Duplicate AssemblyVersion Attribute

Question

I have a project that generates following error on compilation:

error CS0579: Duplicate 'AssemblyVersion' attribute

I have checked the file AssemblyInfo.cs and it looks like there is no duplication there.

I found this article on MSDN which addresses a similar problem and following the suggestion in this article fixes the problem as well.

Can anyone tell me what's going on here? Does it happen only in case of having two or more projects with classes having similar names? Or is it something else?

just a guess but, did you try close and that opening the solution again? perhaps that might solve it? — Stefto, Apr 25 '12 at 07:42
If converting a project to .NET Core , see https://elanderson.net/2017/06/duplicate-system-reflection-assemblycompanyattribute-attribute/ — Michael Freidgeim, Sep 07 '17 at 11:42
I am using Visual Studio 2017 Community edition on the Mac. I had a console app and then I added a reference to a new class library project. These errors started showing up when I did a build. All I did was remove the reference to the class library project and then add it back and the errors went away. — Flea, Feb 26 '19 at 15:21

score 351 · Answer 1 · edited Sep 09 '17 at 07:02

351

Starting from Visual Studio 2017 another solution to keep using the AssemblyInfo.cs file is to turn off automatic assembly info generation like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
  </PropertyGroup>
</Project>

I personally find it very useful for projects which need to support both .NET Framework and .NET Standard.

edited Sep 09 '17 at 07:02

Michael Freidgeim

26,542
16
152
170

answered Jun 12 '17 at 15:05

Serge Semenov

9,232
3
23
24

5

Yes that worked for me, deleting the obj and bin folders wasn't enough. – Nick Josevski Jun 14 '17 at 04:08
1

