Core: Compiling ASP.NET web app with AssemblyInfo.cs in a shared project ends with a warning

[mareklinka]

I upgraded my local .NET Core SDK from version 2.1.201 to 2.1.300. After upgrade, the build process started reporting a warning for one of our web projects:

CA1016: Assemblies should be marked with AssemblyVersionAttribute

The setup of our solution is not entirely straight-forward in regards to AssemblyInfo.cs files. We have a shared project containing an AssemblyInfo.cs with the common properties and then each project, including the failing one, has its own.

Common file:

using System;
using System.Reflection;
using System.Resources;
using System.Runtime.InteropServices;

[assembly: AssemblyVersion("0.20.0.0")]
[assembly: AssemblyFileVersion("0.20.0.0")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyCompany("ERNI")]
[assembly: AssemblyCopyright("...")]
[assembly: AssemblyTrademark("")]
[assembly: NeutralResourcesLanguage("en")]
[assembly: CLSCompliant(false)]
[assembly: ComVisible(false)]

Specific file for the failing project:

using System.Reflection;

[assembly: AssemblyTitle("name")]
[assembly: AssemblyProduct("name")]

All projects have GenerateAssemblyInfo set to false. This setup worked correctly before updating to .NET Core SDK 2.1.300. After I upgraded, the build started reporting the warning above. We usually have TreatWarningsAsErrors set to true, so the build broke on the warning.

I managed to trace the problem down to the presence of Razor views in the failing project - if I remove them, the project builds correctly. This leads me to an assumption that the new build-time compilation of views is the culprit here. Is the compiler, per chance, generating a separate assembly for the views? It looks like the compiler will not include the AssemblyInfo from the shared project in this new assembly and it will fail the analyzers in Microsoft.CodeAnalysis.FxCopAnalyzers.

I'm attaching a minimal repro solution that demonstrates the issue:
ViewCompilationIssue.zip

This code will fail to build due to the TreatWarningsAsErrors. If you exclude the Views folder from the project, it compiles.

We can work around the issue by either rewriting our assembly infos or changing the analyzer rules but this seems like a regression to me so I wanted to report it.

[dasMulli]

cc @pranavkm @rynowak looks like https://github.com/aspnet/Razor/pull/2272/files didn't catch that '$(GenerateAssemblyVersionAttribute)' == 'true' will still evaluate to false because the SDK targets only define those individual properties when GenerateAssemblyInfo is set to true (see SDK targets) thus causing a warning about missing AssemblyVersionAttribute to be generated which fails the build on TreatWarningsAsErrors==true.

[pranavkm]

Is the compiler, per chance, generating a separate assembly for the views?

Yes. The Sdk does pick up the side-effects of GenerateAssemblyInfo correctly. But you see the build warning \ error since it's no longer adding a version to the assembly. If you were to add the shared AssemblyInfo to the list of files added to Razor compilation, things build:

 <!-- SharedProject1.projitems -->
 <ItemGroup>
    <Compile Include="$(MSBuildThisFileDirectory)AssemblyInfo.cs" />
    <RazorCompile Include="$(MSBuildThisFileDirectory)AssemblyInfo.cs" />
  </ItemGroup>

[mareklinka]

I added the RazorCompile property on our shared project and now we can compile without issues. Thanks!

Just out of curiosity, is this the expected behavior or will this change in a future version?

[pranavkm]

Just out of curiosity, is this the expected behavior or will this change in a future version?

I'd think this is expected behavior - with RazorCompileOnBuild or RazorPublishOnBuild enabled, you're effectively getting two binaries per project - one for the app and one for Razor views. They compile different sets of files but we want to share meaningful properties, like versions, between the two assemblies. Our thought was that turning off assembly info for the main one should also disable it for the compiled view, you're more than likely doing something not standard.

If there's a better approach we could take to addressing this, we'd be happy to consider it. Feel free to file an issue in https://github.com/aspnet/Razor/issues with suggestions.

[mareklinka]

Fair enough. Thanks for the clarification, if we can think of something, we'll file it.

[Mattacks]

It can't be expected behaviour to upgrade from .Net Core 2 to 2.1 and get this compilation error!