Skip to content
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 #7207

Closed
frankbuckley opened this issue Nov 19, 2016 · 13 comments
Milestone

Comments

@frankbuckley
Copy link

@frankbuckley 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
Copy link
Author

@frankbuckley frankbuckley commented Nov 19, 2016

Setting GenerateAssemblyInfo property to false fixes for all attributes:

<PropertyGroup>
  <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>
@TheRealPiotrP
Copy link
Contributor

@TheRealPiotrP TheRealPiotrP commented Nov 19, 2016

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

@frankbuckley
Copy link
Author

@frankbuckley 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
Copy link
Contributor

@TheRealPiotrP 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
Copy link

@atanasa 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
Copy link
Member

@dsplaisted dsplaisted commented Nov 25, 2016

@atanasa We do have granular attributes that let you enable or disable each automatically generated assembly attribute:

<GenerateAssemblyCompanyAttribute Condition="'$(GenerateAssemblyCompanyAttribute)' == ''">true</GenerateAssemblyCompanyAttribute>
<GenerateAssemblyConfigurationAttribute Condition="'$(GenerateAssemblyConfigurationAttribute)' == ''">true</GenerateAssemblyConfigurationAttribute>
<GenerateAssemblyCopyrightAttribute Condition="'$(GenerateAssemblyCopyrightAttribute)' == ''">true</GenerateAssemblyCopyrightAttribute>
<GenerateAssemblyDescriptionAttribute Condition="'$(GenerateAssemblyDescriptionAttribute)' == ''">true</GenerateAssemblyDescriptionAttribute>
<GenerateAssemblyFileVersionAttribute Condition="'$(GenerateAssemblyFileVersionAttribute)' == ''">true</GenerateAssemblyFileVersionAttribute>
<GenerateAssemblyInformationalVersionAttribute Condition="'$(GenerateAssemblyInformationalVersionAttribute)' == ''">true</GenerateAssemblyInformationalVersionAttribute>
<GenerateAssemblyProductAttribute Condition="'$(GenerateAssemblyProductAttribute)' == ''">true</GenerateAssemblyProductAttribute>
<GenerateAssemblyTitleAttribute Condition="'$(GenerateAssemblyTitleAttribute)' == ''">true</GenerateAssemblyTitleAttribute>
<GenerateAssemblyVersionAttribute Condition="'$(GenerateAssemblyVersionAttribute)' == ''">true</GenerateAssemblyVersionAttribute>
<GenerateNeutralResourcesLanguageAttribute Condition="'$(GenerateNeutralResourcesLanguageAttribute)' == ''">true</GenerateNeutralResourcesLanguageAttribute>

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
Copy link

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

Aaronontheweb referenced this issue in akkadotnet/akka.net May 22, 2017
…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 (https://github.com/dotnet/cli/issues/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 referenced this issue in marcpiechura/akka.net May 29, 2017
…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 (https://github.com/dotnet/cli/issues/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 referenced this issue in zubialevich/InfoBot-Rest Jun 5, 2017
Aaronontheweb referenced this issue in Aaronontheweb/akka.net Jun 28, 2017
…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 (https://github.com/dotnet/cli/issues/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
Copy link

@alexellis 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
Copy link

@killyosaur 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
Copy link

@gwalschl 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
Copy link
Member

@nguerrera nguerrera commented Apr 14, 2018

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

@rdhainaut
Copy link

@rdhainaut 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
Copy link
Author

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

juancarlostong referenced this issue in optimizely/csharp-sdk Mar 11, 2019
.csproj for NetStandard16 previously did not include AssemblyInfo.cs
which contains versioning information. Because of this, it used an
automatically generated one similar to the one described here:
https://github.com/dotnet/cli/issues/4783#issuecomment-382695175
We now provide the AssemblyInfo.cs to include during the build and
explicitly tell it not to autogenerate.
juancarlostong referenced this issue in optimizely/csharp-sdk Mar 29, 2019
.csproj for NetStandard16 previously did not include AssemblyInfo.cs
which contains versioning information. Because of this, it used an
automatically generated one similar to the one described here:
https://github.com/dotnet/cli/issues/4783#issuecomment-382695175
We now provide the AssemblyInfo.cs to include during the build and
explicitly tell it not to autogenerate.
juancarlostong referenced this issue in optimizely/csharp-sdk Mar 29, 2019
* fix(versioning): NetStandard16

.csproj for NetStandard16 previously did not include AssemblyInfo.cs
which contains versioning information. Because of this, it used an
automatically generated one similar to the one described here:
https://github.com/dotnet/cli/issues/4783#issuecomment-382695175
We now provide the AssemblyInfo.cs to include during the build and
explicitly tell it not to autogenerate.

* use own AssmeblyInfo.cs

* use full path

* better path
ecampidoglio referenced this issue in cake-contrib/Cake.Curl May 15, 2019
Since the assembly metadata is specified in the project file,
we don't want MSBuild to auto-generate the AssemblyInfo.cs files because
that will result in a compilation error (dotnet/cli#4783).
@msftgits msftgits transferred this issue from dotnet/cli Jan 31, 2020
@msftgits msftgits added this to the Discussion milestone Jan 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet