I know I have to define this section in Development.xml:
<serverSideConsoleProjects>
<project>
<Name>Program</Name>
<AssemblyName>Assembly</AssemblyName>
</project>
</serverSideConsoleProjects>
Do I have to do anything else? What effect does this actually have on the solution or on any of the Package Manager Console operations?
Essentially, declaring a server-side console project causes that project's build output to be included in the Logic Packages folder that gets created in your solution folder by the ExportLogic console operation. To my knowledge there is nothing else that EWL does right now with these projects.
Related
When I build my application I get the following error
Error CS0579 Duplicate 'global::System.Runtime.Versioning.TargetFrameworkAttribute' attribute MyUIApp
D:\MyUIApp\obj\Debug\netcoreapp3.1\.NETCoreApp,Version=v3.1.AssemblyAttributes.cs 4 Active
The following code is autogenerated in the obj/Debug/netcoreapp3.1 folder
//
using System;
using System.Reflection;
[assembly: global::System.Runtime.Versioning.TargetFrameworkAttribute(".NETCoreApp,Version=v3.1", FrameworkDisplayName = "")]
I have a project file starting with
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<OutputType>Library</OutputType>
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
<RestorePackages>true</RestorePackages>
<UseWindowsForms>true</UseWindowsForms>
</PropertyGroup>
<PropertyGroup>
I can work around the issue by commenting out the contents of the file, but not by deleting the file.
I was also getting this error in VS Code and the following fixed it.
I have a project/solution with three projects within in.
netstandard2.1
netstandard2.1
netcoreapp3.1
I added the following line to each of the *.csproj files within the <PropertyGroup> section:
<GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute>
Full example
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.1</TargetFramework>
<GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>
</Project>
After doing the above you might need to clean /bin and /obj folders for each project.
This article pointed me in the right direction though nothing online that I found mentioned the attribute above. I just guessed and it worked!
Add the following two lines to the <PropertyGroup>. This fixed it for me.
<PropertyGroup>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
<GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute>
</PropertyGroup>
The problem was about my folder structure : the test project was in the main project folder. Passing each side by side in the same repo solved the problem
MyProject
src/MyProject.csproj
tests/MyTestProject.csproj
Taken from Github issue : https://github.com/dotnet/core/issues/4837
So i did encounter the same on a .NET 4.7 based solution, spent hours, only to find out a colleague of mine did include the obj and bin folders in the project!
excluding them fixed the issue and that error went away.
hope this save someone a couple of hours.
I fixed this by deleting the obj and bin folders in each project directory. I then cleaned the solution and rebuilt. The rebuild succeeded.
You just need to exclude the obj folder from the project/solution.
I was facing the same issue in my asp.net core 3.1 application right after I add the xUnit project to the solution. Ultimately, the main issue was because of that I selected the check box Place solution and project in the same directory as shown in the preceding image.
This should work in normal cases, and you will just consider this root directory as the Git repository (the .sln file and the .csproj will be in the same folder). But you will not be able to add a new project to this directory as you will get the error "Error CS0579 Duplicate 'global::System.Runtime.Versioning.TargetFrameworkAttribute'". So, to fix this error, we just have to follow the preceding steps.
Create a folder with the same name in the .sln file
Move all the project-related files to that directory
Open your .sln file with any code editor
Edit the Project references.
Make sure that your .sln file is in the root directory
This is how your project file references may look like now.
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "WebApplication2", "WebApplication2\WebApplication2.csproj", "{027937D8-D0E6-45A4-8846-C2E28DA102E6}"
EndProject
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "WebApplication2.Tests", "WebApplication2.Tests\WebApplication2.Tests.csproj", "{AD4C6C31-F617-4E76-985A-32B0E3104004}"
EndProject
That's it. Just reload your solution and happy coding!.
Try to delete obj folder from Project, delete it from SolutionExplorer instead of WindowExplorer.
I encountered that issue, what I did is I deleted the .NETCoreApp,Version=v3.1.AssemblyAttributes.cs and then I ran VSCode as an administrator.
I had this when my folder structure got messed up. I'm using Visual Studio 2019 and switched branches that has different folder structure. Some folders got added up in the file explorer and didn't get deleted even if I switched branches. All I did was to delete those folders that weren't part of my current branch and it worked.
I am having the same problem. As far as I can tell, the flag should prevent the auto-generation of assembly info. However, I can see this file in my obj directory:
.NETStandard,Version=v2.1.AssemblyAttributes.cs
It only contains the target version attribute. Maybe there is some other way of suppressing this attribute?
It seems like this might be a regression in .NET core 3.1.300. I was building with .NET core 3.1.200 and I didn't see this issue until I upgraded.
I experienced this on a build pipeline in Azure Devops. I was using a local agent to run the pipeline on (my own machine). It appears that there was code in the working directory that was causing this conflict, and by default, the agent doesn't clean the working directory before starting the pipeline process.
The fix was to delete the contents of the working directory on the agent. I did this by selecting the option to clean the working directory:
I had this kind of Errors in my Blazor Server project when I tried to add .NET Standard Class Library project in Visual Studio 2019.
Errors:
To fix this i tried following ways.
.csproj file Before
.csproj file After
In my case the culprit was my test project so I had to go to my test folder > obj > Debug/net6.0 > .NETCoreApp,Version=v6.0.AssemblyAttributes.cs
and then commented this line
[assembly:global::System.Runtime.Versioning.TargetFrameworkAttribute(".NETCoreApp,Version=v6.0", FrameworkDisplayName = "")]
This error can also happen if you accidentally copied an project file into another projects folder.
in my case (.NET 6.0);
I just exclude the Properties folder from the project/solution.
From the many different kind of answers, it's clear that there could be different reasons for the same issue. In my case the solution definition file was the cause. I decided to delete and create a clean solution file.
Delete the .sln file
Create a blank .sln file, in the root of your project/solution:
dotnet new sln
For every C# project file in your solution, add it with the following command, for example:
dotnet add MyApplication.csproj
and for example:
dotnet add CustomPackages/MyLibrary.csproj
Then to make sure all previous build artefacts are cleaned up
dotnet clean
Encountered this issue when working with AWS Lambda. Turns out I was switching branches, and some auto-generated folders did not get cleared after switching to new branch, and dotnet was picking them up for some reason. The easiest solution is to delete all local project folders, and check out clean version of the code again.
I commented out the offending attribute
// obj/Debug/netcoreapp3.1/.NETCoreApp,Version=v3.1.AssemblyAttributes.cs
using System;
using System.Reflection;
//[assembly: global::System.Runtime.Versioning.TargetFrameworkAttribute(".NETCoreApp,Version=v3.1", FrameworkDisplayName = "")]
DELETE [assembly: global::System.Runtime.Versioning.TargetFrameworkAttribute(".NETCoreApp,Version=v6.0", FrameworkDisplayName = "")]
I was able to solve this issue by getting a new clone of the project.
VS2017, SDK/WDK, C++ project
we have a c++ solution (driver) that is shared across developers via Team Foundation Services - visualstudio.com (now called azure devops?).
When I perform a get latest source code, and want to rebuild the solution I get two MSB3030 errors:
"Could not copy the file "C:\path of my colleague his file" because it was not found."
I found it strange that I saw on one of the two errors a path of my colleague his pc. He works on C:\ I'm working on E:\
Unloading the project, I saw he path being set here:
<ItemGroup>
<FilesToPackage Include="C:\path of my colleague\foo.xml" Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<PackageRelativeDirectory>
</PackageRelativeDirectory>
</FilesToPackage>
We cannot get this solution to build because of the MSB3030. First we have to clean the specific projects individually, rebuild it, then build another project etc.. a few steps to perform manually in the correct order , trial and error, drinking coffee, throwing bananas to the pc and praying that a monkey outputs the code correctly.
Has anyone seen somehting similar regarding MSB3030 errors?
On my pc I see the path of my colleague, but he doesn't see my path (strange!).
C:\Program Files (x86)\Windows
Kits\10\build\WindowsDriver.common.targets(1699,5): error MSB3030:
Could not copy the file 'C:...' because it was not found.
I've set the Any CPU to x64 because it doesn't make any sense for c++.
C++ Windows Driver MSB3030 could not copy the file '' because it was not found
The reason for this issue is that the path of the ItemGroup is an absolute path in the project file:
<ItemGroup>
<FilesToPackage Include="C:\path of my colleague\foo.xml" ...>
...
</FilesToPackage>
</ItemGroup>
Regardless of whether your colleague has added this file to source control, when you pull the code from the TFS server to your local and put the code in a different local folder, the absolute path will bring you a lot of trouble, you need to manually check the code on the TFS server for this file and you need to modify the absolute path of this file in your project. But this problem will reappear after your colleague updates after you submit your code. Because an absolute path cannot be assigned to two different paths C:\ and E:\.
To resolve this issue, you need to change the absolute path to a relative path in the source code. Generally, we prefer to add this file to the Solution/Project folder, then use the MSBuild Macros $(SolutionDir)/$(ProjectDir) to specify it.
Check Common macros for build commands and properties for some more details.
Hope this helps.
So, I have a project in VS2017, and VS2017 has recently received an update. I have then added all the wxWidgets modules as projects to my initial solution and have dealt with build order so they're built in the proper order.
However, I always get this error:
C:\Programs\Visual Studio 2017\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Common.props(144,5): warning
MSB4211: The property "WindowsTargetPlatformVersion" is being set to a value for the first time, but it was already consumed at
"C:\Programs\Visual Studio 2017\Common7\IDE\VC\VCTargets\Microsoft.Cpp.WindowsSDK.props (29,5)".
I've found this thread and the article linked in it: link
but it doesn't tell me how to fix it. From what I can tell, the properties for individual project are not evaluated in an order they should be evaluated.
How do I define the property sheet ordering? What exactly do I need to change?
Also not that I cannot change the project files or anything connected to wxWidgets since it's a submodule in my repository and any changes done cannot be saved to the repo.
Disclaimer: I haven't got a clue about your issue ,just trying to help you (the OP) !
In the IDE ,under menu View ,select other windows.
There select Property Manager ,which let you manipulate property sheets in your projects.
Right-click on a property-sheet. Some sheets have a menu which let you move the sheet up or down.
I suggest to play around with that. It might just solve your issue.
I could be completely wrong of course.
I had the same problem, with a different library though.
The cause for me was that in the project that I converted, the configuration that I was compiling with was not present in the props file
C:\Users\\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props
For example, in the vcxproj file I had
<ProjectConfiguration Include="DLL Release|x64">
<Configuration>DLL Release</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
but in the props file I only had:
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<ClCompile>
<PreprocessorDefinitions>MYMACRO1;MYMACRO2;%(PreprocessorDefinitions)</PreprocessorDefinitions>
</ClCompile>
</ItemDefinitionGroup>
I just added a similar entry for 'DLL Release|x64' and that fixed it.
Definitely the warning message is not very helpful in this case.
I am trying to set/override some settings in our TEST installation of TFS with regards to forcing Code Analysis and assosicated settings during the build process (regardless of the setting sin the project file)
We currently use in our TEST TFS installation:
Visual Studio 2012 Ultimate on our developer machines AND build server
Have TFS 2012 installed on one server (application and data layer)
Have TFS 2012 build service (controller and agent) installed on another server
We can compile sample .net 4.5 projects (class libraries (DLLs), web applications etc) as expected. This is solely to do with overriding associated Code Analysis settings (hopefully).
Scenario 1 - In our sample applications on our developer machines when you select the project settings (right click -> properties in solution explorer), go to the Code Analysis tab if I turn on the "Enable Code Analysis on build" and select a Rule set from the drop down is performs as exepcted, hence it will generate some warnings. This technical adds <RunCodeAnalysis>false</RunCodeAnalysis> to the *.csproj file if opened up in notepad. If the build is executed to compile the sample project/solution then Code Analysis is performed as expected. I do NOT want to do this on every project because a developer could turn it off (although I am looking to have check-in policies and/or private/gated checkins as well to force this anyway).
Scenario 2 - I can disable the "Enable Code Analysis on Build" checkbox and force code analysis in our TFSBuild.proj file (we (will) use the default upgradetemplate.xaml as our process definition because we will be upgrading from TFS 2008 on our LIVE TFS installation) by having:
<RunCodeAnalysis>Always</RunCodeAnalysis>
This works and this is how we will force (lessons still to be learned :-)) Code Analysis on our builds.
The problem then comes when setting other assosicated Code Analysis settings. For example which default rule set(s) to apply/use or treat CA warnings as errors. Some of these settings can be set either in VS or all of them by editting *.csproj in notepad. If i edit the *.csproj then these values are used in the build as expected (as well as locally on the developer machine). This is not ideal as I want to do it centrally in TFSBuild.proj without having to edit every project file. I believe I can use settings such as in my TFSbuild.proj file:
<PropertyGroup>
<RunCodeAnalysis>Always</RunCodeAnalysis>
<CodeAnalysisRuleSet>AllRules.ruleset</CodeAnalysisRuleSet>
<CodeAnalysisTreatWarningsAsErrors>true</CodeAnalysisTreatWarningsAsErrors>
</PropertyGroup>
But they don't appear to work or I am putting them in the wrong place? How do I fix/use them correctly?
FYI i build my solutions in TFSBuild.proj by:
<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />
<ItemGroup>
<SolutionToBuild Include="/some folder/some solution.sln" />
<ConfigurationToBuild Include="Debug|Any CPU">
<FlavorToBuild>Debug</FlavorToBuild>
<PlatformToBuild>Any CPU</PlatformToBuild>
</ConfigurationToBuild>
</ItemGroup>
</Project>
On the build server I did find reference to the target file for Code Analysis at c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\CodeAnalysis but I dont want to change the default behaviour on the build server (although it does work when I do). The condition for example for CodeAnalysisTreatWarningsAsErrors must be getting evaluated as false. Its like my values are not read from TFSBuild.proj but are from the .csproj file.
Any questions feel free to ask and thanks in advance
I had what I think is a similar problem with Cruise Control not compiling using the CODE_ANALYSIS compilation symbol, even if "Enable Code Analysis on Build (defines CODE_ANALYSIS constant)" was checked in VS.Net.
It looks like whether it is check or not, CODE_ANALYSIS is actually not explicitly added to the list of compilation symbols in the csproj (even if it appears in the text box "Conditional compilation symbols"), only <RunCodeAnalysis>true</RunCodeAnalysis> is added.
When compiling through VS.Net, the CODE_ANALYSIS is automatically added, but not when using MSBuild, which is what Cruise Control uses.
I eventually changed in VS.Net the "Conditional compilation symbols" from "CODE_ANALYSIS;MySymbol" to "MySymbol;CODE_ANALYSIS". Doing that forced CODE_ANALYSIS to also appear in the csproj.
I remember having a similar problem - but not having the time to investigate it, I worked around it by calling FxCop directly using the exec task. I'll just give you the highlights, omitting the specification of some properties, I hope the names are clear.
I created an ItemGroup of the output dlls, FilesToAnalyze, and fed it to FxCop in a way similar to:
<PropertyGroup>
<FxCopErrorLinePattern>: error</FxCopErrorLinePattern>
<FxCopCommand>"$(FxCopPath)" /gac /rule:"$(FxCopRules)" /ruleset:="$(FxCopRuleSet)" #(FilesToAnalyze->'/file:"%(identity)"', ' ') /out:$(FullFxCopLog) /console | Find "$(FxCopErrorLinePattern)" > "$(FxCopLogFile)"</FxCopCommand>
</PropertyGroup>
<Exec Command="$(FxCopCommand)"
ContinueOnError="true">
<Output TaskParameter="ExitCode" PropertyName="FxCopExitCode"/>
</Exec>
<ReadLinesFromFile File="$(FxCopLogFile)">
<Output TaskParameter="Lines" ItemName="AllErrorLines"/>
</ReadLinesFromFile>
I could then determine the number of errors in the output using an extensionpack task:
<MSBuild.ExtensionPack.Framework.MsBuildHelper TaskAction="GetItemCount" InputItems1="#(AllErrorLines)">
<Output TaskParameter="ItemCount" PropertyName="FxErrorCount"/>
</MSBuild.ExtensionPack.Framework.MsBuildHelper>
and create a failing build step for each error:
<BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
BuildUri="$(BuildUri)"
Id="$(FxCopStep)"
Status="Failed"
Message="FxCop Failed: $(FxErrorCount) errors."/>
<BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
BuildUri="$(BuildUri)"
Status="Failed"
Message="%(AllErrorLines.Identity)"/>
By doing code analysis on the build server this way, we also avoided having to configure each project separately. We isolated all this in a separate .targets file, so adding code analysis to a solution was a matter of importing that file, and perhaps adjusting the behavior by setting appropriate properties.
I have a VS2010 unit test project set to using SpecFlow 1.8.1 and mstest. In order to get the SpecFlow unit tests working, I've done the following:-
I added the references to the following files in my project:-
Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
TechTalk.SpecFlow.dll
Note that the TechTalk.SpecFlow.dll has been added into my project and the reference points to that file.
I've set the "Copy Local" property of the TechTalk.SpecFlow.dll reference to True.
I've also added an App.Config that specifies "MsTest.2010" as the provider, and regenerated all code-behinds for the SpecFlow features.
Everything works in my VS2010, the tests run successfully in both the SpecFlow testrunner and the mstest test runner. BUT when I try to run the mstests in TFS 2008 (using a .vsmdi test list file), it failed with the following exception:-
Class Initialization method MyNamespace.MyTestFeature.FeatureSetup threw exception.
System.Configuration.ConfigurationErrorsException:
System.Configuration.ConfigurationErrorsException: An error occurred creating the
configuration section handler for specFlow: Could not load file or assembly
'TechTalk.SpecFlow' or one of its dependencies. The system cannot find the file
specified. (D:\Projects\TestProject\TestResults\administrator_MYPC 2012-06-27
18_30_05_Any CPU_Debug\Out\TestProject.DLL.config line 4) --->
System.IO.FileNotFoundException: Could not load file or assembly 'TechTalk.SpecFlow'
or one of its dependencies. The system cannot find the file specified.
Note that the TFS built the project fine and it runs other unit tests in the same project (normal mstests, not SpecFlow) without problems. It only failed for the SpecFlow test runs.
So what am I doing wrong?
Edit: The contents of my App.Config file looks like this:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section
name="specFlow"
type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow"/>
</configSections>
<specFlow>
<unitTestProvider name="MsTest.2010" />
<runtime detectAmbiguousMatches="true"
stopAtFirstError="false"
missingOrPendingStepsOutcome="Inconclusive" />
<trace traceSuccessfulSteps="true"
traceTimings="false"
minTracedDuration="0:0:0.1" />
</specFlow>
</configuration>
Following the instruction on this site and this site:
the command Tools > Library Package Manager > Package Manager Console allows you to type in PM> Install-Package SpecFlow
when the prompts returns "installed successfully", the SpecFlow Assembly now appears in the references of your project. And the MSTest project now compiles succesfully (at least for me).
I got this error as well, in my case the problem was that I was using the \...\obj\Debug||Release\ folder as target and not the \...\bin\Debug||Release\ folder. Looking in these folders I saw that the TechTalk.dll assembly was missing from the former. Simply switching in my .bat file the problem was fixed.
Sometimes VS2013 is looking for SpecRun dlls not in project folder, but in C:\Users\**YOUR_USER**\AppData\Local\Temp\VisualStudioTestExplorerExtensions\SpecRun.Runner.1.3.0\tools. So you just need to put all necessary SpecFlow libraries therel
One hack I found to get it working is to add another class for EVERY single SpecFlow feature that I created in the project. The class looks like this:-
[DeploymentItem(#"TechTalk.SpecFlow.dll")]
partial class MyTestFeature { }
// The above class-name needs to come from the auto-generated code behind
// (.feature.cs) for each SpecFlow feature.
I consider this as a very nasty hack, but it does provide a clue as to why it didn't work. It would be good if anyone comes up with a more elegant solution.
I finally found the more proper fix for this issue. I just need to add a post-build event to remove the .config file from the build output. (The App.config file is used only to generate the code-behind during design time. It is not used at all during runtime, so it can be removed.)
The command for the post-build event looks like this:-
del /f /q "$(TargetDir)$(TargetFileName).config"
Correction: The .config file is used for generating inconclusive results, so a better post-build event command is as follows:-
if "$(IsDesktopBuild)"=="false" del /f /q "$(TargetDir)$(TargetFileName).config"