Sdk: dotnet build results in error CS0579 duplicate attributes with AssemblyVersionAttribute (and others) specified

[frankbuckley]

Building a library project fails with error CS0579 (duplicate attribute) with library projects with AssemblyVersionAttribute (or other assembly attributes) specified.

• Adding (for example) <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute> to csproj fixes

Steps to reproduce

• dotnet new -t lib
• insert [assembly: System.Reflection.AssemblyVersion("0.1.0.0")] into Library.cs
• dotnet restore
• dotnet build

Expected behavior

Build is successful

Actual behavior

Build fails:

   "C:\dsedev\src\AssemblyInfoTest\AssemblyInfoTest.csproj" (Build target) (1) ->
   (CoreCompile target) ->
     obj\Debug\netstandard1.4\AssemblyInfoTest.AssemblyInfo.cs(13,12): error CS0579: Duplicate 'System.Reflection.AssemblyVersionAttribute' attribute [C:\dsedev\src\AssemblyInfoTest\AssemblyInfoTest.csproj]

Environment data

C:\dsedev\src\AssemblyInfoTest>dotnet --info
.NET Command Line Tools (1.0.0-preview3-004056)

Product Information:
 Version:            1.0.0-preview3-004056
 Commit SHA-1 hash:  ccc4968bc3

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64

[frankbuckley]

Setting GenerateAssemblyInfo property to false fixes for all attributes:

<PropertyGroup>
  <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>

[TheRealPiotrP]

@frankbuckley Im glad the switches fix the issue. Do you have thoughts on how the experience should change?

[frankbuckley]

(I'm not sure why I thought this did not happen with exe projects. I have just tried again and it does.)

I hit the issue porting existing code from existing PCL projects by creating a new netstandard/core library (dotnet new -t lib) and copying sources (including, as it happened, Properties\AssemblyInfo.cs).

If traditional assembly attributes are being somehow deprecated in the new csproj model, I think the error message should be more explanatory. I was left wondering "what duplicates?" The error message should state something like assembly attributes are generated from the project file, hence the duplication.

That said, if assembly attributes are defined in code files, could they not simply take precedence and prevent the (duplicated) generation of assembly attributes by the build system?

It is particular confusing that these are auto-generated when there are no properties in the csproj file specifying version numbers (or company, etc.) They seem to appear from nowhere!

In our build system, we use GitVersion to set version numbers for different builds/branches, so want to keep AssemblyInfo.cs files around for that purpose.

[TheRealPiotrP]

@nguerrera @dsplaisted thoughts on improving the error message to hint at the auto generation flags?

@frankbuckley We chose not to inspect the included assemblyinfo.vs because it is very expensive to open the assemblyinfo.cs at build time. We would add 100s of ms to all builds with that approach.

I think improving the UX here is valuable as this question comes up often...

[atanasa]

Considering why you are migrating back to MSBuild, legacy code should work with minimal changes. That is, one way is for the default value for GenerateAssemblyInfo to be false and migration from project.json to handle this.
If I remember correctly, the project.json behavior was to generate only the attributes that were specified in the project.json and that approach supported both legacy code and new code.
I couldn't find how the current tooling decided what values to put in the attributes, I assume the AssemblyName property was being propagated to all values. A similar approach to what project.json did would probably be better than having the flag GenerateAssemblyInfo as that is more granular.

[dsplaisted]

@atanasa We do have granular attributes that let you enable or disable each automatically generated assembly attribute: https://github.com/dotnet/sdk/blob/8f09baf9b3c600d7df3495c6eb68814959b4bafb/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.GenerateAssemblyInfo.targets#L27-L36

I would like to improve the error message here, but I would not like to have to put an extra property in the project file in order to enable automatically generating assembly attributes. We are trying to make project files as concise as possible.

[offbeatful]

Is there any documentation to clarify how to control attribute values that are auto-generated? The ideal case for us would be to have a static (may be even shared) assembly info file with Company, Product, Trademark, Copyright, Description etc and dynamic part with version, configuration etc. It would be perfect to set the dynamic part in the form of command like arguments.

[alexellis]

This is a very odd error and unexpected - I got it by creating a new "console" type of project, a "library" type and then referencing the library from the console app.

[killyosaur]

This is happening in my .net core 2.0 application that started out as a .net core 2.0 app. I don't actually have an assembly.c file, it just generates one for me

[gwalschl]

I have just experienced exactly what @alexellis just described and I'm using the new SDK format project on .NET framework targeted code. I have a project with a class library. Built fine repeatedly. Added another project that created a console app that referenced the class library, got duplicate assembly info errors. Removed the executable project, built just fine again. There are still issues here at this point in time...even in such a basic use case!

[nguerrera]

@gwalschl please open a new issue with the precise steps you took to get to the error.

[rdhainaut]

I have encountered a error CS0579 duplicate attributes after "an upgrade" to .NetStandard library project.
After some investigation, i have founded that i have a file 2 AssemblyInfo files.

• One in Properties/AssemblyInfo.cs
• A new one auto generated during the compilation in obj/Debug/netStandard2.0/ProjectName.AssemblyInfo.cs

After delete Properties/AssemblyInfo.cs file, the compilation works like a charm and the error was gone.

[frankbuckley]

Closing as @TheRealPiotrP stated this is by design. FWIW, we moved away from AssemblyInfo.cs with GitVersion and now write version information into a common MSBuild props file that our projects reference.