Unfortunately, every time I change the `.csproj` file using its property pages (Application, Build, Build Events, etc.), the `PropertyGroup` with the `GenerateAssemblyInfo` disappears :-( – Palo Mraz Oct 18 '17 at 07:42
3

Move it into a Directory.Build.props file – Bryan Sep 14 '18 at 14:17
7

Is there any risk or negative outcome possible with this solution? – mrcoulson Feb 20 '19 at 19:16
1

@PaloMraz It seems that provided you're using a modern "SDK-style" csproj file, that modern versions of Visual Studio 2019 (e.g. 16.9.x) will preserve manual changes in the csproj file. – Dai Apr 22 '21 at 07:50
YES! Thanks. I wanted to USE the `AssemblyInfo.cs` attributes, not the auto-generated ones. This answer allows me to do that. – Jesse Chisholm Jul 21 '21 at 21:49
4

So why is this not the default? What is GenerateAssemblyInfo required for? What did I just break by setting it to false? – Heinzlmaen Feb 01 '22 at 10:38

score 194 · Accepted Answer · edited Nov 26 '19 at 20:52

194

I have also run into this issue in the past, so I am going to assume that your build process provides assembly information separately to providing versioning. And that causes a duplication as your project also has that info in the AssemblyInfo.cs file. So remove the file and I think it should work.

edited Nov 26 '19 at 20:52

WalterGR

311
3
13

answered Apr 25 '12 at 09:15

luqi

2,779
2
18
14

5

So, Shouldn't build process overwrite the existing AssemblyVersion instead of creating a new entry? I know that our build process does that but I am curious that why it doesn't overwrite the existing one. Is it badly implemented or is it a limitation? – Aamir Apr 25 '12 at 09:18
I think for .net assemblys the better way would be to use version injection method. But thats a seperate story. In your case the problem is there are different ways of providing assembly versions, through cmdline build parameters and through AssemblyInfo.cs and you have to make sure that only one method is being used as duplication of attributes is a .net compilation error. – luqi Apr 25 '12 at 09:32
remove what exactly? – roberto tomás Feb 09 '20 at 23:53
1

Removing the AssemblyInfo.cs file fixed my issue. – Sanushi Salgado May 19 '21 at 12:12
1

I voted for this answer as it lead me to the best solution. The answer by "Serge Semenov" is also correct. One can selectively suppress the generation of the duplicities by false based on the the situation. In my case it was the debug profile. – Pepik Mar 14 '23 at 00:12

heringer · Answer 3 · 2022-09-03T22:14:28.663

41

In my case, there where a subfolder in a project that was a project folder it self:

file system:
- c:\projects\webapi\wepapi.csproj
- c:\projects\webapi\tests\wepapitests.csproj
solution
- webapi (folder and project)
  - tests (folder)
tests (folder and project)

Then i had to remove the subfolder "tests" from the "webapi" project.

EDIT 2022: Just to be more clear, as @bobt mentioned in the commentaries, by "remove" I meant: to right click the "tests" folder inside webapi and choose the option "exclude from project".

edited Sep 03 '22 at 22:14

answered Dec 12 '17 at 12:25

heringer

2,698
1
20
33

I had removed the subproject from the solution, but the subdirectory and files were still sitting there. Removing them finally fixed the problem. – tobbenb3 Nov 05 '21 at 10:52
3

Right click on the folder in Solution Explorer and choose "Exclude from Project". This way you don't have to restructure your folders. – bobt Sep 02 '22 at 23:54
You are right, @bobt, that is what I meant. I edited the answer to make it clear, thanks! – heringer Sep 03 '22 at 22:15
you can also set test project path in .sln file like (..\test......) – Akbar Asghari Dec 07 '22 at 20:01

score 23 · Answer 4 · answered Sep 07 '17 at 11:57

23

When converting an older project to .NET Core, most of the information that was in the AssemblyInfo.cs can now be set on the project itself. Open the project properties and select the Package tab to see the new settings.

The Eric L. Anderson's post "Duplicate ‘System.Reflection.AssemblyCompanyAttribute’ attribute" describes 3 options :

remove the conflicting items from the AssemblyInfo.cs file,
completely delete the file or
disable GenerateAssemblyInfo (as suggested in another answer by Serge Semenov)

answered Sep 07 '17 at 11:57

Michael Freidgeim

26,542
16
152
170

I find it more intuitive and more "Visual Studio" to specify these attributes in the project (`.csproj`), because they are metadata instead of code that describe actual logic. I hope in future everything can be specified in the project! (Currently I cannot specify COM visibility, so I leave it in `AssemblyInfo.cs`.) – Franklin Yu Dec 08 '17 at 16:06

score 22 · Answer 5 · edited Jan 18 '23 at 00:12

22

I had the same error and it was underlining the Assembly Version and Assembly File Version so reading Luqi answer I just added them as comments and the error was solved

// AssemblyVersion is the CLR version. Change this only when making breaking    changes
//[assembly: AssemblyVersion("3.1.*")]
// AssemblyFileVersion should ideally be changed with each build, and should help identify the origin of a build
//[assembly: AssemblyFileVersion("3.1.0.0")]

edited Jan 18 '23 at 00:12

Sylvain Rodrigue

4,751
5
53
67

answered Jun 25 '15 at 21:46

Pantelitsa Mavrovounioti

495
4
14

1

I tried this, and it changed nothing in my case :-( – Gertsen Jul 17 '19 at 11:33

score 18 · Answer 6 · answered Apr 16 '20 at 12:11

18

There must be already a AssemblyInfo.cs file in the project here:

To solve: - Delete any one AssemblyInfo.cs

answered Apr 16 '20 at 12:11

Tejas Katakdhond

275
3
5

score 14 · Answer 7 · edited Apr 28 '21 at 16:50

I came across the same when tried add GitVersion tool to update my version in AssemblyInfo.cs. Use VS2017 and .NET Core project. So I just mixed both worlds. My AssemblyInfo.cs contains only version info that was generated by GitVersion tool, my csproj contains remaingin things. Please note I don't use <GenerateAssemblyInfo>false</GenerateAssemblyInfo> I use attributes related to version only (see below). More details here AssemblyInfo properties.

AssemblyInfo.cs

[assembly: AssemblyVersion("0.2.1.0")]
[assembly: AssemblyFileVersion("0.2.1.0")]
[assembly: AssemblyInformationalVersion("0.2.1+13.Branch.master.Sha.119c35af0f529e92e0f75a5e6d8373912d457818")]

my.csproj contains all related to other assembly attributes:

<PropertyGroup>
   ...
  <Company>SOME Company </Company>
  <Authors>Some Authors</Authors>
  <Product>SOME Product</Product>
   ...
  <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>
  <GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute>
  <GenerateAssemblyInformationalVersionAttribute>false</GenerateAssemblyInformationalVersionAttribute>
</PropertyGroup>

score 11 · Answer 8 · answered Feb 26 '16 at 00:56

In my case, some temporary *.cs files generated during compilation got accidentally added to the project.

The files were from the obj\Debug directory, so they definitely shouldn't have been added to the solution. A *.cs wildcard went a little crazy and added them incorrectly.

Deleting these files fixed the problem.

score 5 · Answer 9 · answered Mar 23 '17 at 16:09

5

My error occurred because, somehow, there was an obj folder created inside my controllers folder. Just do a search in your application for a line inside your Assemblyinfo.cs. There may be a duplicate somewhere.

answered Mar 23 '17 at 16:09

Dwayne Love

323
3
10

Similarly, I had a .csproj file (A) inside another folder belonging to another .csproj (B). – taylorswiftfan Feb 22 '19 at 21:00

score 4 · Answer 10 · answered Jan 17 '14 at 12:15

4

For me it was that AssembyInfo.cs and SolutionInfo.cs had different values. So check these files as well. I just removed the version from one of them.

answered Jan 17 '14 at 12:15

Mariusz.W

1,347
12
19

score 4 · Answer 11 · answered Jan 22 '21 at 19:36

I ran into this recently with no changes to source, but after experimenting with some new project references. I got into a state where this error was appearing even after reverting all changes in the branch.

Cleaning the branch resolved it for me:

git clean -xfd

AnonymouseITManFromUS · Answer 12 · 2022-06-17T16:24:13.143

When you create a project, Visual Studio sets it up to compile & generate a corresponding assembly. Each project generates 1 assembly, and so each has a corresponding assembly configuration to generate its assembly from.

The problem is when you create more than one project that each can generate their own assembly, and then include one of these projects in the other.

In this scenario, Visual Studio gets confused and doesn't know which config file to go off of to generate the single assembly for the project -- it finds the second assembly configuration in the included project and says "HEY, DUPLICATE! You've given me two sets of instructions for generating my assembly!"

But sometimes you still want the included project to be able to generate an assembly on it's own, but not when it is being included in another project.

To obtain this, one solution is to add conditional defines to the including project (found in project Properties). Then change the assembly config in the included project to look for this conditional define. If it is defined (by the including project), then the config can skip over it's content -- this will result in only 1 config found by VS -- the one from the including project -- problem solved!

Steps Below (screenshots included)

Step 1: Select the including/container Project > Right Click > Properties

Project properties (screenshot)

Step 2: Navigate to Build > General > Conditional compilation symbols

Add your conditional defines as shown:

Conditional compilation symbols (screenshot)

Step 3: Use conditional defines in the included project AssemblyInfo.cs

Using conditional defines (screenshot)

This all sounds right but I'm having a hard time finding settings in the project properties in VS2022. I've looked at the csproj as well but I'm not sure where or what lines to add to conditionally or unconditionally remove the assembly from the encompassing solution — Glenn, Apr 27 '22 at 16:18
I added the steps with screenshots in my OP. This should make it easier to find your way around :) — AnonymouseITManFromUS, Jun 17 '22 at 16:19

score 2 · Answer 13 · answered Oct 19 '17 at 07:56

2

Yet another solution when upgrading core to VS2017 is to remove them in the properties\assemblyinfo.cs file.

Since they now are stored in the project.

answered Oct 19 '17 at 07:56

Thomas Koelle

3,416
2
23
44

score 2 · Answer 14 · answered Dec 25 '18 at 02:10

This usually happens for me if I compiled the project in Visual Studio 2017 & then I try to rebuild & run it with .NET Core with the command line command "dotnet run".

Simply deleting all the "bin" & "obj" folders - both inside "ClientApp" & directly in the project folder - allowed the .NET Core command "dotnet run" to rebuild & run successfully.

score 2 · Answer 15 · answered Jul 15 '21 at 16:55

2

You can remove bin and obj file and clear the cache of the project. My issue was fixed from that.

answered Jul 15 '21 at 16:55

Adithya

265
4
9

score 2 · Answer 16 · edited Nov 02 '21 at 19:54

In my case, one of my colleagues had removed a Console App used for testing purposes, that was placed in the same directory as our Api, and then committed to Git. When I later pulled from Git, the console app itself was ofcourse gone, but it's bin and obj folders was still there, resulting in the AssemblyInfo.cs file being present in both the root application dir and the subdir for the old console app. Simply removing the bin and obj folders for the old console app resolved the issue.

ASP.NET Core 3.1

score 1 · Answer 17 · answered Jan 29 '19 at 16:38

I found this answer on msdn, that explains marking the file as Content and then Copy to Output = If Newer. See article below:

https://social.msdn.microsoft.com/Forums/en-US/8671bdff-9b16-4b49-ba9e-227cc4df31b2/compile-error-cs0579-duplicate-assemblyversion-attribute?forum=vsgatk

GH

score 1 · Answer 18 · answered Jun 09 '19 at 20:46

Edit you AssemblyInfo.cs and #if !NETCOREAPP3_0 ... #endif

using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.

#if !NETCOREAPP3_0  

[assembly: AssemblyTitle(".Net Core Testing")]
[assembly: AssemblyDescription(".Net Core")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("")]
[assembly: AssemblyProduct(".Net Core")]
[assembly: AssemblyCopyright("Copyright ©")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]

// Setting ComVisible to false makes the types in this assembly not visible
// to COM components.  If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]

// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("000b119c-2445-4977-8604-d7a736003d34")]

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

#endif

score 1 · Answer 19 · answered Oct 17 '19 at 08:46

1

I got this error when I did put 2 projects in the same directory. If I have a directory with an solution and I put a separate Web and Data directory in it compiles right.

answered Oct 17 '19 at 08:46

Herman Van Der Blom

718
9
20

score 1 · Answer 20 · answered Nov 12 '19 at 00:14

1

I had this issue when my main project was in the same folder as the solution, then I had a separate project in the same solution located in a sub folder, and that separate project used the main project as a reference. This caused the main project to detect the sub folder bin & obj folders which created duplicate references.

answered Nov 12 '19 at 00:14

Mark Entingh

621
6
10

This helped me out a lot! One project referenced another as a build-time dependency, but a bug in the csproj caused the obj folders to be different, generating this error. – Chad Jessup Jan 15 '20 at 18:16

score 1 · Answer 21 · answered Jan 24 '20 at 14:19

1

If you're having this problem in a Build Pipeline on Azure DevOps, try putting the Build Action as "Content" and Copy to Output Directory equal to "Copy if newer" in the AssembyInfo.cs file properties.

answered Jan 24 '20 at 14:19

Marcello Teófilo Fonteles

46
2

score 1 · Answer 22 · edited Dec 25 '20 at 03:24

1

I got the error Just after switching from .NET Framework to .NET Core. I have 2 class library projects in my Visual Studio solution. I realized that 1 of the projects has a file named AssemblyInfo.cs while the other project does not have the file. The file is located under the Properties folder. I simply delete the Properties folder and all works fine.

edited Dec 25 '20 at 03:24

Michael Arkhipov

737
8
19

answered Dec 24 '20 at 23:38

Felix Augustin

11
1

score 1 · Answer 23 · answered Feb 12 '21 at 14:26

I have being struggling with this issue, but my problem was much easier to solve.

I had copied OBJ folder to "OBJ___" name to do some compilation tests.

So, I don't know why, this folder was being also compiled, creating the assembly attributes duplication.

I simply deleted the "OBJ___" folder and could compile successfuly.

score 1 · Answer 24 · answered Dec 23 '21 at 07:17

1

I got these errors because I tried to temporarily rename the obj folder to obj_, and then it's included in the project automatically. Then the assembly.cs in it began to fight with the right one in obj folder generated later.

answered Dec 23 '21 at 07:17

cheny

2,545
1
24
30

score 0 · Answer 25 · answered Mar 16 '17 at 10:38

My error was that I was also referencing another file in my project, which was also containing a value for the attribute "AssemblyVersion". I removed that attribute from one of the file and it is now working properly.

The key is to make sure that this value is not declared more than once in any file in your project.

score 0 · Answer 26 · edited Mar 17 '20 at 21:56

obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(15,12): error CS0579: Duplicate 'System.Reflection.AssemblyConfigurationAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(16,12): error CS0579: Duplicate 'System.Reflection.AssemblyFileVersionAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(17,12): error CS0579: Duplicate 'System.Reflection.AssemblyInformationalVersionAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(18,12): error CS0579: Duplicate 'System.Reflection.AssemblyProductAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(19,12): error CS0579: Duplicate 'System.Reflection.AssemblyTitleAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(20,12): error CS0579: Duplicate 'System.Reflection.AssemblyVersionAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]

