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.
I've installed veins_inet project with omnet++ 5.0 and sumo 0.28. When I try to run the .ini on veins_example file this error appears:
Error in the module(omnetp::cModule) Scenario during network setup: Class Veins::VeinsInetManager not found
How do I solve this problem?
Is this the whole error message?
This kind of error can happen when the project is not properly created. To check that, verify if there is a folder named "Includes" in your project (you can see it in eclipse). If no, create a new project in Eclipse New | Project | OMNeT++, and paste your files there.
I am trying to add the application manifest to a program built with C++Builder 2006, by following this article.
(The manifest is to obtain admin rights for my program, which contains "setup" in his name and so it triggers the “This program may not have installed correctly” warning).
I have the MyApp_Setup.exe.manifest in the project folder, along with the MyApp_Setup1.rc file, which is present in the project.
When i try to build, i get:
[RC Fatal Error] MyApp_Setup1.rc(1): File creation failed
What i'm doing wrong, or what should I do?
question edited 'cause i messed up the filenames and the output error didn't matched
Found the problem.
In the project options I always set an "_obj" output folder, but the resource compiler WANTS an existing "debug_build" folder to write the .res file.
It don't create the directory, hence the error in the file creation.
If i remove the "Obj" option, or once you have the "Debug_Build" folder present, everything compiles.
EDIT: See my answer below for the hotfix.
ORIGINAL QUESTION:
In setting up for our boat-programming adventure I have to set up source control and fix project files for a team to use them. (the project was previously only being worked on by one person who took shortcuts with setting up the project includes, etc)
I am fixing those SLN and Proj files. When trying to do a build on an external USB drive (I have not tried it on the primary hard drive) I am getting odd errors (lots of them for various files):
fatal error C1083: Cannot open
compiler generated file:
'.\Debug\.sbr': Permission
denied
These files are referenced in the vcproj file with relative paths in double quotes:
RelativePath="..\..\Source\.cpp"
I get the same errors form within a sln file in the IDE or if I call msbuild with the sln file.
The files are kind of "shared" for a few sln files (projects).
The person who originally created the SLN files is not known for being a wizard at configuring MSDev or making things work for teams.
Is this an issue with the way the source files are referenced? Any suggestions on how to fix these?
This URL does not seem to have helpful information:
Fatal Error C1083 on MSDN
Note - there were/are still hardcoded paths in the proj file, but i don;t see them for these files. They were mostly for the include and lib dirs. I think I removed them all.
I also get these errors:
..\..\Source\.cpp : error C2471:
cannot update program database '\debug\vc90.pdb'
..\..\Source\.cpp(336) : fatal
error C1903: unable to recover from
previous error(s); stopping
compilation
..\..\Source\.cpp(336) : error
C2418: cannot delete browser file:
.\Debug\.sbr
Title: You may receive a "PRJ0008" or "C2471" or "C1083" or "D8022" or "LNK1103" or similar error message when you try to build a solution in Visual C++
Symptoms:
D8022 : Cannot open 'RSP00000215921192.rsp'
PRJ0008 : Could not delete file 'vc90.idb'.
C1083 : Cannot open program database file 'vc90.pdb'
C2471 : Cannot update program database 'vc90.pdb'
LNK1103 : debugging information corrupt.
Cause:
This problem occurs when all of the following conditions are true:
You have a solution with more than one project in it.
Two or more of the projects are not dependent on each other.
You have parallel builds enabled. (Tools -> Options: Projects and Solutions, Build and Run: "maximum number of parallel project builds" is set to a value greater than 1)
You are building on a system with multiple CPUs (cores).
Two or more of the non-dependent projects are configured to use the same Intermediate and/or Output directory.
A specific race condition in mspdbsrv.exe remains uncorrected.
Resolution:
To resolve the problem do one or more of the following:
Reconfigure the non-dependent projects to specify an Intermediate and Output directory that is different from one another, e.g. Output Directory = "$(SolutionDir)$(ProjectName)\$(ConfigurationName)", Intermediate Directory = "$(OutDir)".
Adjust your solution's project dependencies (Project -> Project Dependencies...) so that each is dependent on another.
Disable parallel builds.
Add the "/onecpu" boot option to your boot.ini file.
Change you BIOS settings to enable/use only one CPU.
File a problem report with Microsoft Technical Support and keep bugging the crap out of them until they eventually fix mspdbsrv.
Status:
The problem is a combination of both a user project configuration error as well as a race condition in Microsoft's "mspdbsrv.exe" utility that does not properly handle more than one thread calling it at the same time for the same file resulting in the file's HANDLE being left open.
Additionally Visual Studio itself and/or its build system (VCBUILD and/or MSBUILD) (or all three!) should be made smart enough to detect and alert the user of such user errors so that corrective action can be taken.
This problem has been around for a LOOOOOONG time.
Applies to:
Microsoft Visual C++ 2005
Microsoft Visual C++ 2008
Others?
Respectfully submitted:
"Fish" (David B. Trout)
fish#infidels.org
p.s:
You're welcome. :)
Hmmm.
Perhaps:
http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/0ceac3c6-62f6-4fdf-82e1-d41e1b4fcd20/
there is a hotfix from MS
http://code.msdn.microsoft.com/KB946040
http://support.microsoft.com/kb/946040
That might be my problem. I think it might only be on one machine I have.
EDIT:
I downloaded and ran the hotfix installer. It seems to have fixed it.
I get this same error when I physically remove a file from disk, but leave it in VS. In VS2005 it would give a much better : fatal error file not found. I think this is a bug in VS2008. The hotfix mentioned above didn't help me.
In my case it was my virus package (Trend Micro) causing all the problems. I added my Dev folders to the Ignore/White lists to solve the problem
delete your debug folder and build your project agian.
Occastionally my Visual Studio will suddenly decide something like this. I have found it maybe help to toggle to release, do a full rebuild, then toggle back to debug.