sdk: Duplicate 'System.Reflection.AssemblyCompanyAttribute' attribute

In my case I need to remove bin and obj folders after any change, do restore and then build. This fixed issue.

I think the name might have changed? <GenerateAssemblyInfo>false</GenerateAssemblyInfo> does seem to work.

Ran into that myself when already having a Properties\AssemblyInfo.cs in the project with an [assembly: AssemblyCompany("..")] attribute. The SDK now has targets that emit these attributes to a generated AssemblyInfo.cs that is included during build. (Here) If this is indeed your problem, you can either move all existing Attributes to the .csproj by adding a <Company>Evilcorp</Company> property or suppress the generation of the attribute by specifying <GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>.

in my case, deleting Properties/AssemblyInfo.cs did the trick.

Why not just set GenerateAssemblyInfo to false in the PropertiesGroup in your project file? The .targets file mentioned above has a condition on this property that determines whether those properties are set.

<GenerateAssemblyInfo>false</GenerateAssemblyInfo>

@cmooring I also had this occur when doing a dotnet new web -o mywebapp tutorial in VS Code…

Very bizarre first experience as all I did was just use the command line tool to create a new app. And it created it with problems?

Full list of issues is below:

I’ve just found this same issue when playing around with dotnet core and vscode.

I have dotnet core version 2.1.300 and vs code version 1.23.1 with Microsoft’s C# extension installed.

I simply run the following in an empty directory; dotnet new mvc code .

Wait until the C# extension offers to add my launch and tasks json files and then hit F5 to debug the default app that is created. At some point after doing nothing more than opening and closing the code, I find I have 7 errors

@TheRealPiotrP - back to your point about fixing the user experience around this, is this something that will likely be addressed? It doesn’t impact my ability to continue exploring, but it might impede adoption if simple things like that throw up errors.

Just to chime in on this in the hope of possibly helping someone in the future, what caused the problem for me was when I changed the target framework of my library from netcoreapp2.1 to netstandard3.0. After trying to compile my lib with dotnet build -c Debug, it turned out that every single attribute in the AssemblyInfo.cs was marked as ‘duplicate’. I simply deleted the obj directory and recompiled successfully. Also if you’re using VSCode with Omnisharp, you’ll probably just have to hit Ctrl + Shift + P to bring up the command palette, and execute the OmniSharp Restart OmniSharp command to get rid of the errors in VSCode.

Oh I completely missed the razor part. I believe you need to set

<PropertyGroup>
  <EnableDefaultRazorTargetAssemblyInfoAttributes>false</EnableDefaultRazorTargetAssemblyInfoAttributes>
</PropertyGroup>

in the .csproj file.

If you have more issues with it, think this is too complex or it doesn’t behave as expected, file an issue over at https://github.com/aspnet/Razor

This is a very old issue that has since been closed. If this is consistent for you, I would suggest filling a separate new issue for it, though, I just tried it and could not repro it.

Does this happen to you when doing a dotnet build from the command line? If so, could you provide a binary log of your build for us to investigate?

This is the only place I’ve been able to find this information. It would be nice if it was part of the documentation.

I deleted the bin directory, obj directory and the AssemblyInfo.cs file in the Properties directory.

Ran dotnet restore then build and it fixed the issue.

I had the same problem like you guys and a solved deleting all the obj folder on my project and adding this command inside of the all cs.proj on my project, then I run dotnet restore and dotnet build .

I am using vscode with dotnetcore3.1 and dotnet stantard2.0

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

@TroyWitthoeft are you creating projects inside of the directory of other projects? That is currently blocked because the default csproj file assumes all content to be part of the project itself. so once you fix the assembly attribute issues, you’ll get missing references because all the nested project’s .cs files will be imported as well.

In this case you should rather exclude these directories from the “outer” project:

  <PropertyGroup>
    <DefaultItemExcludes>$(DefaultItemExcludes);innerproject\**</DefaultItemExcludes>
  </PropertyGroup>

Changing the behavior to opt-in would be a beraking change, because projects that don’t have an assembly info source file would loose metadata information.

Will the error reported by the build be updated? It’s currently unclear one has to add a GenerateAssemblyInfo element to the csproj manually. In fact, if I hadn’t found this github issue I might have never known about it. 😄 (I ran into the same issue as others in this thread: duplicate assemblyinfo attributes as I too use a shared cs file among all projects of my system)

