Sdk: dotnet pack does not respect assembly atttributes

[Petermarcu]

@junalmeida commented on Tue Jan 09 2018

Issue Title

Compiling and packing using Visual Studio 2017 or dotnet pack does not respect assembly attributes while using AssemblyInfo.cs

General

Using the following csproj structure:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <AssemblyName>Alma.Core</AssemblyName>
    <RootNamespace>Alma.Core</RootNamespace>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
  </PropertyGroup>

When building the project, binaries are generated correctly with my attributes from .cs file, but nuget package is wrong:

[dasMulli]

msbuild-integrated NuGet takes its version from the PackageVersion property which is - unless set explicitly - set to whatever VersionPrefix or Version is set to.
It does not read the attributes of the built assembly/ies.

A workaround which works only using full-framework msbuild (msbuild command line or in vs) - as I posted on https://stackoverflow.com/questions/47818235/msbuild-tpack-nuget-package-has-allways-the-same-version/47819996#47819996 - is to add the following to the csproj file:

<Project>

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
    <GenerateNuspecDependsOn>$(GenerateNuspecDependsOn);ReadPackageVersionFromOutputAssembly</GenerateNuspecDependsOn>
  </PropertyGroup>

  <Target Name="ReadPackageVersionFromOutputAssembly" DependsOnTargets="Build">
    <GetAssemblyIdentity AssemblyFiles="$(TargetPath)">
      <Output TaskParameter="Assemblies" ItemName="PackAssembly" />
    </GetAssemblyIdentity>
    <PropertyGroup>
      <PackageVersion>%(PackAssembly.Version)</PackageVersion>
    </PropertyGroup>
  </Target>

</Project>

for a multi-targeting project (https://stackoverflow.com/questions/48065516/build-project-with-multiple-targetframeworks-in-tfs-as-nuget-package/48069440#48069440):

<Target Name="ReadPackageVersionFromOutputAssemblySingleTfm" Returns="@(PackAssembly)" Condition="'$(IsCrossTargetingBuild)' != 'true'">
  <GetAssemblyIdentity AssemblyFiles="$(TargetPath)">
    <Output TaskParameter="Assemblies" ItemName="PackAssembly" />
  </GetAssemblyIdentity>
  <PropertyGroup>
    <PackageVersion>%(PackAssembly.Version)</PackageVersion>
  </PropertyGroup>
</Target>

<Target Name="ReadPackageVersionFromOutputAssemblyMultipleTfms" Condition="'$(IsCrossTargetingBuild)' == 'true'">
  <PropertyGroup>
    <FirstTargetFramework>$([System.String]::Copy($(TargetFrameworks)).Split(';').GetValue(0))</FirstTargetFramework>
  </PropertyGroup>
  <MSBuild Projects="$(MSBuildProjectFullPath)" Targets="ReadPackageVersionFromOutputAssemblySingleTfm" Properties="TargetFramework=$(FirstTargetFramework)">
    <Output TaskParameter="TargetOutputs" ItemName="PackAssembly" />
  </MSBuild>
  <PropertyGroup>
    <PackageVersion>%(PackAssembly.Version)</PackageVersion>
  </PropertyGroup>
</Target>

<Target Name="ReadPackageVersionFromOutputAssembly" DependsOnTargets="Build;ReadPackageVersionFromOutputAssemblySingleTfm;ReadPackageVersionFromOutputAssemblyMultipleTfms">

[livarcocc]

@rohit21agrawal should I move this issue to nuget?

@dasMulli as always, thank you very much for the reply.

[rohit21agrawal]

@livarcocc I don't think nuget reading from the aseemblyinfo file is a good idea, given how pack is written, all our inputs should come from msbuild properties. I would hope that SDK would be in a much better position to translate assemblyinfo properties to msbuild properties.

[livarcocc]

@rohit21agrawal who does the work is something that can be discussed and figure out later. I am wondering if it even makes sense for pack to pick up the AssemblyVersion for the Package version. And in what circumstance. I am not comfortable designing that interaction and going around pack for it. Independently of where the code lives.

[rohit21agrawal]

@livarcocc my point was that even if we do want to design the scenario where a package version should be equal to AssemblyVersion, the AssemblyVersion should be fed to pack using an msbuild property, rather than parsing the value from the AssemblyInfo.cs file.

Regardless, I just remembered that an AsssemblyInfo.cs file should not really be required, because setting an AssemblyVersion can be achieved in a csproj file as well. Here is how NuGet does it for it's projects:

https://github.com/NuGet/NuGet.Client/blob/dev/build/common.project.props#L168-L209

[junalmeida]

@dasMulli your solution resolves the assembly version. What about title, description, etc?
I used to work with a nuspec like this:

    <id>$id$</id>
    <version>$version$</version>
    <title>$id$</title>
    <authors>$author$</authors>
    <owners>$author$</owners>
    <licenseUrl>https://myhost/license</licenseUrl>
    <projectUrl>https://myhost</projectUrl>
    <iconUrl>https://myhost/url.png</iconUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>$description$</description>
    <summary>$description$</summary>

[obylium]

@dasMulli Your solution works for me perfectly while using msbuild.

I am attempting to convert projects over to the new format and start using dotnet to build all of them. This one solution is also a nuget package that requires custom versioning, which is passed in through build arguments and then we modify the AssemblyVersion through another task that is currently also not working with dotnet build (another issue). Using dotnet pack, I am getting the following error:

error MSB4062: The "Microsoft.Build.Tasks.GetAssemblyIdentity" task could not be loaded from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

Any ideas?

[dasMulli]

@obylium It should work on 2.1.300+ CLI versions as this task was introduced for newer msbuild versions (https://github.com/Microsoft/msbuild/pull/2933)
You could try the .NET Core 2.1 preview which will install a version of the CLI that should be able to do this.

[dasMulli]

Actually it may already be in 2.1.200+ but I'm not 100% sure.

[obylium]

@dasMulli I just tried 2.1.300 and it worked. Thanks.

[BrightLight]

I'm using Visual Studio 2017 (15.9.5). My .Net Standard 2.0 project is using an AssemblyInfo.cs file. When building the nuget package this information is ignored (as explained here, fine by me). What's confusing is that after the project was compiled, the "Package" tab of the project settings in Visual Studio does show the information from the AssemblyInfo attributes (if necessary, close and reopen the project settings tab).
Because of this, it looks like the package information are correctly set, when in fact they will not be applied because they originate from AssemblyInfo attributes.