I recently started working on my first .NET Core project and quickly ran into a problem. After adding a class library project, the second time I ran
dotnet run I received the following errors:
error CS0579: Duplicate ‘System.Reflection.AssemblyCompanyAttribute’ attribute
error CS0579: Duplicate ‘System.Reflection.AssemblyConfigurationAttribute’ attribute
error CS0579: Duplicate ‘System.Reflection.AssemblyFileVersionAttribute’ attribute
error CS0579: Duplicate ‘System.Reflection.AssemblyInformationalVersionAttribute’ attribute
error CS0579: Duplicate ‘System.Reflection.AssemblyProductAttribute’ attribute
error CS0579: Duplicate ‘System.Reflection.AssemblyTitleAttribute’ attribute
error CS0579: Duplicate ‘System.Reflection.AssemblyVersionAttribute’ attribute
My Google-fu revealed the solution buried in a GitHub issue thread. Add the following line to your
As the name indicates, this will prevent the build process from generating the AssemblyInfo.cs file in project
obj directories, thus preventing the duplicate attribute conflict.
Disclaimer: I am far from a .NET expert so there is probably more to this story.
The error is a result of the build process generating
AssemblyInfo.cs files in each project
obj directory. This file exists to provide MSBuild metadata about the resulting assembly that can be attached to the build artifact and utilized by anyone who wants such information. You can see your assembly info in Windows by selecting your build artifact, right click -> properties. The following shows the results with GenerateAssemblyInfo set to false. As you can see, the metadata is set to default values.
It’s not clear why the default
.csproj file generated by
dotnet new results in this behavior. The closest I came across was a mention of the philosophy to keep the file as terse as possible. Of course, I’m completely in support of this as
.csproj tends to be a dense mess in Visual Studio. However, this particular scenario puts the onus on the developer to edit the file to eliminate an error which is almost guaranteed to occur in a project of any complexity. A better design decision would have probably been to default to not generating