Here is the code: https://github.com/dotnet/sdk/blob/release/2.0.0/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.GenerateAssemblyInfo.targets#L26.

The one you reference above can be used to prevent a whole set of the properties from being turned on by default. But notice that if something else sets them to true, setting the one above will not set them to false. Just keep that in mind.

@SamvelS I see. So you have:

/myproj
  /myproj.csproj
  /myinnerproj
    /myinnerproj.csproj

Is that right? Then for the first issue, you should be able to modify your myproj.csproj’s compile Items like this:

  <Compile Include="**\*.cs" Exclude="bin\**;obj\**;myinnerproj\**.*" />

You may need to play with the glob a little, but this will allow the outer project to ignore the sources of the inner project.

RE the <OuputType> issue can you create a bug with a repro? CLI build generates many EXE’s and we’ve not seen such a problem so far…

@piotrpMSFT I didn’t specify any argument at all. Everything is what was generated. The problem was with inner project. I was trying to create solution like structure, created inner folder (on same directory as root csproj file) and added new project to it. After that first was building inner project (which was generating bin and obj folders) and after that root project. I removed inner bin/obj folders and started to build only root. Also deleting bin/obj folders every time I need to call ‘dotnet restore’. I was thinking that I will need to add reference to inner project but it is working without adding anything to root folder, which can cause lots of issues as on .Net many projects in solution can have classes with same name and in same namespace but here it can’t happen. One more issue is that on version 1.0.0-preview4-004079 <OutputType>Exe</OutputType> is not considered and it is always generating DLL instead of exe.

I am using this to remove duplicated attributes messages (Core 3.1):

<PropertyGroup>
  <GenerateAssemblyInfo Condition=" '$(Configuration)' == 'Debug' ">false</GenerateAssemblyInfo>
  <Product>qwe</Product>
  <Company>asd</Company>
  <Authors>zxc</Authors>
  etc from https://docs.microsoft.com/dotnet/core/tools/csproj
</PropertyGroup>

Looking at 4783, it seems this is by design? Are we sure this is what we want? Would we consider changing the default behavior of the CLI to NOT generate AssemblyInfo.cs file? Let developers opt-in to this behavior? I understand we want the csproj file to be terse. But this default behavior is having the opposite effect. Folks are now adding

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

everywhere. Check the bottom of 4783 for examples. Should we not be moving away from Assembly Info? Let’s make it opt-in by default! This would encourage folks to have more complex projects and use more of the cli. For instance, my team is trying to get into unit testing. So we …

dotnet new console dotnet new xunit --name MyTests cd MyTests dotnet build cd.. dotnet build

The steps above yield a nicely abstract CS5079 error and their projects are slowed. Is having the AssemblyInfo by default more important than encouraging composition, unit testing, and subprojects?

I was getting this error on a project with multiple target frameworks. The problem was that AssemblyInfo.cs was being generated multiple times, one for each target framework. The solution was to disable the auto-generation on all frameworks but one.

<PropertyGroup>
  <TargetFrameworks>netcoreapp3.0;</TargetFrameworks>
  <GenerateAssemblyInfo>true</GenerateAssemblyInfo>
</PropertyGroup>

<PropertyGroup>
  <TargetFrameworks>net46;</TargetFrameworks>
  <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>

<PropertyGroup>
  <TargetFrameworks>netcoreapp2.1</TargetFrameworks>
  <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>

Interesting… if so the repo for the C# extension would be https://github.com/OmniSharp/omnisharp-vscode

Same Issue here with <TargetFramework>netcoreapp2.1</TargetFramework> and VS Code 1.25.0.

@FransBouma FYI https://github.com/dotnet/sdk/issues/438

What happened to this property? <GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>

I just updated VS 2017 Preview today and I tried this property and it doesn’t work. What’s more I don’t see it in the project file Intellisense list.

@piotrpMSFT So i just gave the migration code that parses the AssemblyInfo.cs a short test to try to reproduce my former issue. The migration fails with the following attributes (using the full namespace and/or the “Attribute” suffix):

[assembly: System.Reflection.AssemblyCompany("fooo")]
[assembly: System.Reflection.AssemblyProduct("TestApp")]
[assembly: System.Reflection.AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersionAttribute("1.0.0.0")]

used dotnet version was 1.0.0-preview3-004056. I’ll try with the latest preview4 in a few minutes (sloooow download here in austria).