UPDATED: 2020-12-23

I’ll leave the below for posterity, but recently I came across the real reason for the error. In this issue it was pointed out that your .net core solutions have to be structured in a particular way. Specifically, make sure that you do not create projects in the same directory as your main project.

Problem description

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

tl;dr Solution

My Google-fu revealed the solution buried in a GitHub issue thread. Add the following line to your *.csproj files:

<GenerateAssemblyInfo>false</GenerateAssemblyInfo>

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.

Details

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 AssemblyInfo.cs.