10

I am getting a code analysis error on my build server the error is

...NETFramework,Version=v4.6.AssemblyAttributes.cs(3,1): error CS8019:Unnecessary using directive.

This is in a Temp file which Visual Studio creates.

In my project I have "Suppress results from generated code (managed only)" ticked. I would have thought that would be enough.

But I still get the error on the server and locally i get none.

Any ideas?

sshine
  • 15,635
  • 1
  • 41
  • 66
MicroMan
  • 1,988
  • 4
  • 32
  • 58

3 Answers3

10
  1. Only setting the TargetFrameworkMonikerAssemblyAttributesPath property does not remove the warning. It relocates the file that generates the warning, which will prove useful.
  2. Setting the TargetFrameworkMonikerAssemblyAttributeText property does not work. It appears that this property is overwritten by the target that generates this file. (In MSBuild 14.0, the property is overwritten by the target _SetTargetFrameworkMonikerAttribute in the file Microsoft.CSharp.CurrentVersion.targets and is later being referred to in the target GenerateTargetFrameworkMonikerAttribute in file Microsoft.Common.CurrentVersion.targets.)
  3. (Working solution) Setting the TargetFrameworkMonikerAssemblyAttributesFileClean to false will prevent the file from being overwritten if it already exists. You can thus let the build script generate it, fix the using ...; lines manually, save it and see that it is not regenerated when rebuilding. At this point, placing the file in a non-temporary path makes sense.

    Adding the following to a SharedBuildScript.msbuild.xml file and referring to that within individual project files ensures that they all refer to the same single file:

    <PropertyGroup>
        <TargetFrameworkMonikerAssemblyAttributesFileClean>False</TargetFrameworkMonikerAssemblyAttributesFileClean>
        <TargetFrameworkMonikerAssemblyAttributesPath>$(MSBuildThisFileDirectory)SharedAssemblyAttributes.cs</TargetFrameworkMonikerAssemblyAttributesPath>
    </PropertyGroup>
    
sshine
  • 15,635
  • 1
  • 41
  • 66
  • This seems to work for .NET Framework only. Doing this while targeting .NET Standard does not seem to solve the issue. – Logerfo Jul 02 '19 at 13:56
  • 1
    That is good to know. Unfortunately I am not in a position to research what works under these circumstances. If you find a solution that works for .NET Standard, I'm sure it would be appreciated as an additional answer. :-) – sshine Jul 02 '19 at 14:22
7

Googling for CS8019 AssemblyAttributes yielded many interesting articles, such as this blog post. Quoting:

Fortunately for us, MSBuild is flexible enough so we can work around it. The good design is to generate this file into the Intermediate directory (usually called obj), because this is where all transient and temporary files should go during a build process. We can either set this property in our project file:

<PropertyGroup>
    <TargetFrameworkMonikerAssemblyAttributesPath>$([System.IO.Path]::Combine('$(IntermediateOutputPath)','$(TargetFrameworkMoniker).AssemblyAttributes$(DefaultLanguageSourceExtension)'))</TargetFrameworkMonikerAssemblyAttributesPath>
</PropertyGroup>

Or if your build uses a common .props file, set this property there. This will ensure that your build doesn’t depend on the TEMP directory and is more isolated, repeatable and incremental.

Michal Hosala
  • 5,570
  • 1
  • 22
  • 49
4

Michal's answer only partially helps here. Yes, you can redirect where that file is written but it will still violate the CS8019 rule.

You have two options:

  1. Also set the <TargetFrameworkMonikerAssemblyAttributeText> property to something that doesn't violate the rule. For instance:

    // &lt;autogenerated /&gt;
    [assembly: global::System.Runtime.Versioning.TargetFrameworkAttribute(&quot;$(TargetFrameworkMoniker)&quot;, FrameworkDisplayName = &quot;$(TargetFrameworkMonikerDisplayName)&quot;)]
    
  2. Or, redirect the file to someplace not temporary. In my case I chose to write it to the solution root so all projects would share the file. I then manually edited the file to remove the violations and committed the file along with the rest of my code. The file doesn't get overwritten if it already exists so this will generally be safe.

maxshuty
  • 9,708
  • 13
  • 64
  • 77
  • As neither of these suppressed the warnings, another solution is provided. – sshine Feb 22 '16 at 11:41
  • If I redirect the temp file to a fixed location and later update the .csproj file to target a new .net framework, the temp file WILL not get re-generated. – Ike Starnes Oct 02 '20 at 18:04