I believe my Library folder was corrupted by an inadvertent creation of another class library.I deleted the library an all associated file but the problem persisted. I found a workaround by deleting ALL bin and obj folders in the directory. The build was ok previously but found a subfolder that had the same assemblyinfo.cs file.

score 0 · Answer 27 · answered Apr 01 '20 at 12:44

This issue is a reference conflict which is mostly peculiar to VS 2017.

I solved this same error by simply commenting out lines 7 -14 as well as Assembly version codes at the bottom of the page on AssemblyInfo.cs

It removed all the duplicate references and the project was able to build again.

score 0 · Answer 28 · answered Sep 10 '21 at 14:07

I just helped a team member resolve this issue by renaming the repo folder the re-cloning the repo. This was only an issue for one developer as everyone else on the team was able to build master without hitting this error so we knew the problem wasn't an issue in source.

We did try deleting bin and obj folders and doing a git clean -xfd but neither of those resolved the issue. Starting fresh with a clean copy of the repo did the trick in this case.

score 0 · Answer 29 · answered Oct 02 '21 at 21:10

0

I've being struggling with this issue too. In my case ,I had put solution and project in a same place .So I had problem .After I chose a folder for solution and put the project in this solution ,it worked properly.

answered Oct 02 '21 at 21:10

Ali Mahdian

59
4

score 0 · Answer 30 · answered Jul 18 '22 at 10:30

I had the same problem when I changed my folder structure and tried to push. Git told me I had to pull first and I did. That duplicated my source code in the old folder and the new one, so lots of duplication errors came up at build time.

Simply removing the duplicated folders resolves the issue.

score 0 · Answer 31 · answered Jan 13 '23 at 06:12

0

I had the same error in my project on the .NET Framework solved the problem by deleting in the project folder packages/GitVersion*

answered Jan 13 '23 at 06:12

Arthas

15
5

Duplicate AssemblyVersion Attribute

31 Answers31

Steps Below (screenshots included)

Linked