New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dotnet build results in error CS0579 duplicate attributes with AssemblyVersionAttribute (and others) specified #4783

Closed
frankbuckley opened this Issue Nov 19, 2016 · 13 comments

Comments

Projects
None yet
10 participants
@frankbuckley
Copy link

frankbuckley commented Nov 19, 2016

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

This comment has been minimized.

Copy link
Author

frankbuckley commented Nov 19, 2016

Setting GenerateAssemblyInfo property to false fixes for all attributes:

<PropertyGroup>
  <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>
@TheRealPiotrP

This comment has been minimized.

Copy link
Contributor

TheRealPiotrP commented Nov 19, 2016

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

@frankbuckley

This comment has been minimized.

Copy link
Author

frankbuckley commented Nov 19, 2016

(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.

@frankbuckley frankbuckley changed the title dotnet build results in error CS0579 duplicate attributes with library projects with AssemblyVersionAttribute (and others) specified dotnet build results in error CS0579 duplicate attributes with AssemblyVersionAttribute (and others) specified Nov 19, 2016

@TheRealPiotrP

This comment has been minimized.

Copy link
Contributor

TheRealPiotrP commented Nov 19, 2016

@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

This comment has been minimized.

Copy link

atanasa commented Nov 25, 2016

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

This comment has been minimized.

Copy link
Member

dsplaisted commented Nov 25, 2016

@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.

@TheRealPiotrP TheRealPiotrP added this to the Discussion milestone Nov 28, 2016

@offbeatful

This comment has been minimized.

Copy link

offbeatful commented Dec 22, 2016

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.

Arkatufus added a commit to Arkatufus/akka.net that referenced this issue May 10, 2017

Aaronontheweb added a commit to akkadotnet/akka.net that referenced this issue May 22, 2017

Change Dictionary.ContainsKey() + Dictionary[] combination to Diction…
…ary.TryGetValue() (#2651)

* Change all Dictionary.ContainsKey(key) + Dictionary[key] combination to Dictionary.TryGetValue(key, out value)

* Shuffle the code a bit so it makes more sense.

* Workaround for dotnet/cli#4783 (dotnet/cli#4783)

* Use new C# 7.0 out variable feature

* Code formatting
- Remove curly braces from single line if statements
- Add new line to single line if and foreach statements

* Use expression body in PersistentFSMBase.SetStateTimeout

* Fix some overzealous curly cleanup

* Fix wrong conditional

* Change all out variable type to var

marcpiechura added a commit to marcpiechura/akka.net that referenced this issue May 29, 2017

Change Dictionary.ContainsKey() + Dictionary[] combination to Diction…
…ary.TryGetValue() (akkadotnet#2651)

* Change all Dictionary.ContainsKey(key) + Dictionary[key] combination to Dictionary.TryGetValue(key, out value)

* Shuffle the code a bit so it makes more sense.

* Workaround for dotnet/cli#4783 (dotnet/cli#4783)

* Use new C# 7.0 out variable feature

* Code formatting
- Remove curly braces from single line if statements
- Add new line to single line if and foreach statements

* Use expression body in PersistentFSMBase.SetStateTimeout

* Fix some overzealous curly cleanup

* Fix wrong conditional

* Change all out variable type to var

zubialevich added a commit to zubialevich/InfoBot-Rest that referenced this issue Jun 5, 2017

Aaronontheweb added a commit to Aaronontheweb/akka.net that referenced this issue Jun 28, 2017

Change Dictionary.ContainsKey() + Dictionary[] combination to Diction…
…ary.TryGetValue() (akkadotnet#2651)

* Change all Dictionary.ContainsKey(key) + Dictionary[key] combination to Dictionary.TryGetValue(key, out value)

* Shuffle the code a bit so it makes more sense.

* Workaround for dotnet/cli#4783 (dotnet/cli#4783)

* Use new C# 7.0 out variable feature

* Code formatting
- Remove curly braces from single line if statements
- Add new line to single line if and foreach statements

* Use expression body in PersistentFSMBase.SetStateTimeout

* Fix some overzealous curly cleanup

* Fix wrong conditional

* Change all out variable type to var
@alexellis

This comment has been minimized.

Copy link

alexellis commented Aug 16, 2017

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 comment has been minimized.

Copy link

killyosaur commented Jan 10, 2018

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

This comment has been minimized.

Copy link

gwalschl commented Apr 14, 2018

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

This comment has been minimized.

Copy link
Member

nguerrera commented Apr 14, 2018

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

@rdhainaut

This comment has been minimized.

Copy link

rdhainaut commented Apr 19, 2018

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

This comment has been minimized.

Copy link
Author

frankbuckley commented Apr 19, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment