Sdk: Need better error message when generated assembly info collides with one in source.

[twsouthwick]

I usually generate assembly information (such as version, informational version, etc) with custom tasks. However, when trying to use these with the SDK, it fails with errors such as Duplicate 'AssemblyVersion' attribute. If I add <GenerateAssemblyInfo>false</GenerateAssemblyInfo> to the csproj it is built with no issue and my custom generated versions are available.

A simple way to reproduce this is to add the GitVersionTask to the project and attempt to build.

The SDKs I'm using are:

<PackageReference Include="Microsoft.NET.Sdk">
  <Version>1.0.0-alpha-20161104-2</Version>
  <PrivateAssets>All</PrivateAssets>
</PackageReference>
<PackageReference Include="Microsoft.NET.Sdk.Web">
  <Version>1.0.0-alpha-20161104-2-112</Version>
  <PrivateAssets>All</PrivateAssets>
</PackageReference>

[davidfowl]

That workaround seems fine to me. By default you get an assembly info and when you want take over, you turn of the generation. Maybe the gitversion targets needs an update to do this automatically.

[twsouthwick]

This is a regression from previous behavior - an even simpler repro is add the following to a file:

[assembly: System.Reflection.AssemblyInformationalVersion("test")]

This is how assembly information is added in all other .NET projects and is now broken with the new SDK without adding this property. The assembly level attributes should only be created if they are not already available.

[davidfowl]

There's lots of new things different about .NET projects with the new .NET CLI and new MSBuild. This is one of those changes. We can talk about having a more cooperative way to handle assembly info, but there is a new build task that does it by default in the new SDK.

The workaround is extremely simple. The upside of the new approach is that it allows version information to be specified in a single place (the csproj) and that information then flows to multiple sources:

• The nuget package (msbuild /t:Pack)
• The assembly info

If you don't want the latter, then I see no problem requiring that to be turned off if you want to take over.

[dsplaisted]

See also #254 and #302

It is easy to fix this if you know what properties to set, but when you run into the error you just get a compile error (error CS0579: Duplicate 'System.Resources.NeutralResourcesLanguage' attribute) which doesn't tell you anything about how to fix it. I'd like for us to display a better error message, telling people how to control the automatically generated assembly attributes. I'm not sure how feasible that is.

[twsouthwick]

Yeah, what @dsplaisted is more of the issue. The change makes sense, but it did block me for an hour or so while converting a project to this format. What about including <GenerateAssemblyInfo>true</GenerateAssemblyInfo> by default in the csproj template file? Then it would be (more) discoverable.

[davidfowl]

I'm morning a fan of every csproj having this extra property for discoverablity. That's why csproj is so bloated today. Wonder if we can have a better error message somehow....

[srivatsn]

Repurposing the issue to be about a better error message. The difficuly is that to produce that error message we wouldn't need to scan all files semantically for the attribute or teach the compiler about the generated attributes. There's perf implication for the former and layering implications for the latter.

[rkeithhill]

Perhaps we just need some guidance on the landing page for this error:

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/cs0579

I tried to add a community comment:

If you get this error on one of the Assembly-level attributes such as AssemblyCompanyAttribute in a .NET Core/Standard project, the error might be occurring because you are compiling a "ported" AssemblyInfo.cs file with these attributes. 

The new CSPROJ / MSBuild / SDK project system automatically generate these attributes which is why you get "duplicate attribute" errors when porting a project from the old build system to the new build system.  You can tell the new project system to skip auto-generating these attributes with <GenerateAssemblyInfo>false</GenerateAssemblyInfo>.

But the site wouldn't accept my Hotmail account. Go figure. Anyway, I think this would be enough to address the issue.