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’ve been trying to explore WSO2 Microgateway and set up a Microgateway project. Building the project in Windows 10 with the command “micro-gw build project-name” is giving this error: “Could not find or load main class org.wso2.apimgt.gateway.cli.cmd.Main”.
I’ve downloaded the Toolkit and Runtime from https://wso2.com/api-management/api-microgateway/. I've set the Path environment variable to the /bin directory of the Toolkit and Runtime extracted folders, but still the “micro-gw build project-name” command is giving error “Could not find or load main class org.wso2.apimgt.gateway.cli.cmd.Main”. I’ve also cloned the source code from Github (https://github.com/wso2/product-microgateway/) which has the Main.java class and tried setting environment variables to its path.
I also tried setting the environment variables to the path where Toolkit batch file is present. I also followed the steps mentioned here, https://github.com/wso2/product-microgateway/#running-the-microgateway.
I'm assuming the Toolkit batch file (micro-gw) would execute the Main.java class coming up in the error.
These steps did not resolve the error. I'm new to Java based product, and I'm sure I'm missing something here.
Problem is with the init command not the build command. Init command is suppose to setup the TOOLKIT after the first use. It should extract the platform.zip file and copy all of the required resources to relevant places for you.
I hope you get the Project ___ successfully initialized message after running the init command. Just check $TOOLKIT_HOME/logs/ directory to see if there are any information on the log file.
If the log file also doesn't help, as a workaround, copy all the .jar files inside $TOOLKIT_HOME/lib/gateway/platform and $TOOLKIT_HOME/lib/gateway/cli to $TOOLKIT_HOME/lib/platform/bre/lib and try again, that should work.
Also please report this issue at https://github.com/wso2/product-microgateway/issues
I am new for creation of NuGet Package. Somehow I managed to create NuGet Package as my solution. But, I am facing few problems in my solution. Based on regions, I am using the configuration file. for example, i am having following config files in my solution.
1) Service-AMR.config
2) Service-EUR.config
During build, i want to convert above files to service.config in AMR folder and same for another one. I have tried copy files task and failed.
Please help., Thanks in advance.
To simply rename a file name on the build agent, you could use cmd.exe in a command line task to rename files. Here's an example :
Arguments: String.Format("/c rename ""{0}"" ""{1}""","currentname.config","newname.config")
FileName: "C:\Windows\System32\cmd.exe"
WorkingDirectory: "C:\Windows\System32"
So I am running into an issue when I go to build my projects using tfs build controller using the Output location "AsConfigred" it will not detect my unit tests. Let me give a little info on my setup.
TFS 2013 Update 2, Default Process Template
Here is a few screenshots that can hopefully help fill in what I can't in typing. I am copying my build out to a file share on our network so that we can use other utilities use the output. I don't want to use "PerProject" or "SingleFolder" because they mess up the file structure we have configured (These both will run the tests). So i have the files copy to folder names "SingleOutputFolder" which is a child of the DropLocation. I would like to be able to run from the drop folder or run from the bin folder for each of my tests (I don't care which). However it doesn't seem to detect/run ANY of the tests. Any help would be greatly appreciated. Please let me know if you need any additional information.
I have tried using ***test*.dll, Install\SingleFolderOutput**.test.dll, and $(TF_BUILD_DROPLOCATION)\Install\SingleFolderOutput*test*.dll
But I am not sure what variables are available and understand where the scope of its execution is.
Given that you're using Build Output location set to AsConfigured you have to change the default values of the Test sources spec setting to allow build to find the test libraries in the bin folders. Here's an example.
If the full path to the unit test libraries is:
E:\Builds\7\<TFS Team Project>\<Build Definition>\src\<Unit Test Project>\bin\Release\*test*.dll
use
..\src\*UnitTest*\bin\*\*test*.dll;
This question was asked on MSDN forums here.
MSDN Forums Suggested Workaround
The suggested workaround in the accepted answer (as of 8 a.m. on June 20) is to specify the full path to the test projects' binary folders: For example:
C:\Builds\{agentId}\{teamProjectName}\{buildDefinitionName}\src\{solutionName}\{testProjectName}\bin*\Debug\*test*.dll*
which really should have been shown as
{agentWorkingFolder}\src\{relativePathToTestProjectBinariesFolder}\*test*.dll
However this approach is very brittle, for the following reasons:
Any new test projects you add to the solution will not be executed until you add them to the build definition's list of test sources:
It will break under any of the following circumstances:
the build definition is renamed
the working folder in build agent properties is modified
you have multiple build agents, and a different agent than the one you specified in {id} runs the build
Improved Workaround
My workaround mitigates the issues listed in #2 (can't do anything about #1).
In the path specified above, replace the initial part:
{agentWorkingFolder}
with
..
so you have
..\src\{relativePathToTestProjectBinariesFolder}\*test*.dll
This works because the internal working directory is apparently the \binaries\ folder that is a sibling of the \src\ folder. Navigating up to the parent folder (whatever it is named, we don't care) and back in to \src\ before specifying the path to the test projects binaries does the trick.
Note: If you have multiple test projects, you add additional entries, separated with semicolons:
..\src\{relativePathToTestProjectONEBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTWOBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTHREEBinariesFolder}\*test*.dll;
What I ended up doing was adding a post build event to copy all of the test.dll into the staging location folder in the specific build that is basically equivalent to where it would go on a SingleFolder build and do that on each test project.
if "$(TeamBuildOutDir)" == "" (
echo "Building Interactively not in TFS"
) else (
echo "Building in TFS"
xcopy "$(TargetDir)*.*" "$(TeamBuildBinaries)\" /Y /E /S
)
MSBUILD parameter in the build def that told it to basically drop in the folder that TFS looks for them.
/p:TeamBuildBinaries="$(TF_BUILD_BINARIESDIRECTORY)"
Kept the default Test assembly file specification:
**\*test*.dll
View this link for the information on the variable that I used and what relative path it exists at.
Another solution is to do the reverse.
Leave all of the files in the root so that all of the built in functionality works. There is more than just test execution in there. What about static code analysis, impact analysis..among others. You would have to do something custom for them all.
Instead use a pre-drop powershell script to create your Install arrangement from the root files.
If it is an application then you can use the _ApplicationFolder Nuget package to create an _PublishApplications folder same as you get for web applications.
I am trying to find a way to call notepad++ from command line with compare plugin showing the compare result providing I pass 2 files name which I want to compare.
Think like I have a batch file, which does some work and result is opening notepad++ showing 2 files in compare mode. (Yes, compare plugin is installed)
If anyone has any other suggestion to using any other editor or software also welcome..
tl;dr:
The command is Notepad++\plugins\ComparePlugin\compare.exe file1 file2.
Details:
Download the compare plugin https://bitbucket.org/uph0/compare/downloads/ComparePlugin.v1.5.6.6.bin.zip. Installing the compare plugin from the plugin manager within Notepad++ does not install the requisite exe. I assume you could also build from source to obtain the exe.
Follow the manual installation instructions in the readme:
To install manually, copy ComparePlugin.dll and ComparePlugin subfolder
into the plugins directory C:\Program Files\Notepad++\Plugins.
For a portable Notepad++ installation, you need to run the command from a directory above the notepad++ directory (or with absolute path of exe), otherwise you get an error that Notepad++.exe is not found.
The commands look like this:
>cd C:\portapps\Notepad++
>cd ..
>Notepad++\plugins\ComparePlugin\compare.exe C:\files\file1.txt C:\files\file2.txt
ufo's answer put me on the right track but it did not contain the commands to run.
There's a tool called NppCompareLoader doing exactly what you want. Simply drop it in the N++ installation folder. I'm using it since many years as a diff viewer for TortoiseSVN and TortoiseGit, thus you should certainly be able to call it right from command line.
/EDIT
Since the (unofficial) Compare-plug-in version 1.5.6.6 the additional loader mentioned above isn't required anymore. There's already one included in the plug-in. Here's the regarding change-log fragment:
NEW: Loader for using N++ as an external diff viewer (e.g. in TortoiseSVN, TortoiseGit, ..)