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.
I have solution with n csharp projects and cpp project on top, this cpp provides interfaces and headers so those csharp ones can be used in other cpp solutions.
The build machine is configured to build csharp project with anyCPU architecture so it provides single assembly per build in Solution\bin\Release. For cpp the anyCpu is not available so I build project twice and store assemblies in Solution\bin\Release\x86 and x64 folders.
This is all to get it packaged in nuget as a single package with .targets file to ease consumption in other cpp projects.
Issue is that cpp project is looking for csharp asseblies using ResolveAssemblyReference and cannot find it, giving missleading message:
ResolveAssemblyReferences:
Primary reference "Implementation".
Could not find dependent files. Expected file "C:\Jenkins\Workspace\Solution\bin\Release\x86\Implementation.dll" does not exist.
Could not find dependent files. Expected file "C:\Jenkins\Workspace\Solution\bin\Release\x86\Implementation.dll" does not exist.
Resolved file path is "C:\Jenkins\Workspace\Solution\bin\Release\x86\Implementation.dll".
Reference found at search path location "".
I tried to alternate ResolveAssemblyReferences behaviour using command line properties, custom targets/properties, but without any luck. The parameters described in https://learn.microsoft.com/en-us/visualstudio/msbuild/resolveassemblyreference-task?view=vs-2017 seem to be computed during the build process and I cannot inject any value, which should be in this case something like $(OutDir)..
The one feasable solution seems to be copy c# dlls into each cpp folder, but I dont think it is the way to solve it properly.
Closes I got is by using /p:ReferencePath like below:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MsBuild\15.0\bin\MsBuild.exe" /p:BuildProjectReferences=false /p:Configuration=Release /p:DebugType=full /p:DebugSymbols=true /p:PlatformToolset=v120 /p:WindowsTargetPlatformVersion=8.1 /p:ForceImportBeforeCppTargets="C:\Jenkins\Workspace\Solution\Cpp.props" /p:OutDir="C:\Jenkins\Workspace\Solution\bin\Release\x86\" /p:Platform=Win32 /t:Build Interface\Interface.vcxproj /p:ReferencePath="C:\jenkins\workspace\Solution\bin\Release"
My custom Cpp.props does:
<Target Name="Output" BeforeTargets="ResolveAssemblyReferences">
<Message Text="AssemblySearchPaths: $(AssemblySearchPaths)" />
</Target>
and by adding /p:ReferencePath it got added to AssemblySearchPaths as second record, after {CandidateAssemblyFiles}; but it is still not finding those dlls
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.
This is pretty crazy, I am only adding an existing .h file to VS2015 C++ project but it would complain:
The desired name for c:\code\usbview\USBdevices.h is invalid
I was able to add this file to project when it had its own .sln file. However, I created a new empty .sln file and wanted to add this and other project and that's how this issue kicked in. It wouldn't add this project to new solution giving a similar weird error about the files I added.
I then add the base project to that solution file and tried to add this .h and .cpp files there but it adds the .cpp but gives this error for .h file.
This is very weird, I changed the files names but the same error.
The link in the comment section by BlackDwarf fixed the problem even though that was was for C# but applies.
I didn't have USERPROFILE environment variable so I created it and set it to c:\Users\my.name and now I can add the file
I had the same problem and it was because of merge errors in the file ProjectName.vcxproj.filters.
The answers here led me to check my vcxproj when I experienced the OP's problem.
It turns out I had two filters with the same name in my Project.vcxproj.filters, something like
<Project>
<Common>
...
...
<Stuff>
<Common>
And I was trying to add files to the second Common.
To fix it, I had to ..
edit the vcxproj manually in {favoured text editor} and remove the second filter I'd added with a duplicate name.
Unload/Reload the project from the solution in VS(2017), and add a filter with a unique name. All good - I can add files to my new filter.
I use VS 2013 Express and had the same error.
Solved by removing VCTargetsPath environment variable, I added it some time ago, don't remember why :)
I had the same issue, but the solution had nothing to do with "Environment Variables" for me. What I did: Close Visual Studio 2017. Reopen my project. Suddenly I had two copies of the "Helper.cpp" and "Helper.h" that I was trying to add already as part of the solution files. Clicking on each I saw that one of the files was invalid, probably because I had deleted that version of the file in that file location. I deleted the invalid files, checked to make sure that the files had the correct code I wanted in them, built the solution and everything ran fine.
Not sure why closing and reopening VS fixed the problem, but glad it did.
If the environment variable route doesn't work for you, check the integrity of your project file next.
I had this problem in 2017, and it was due to a double entry in the vcxproj from a manual editing error. Our vcxproj file had the following in it:
<ClInclude Include="XXXX.h" />
<ClCompile Include="XXXX.h" />
In 2017 we got exactly the error you described when trying to add an existing file, a slightly different one when adding new, and strange crashes elsewhere. Opening the solution in 2015 logged the exact problem and failed to load the project. We removed the double entry and all the mysterious problems vanished.
I've been using Eclipse for a while and this has me stymied. I created a library name ITS8410_LIB a few weeks ago and then let it sit while I worked on a supporting library called Reach_Lib. The directory include paths I added back when I first created the project work fine. Today I finished Reach_Lib and went to add its path to ITS8410_Lib. I used the project properties C++ settings to add a workspace path (like I've done many times before). I have only one build configuration. The path is shown in the image (the one highlighted in blue is the specific one I'm talking about in this question).
When I go to include the file in the source neither Eclipse (I see the yellow question mark) nor the compiler (I get a compiler error) can locate the file. If I add the a directory path using the full absolute path syntax the results are the same. I can modify the source code and specify the #include via a full relative path from the current directory, and it is found. Eclipse just won't use the path specified in the project settings. This same Reach_Lib has an associated unit test project and the path is specified with a workspace setting from there and it works fine.
Directory paths that were added before today appear fine. Paths (there are two libs showing this behavior) I add today just seem to be ignored. I took a look at the compiler settings (see image below) and the path specified to the compiler appears to be OK.
Running under Windows7 64 bit (but using a 32 bit version of Eclipse Indigo).
I have tried:
rebuilding indices
Exiting and restarting Eclipse multiple times
workspace and absolute file paths
modifying the order of the include paths
different .h include files in project
Update
I took a look into the .cproject file and while I don't know much about what these files are supposed to look like I think I have a problem. Maybe the question is: How do I tell Eclipse to rebuild the .cproject file? I appear to have two similar sections and Eclipse is getting confused. I can see different version numbers tagged as suffixes. It appears to me that the visual editors are letting me modify one section but the IDE and compiler only care about the other section. Here's the relevant portions
...
<folderInfo id="nbeclipse.toolchain.nbl.rel.396284009." name="/" resourcePath="">
<toolChain id="nbeclipse.toolchain.nbl.rel.tc.1465290409" name="NetBurner Device Library" superClass="nbeclipse.toolchain.nbl.rel.tc">
<targetPlatform id="nbeclipse.toolchain.nbl.rel.tc.targetPlatform.283367649" isAbstract="false" name="NetBurner Module Library" superClass="nbeclipse.toolchain.nbl.rel.tc.targetPlatform"/>
<builder buildPath="${workspace_loc:/ITS8410_Lib/Release}" id="nbeclipse.toolchain.nbl.rel.tc.builder.2064025940" keepEnvironmentInBuildfile="false" managedBuildOn="true" name="Release ELF builder (MINGW)" superClass="nbeclipse.toolchain.nbl.rel.tc.builder"/>
<tool id="nbeclipse.toolchain.nbl.rel.tc.gcc.278195048" name="GNU C Compiler" superClass="nbeclipse.toolchain.nbl.rel.tc.gcc">
<inputType id="nbeclipse.toolchain.nbl.rel.tc.gcc.input.1060035859" name="GNU C Input" superClass="nbeclipse.toolchain.nbl.rel.tc.gcc.input"/>
</tool>
<tool id="nbeclipse.toolchain.nbl.rel.tc.gpp.767008127" name="GNU C++ Compiler" superClass="nbeclipse.toolchain.nbl.rel.tc.gpp">
<option id="nbeclipse.toolchain.super.gcc.directories.includepaths.1666029541" name="Include paths (-I)" superClass="nbeclipse.toolchain.super.gcc.directories.includepaths" valueType="includePath">
**inside here is an option list with all my include paths**
...
</folderInfo>
Then right after the folderInfo close tag another folderInfo section starts
<folderInfo id="nbeclipse.toolchain.nbl.rel.396284009.2022231003" name="/" resourcePath="src">
<toolChain id="nbeclipse.toolchain.nbl.rel.tc.1982112905" name="NetBurner Device Library" superClass="nbeclipse.toolchain.nbl.rel.tc" unusedChildren="">
<targetPlatform id="nbeclipse.toolchain.nbl.rel.tc.targetPlatform" isAbstract="false" name="NetBurner Module Library" superClass="nbeclipse.toolchain.nbl.rel.tc.targetPlatform"/>
<tool id="nbeclipse.toolchain.nbl.rel.tc.gcc.1671008421" name="GNU C Compiler" superClass="nbeclipse.toolchain.nbl.rel.tc.gcc.278195048">
<inputType id="nbeclipse.toolchain.nbl.rel.tc.gcc.input.436341699" name="GNU C Input" superClass="nbeclipse.toolchain.nbl.rel.tc.gcc.input"/>
</tool>
<tool id="nbeclipse.toolchain.nbl.rel.tc.gpp.498310867" name="GNU C++ Compiler" superClass="nbeclipse.toolchain.nbl.rel.tc.gpp.767008127">
**the newly added paths don't show up here, if I add them manually things start working**
The key to the answer was posted by dbrank0 but he didn't promote it to an answer so I just upvoted the comment. Something went wrong in the .cproject file and editing it manually fixed the problem.
Try to replace relative workspace path to real path (add same include as filesystem) in include directories project settings.
full absolute path is okay at any time.
when use the relative directory you should be careful.
in eclipse the current directory is not the same as run directory.
string strRunDir, strCurDir;
strRunDir = AfxGetApp()->m_pszExeName;
strCurDir = GetCurrentDirectory(...);
and strRunDir != strCurDir;
when you want to use the relative directory, you should reference to the runDir;