Pack metadata doesn't work if project is multi-targeted

[rohit21agrawal]

From @bording on June 28, 2017 0:30

The MSBuild pack targets documentation indicates that <Pack> and <PackagePath> metadata can be added to other build action items, such as Compile. This appears to work fine as long as the project has a single target framework, but it stops working when the project is multi-targeted.

Given the following project file:

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

  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Compile Update="**\*.cs">
      <Pack>true</Pack>
    </Compile>
  </ItemGroup>

</Project>

Here is the generated nuspec after packing:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    <id>PackTest</id>
    <version>1.0.0</version>
    <authors>PackTest</authors>
    <owners>PackTest</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Package Description</description>
    <dependencies>
      <group targetFramework=".NETCoreApp2.0" />
    </dependencies>
    <contentFiles>
      <files include="cs/netcoreapp2.0/Class1.cs" buildAction="Compile" />
    </contentFiles>
  </metadata>
  <files>
    <file src="C:\code\PackTest\PackTest\bin\Debug\netcoreapp2.0\PackTest.dll" target="lib\netcoreapp2.0\PackTest.dll" />
    <file src="C:\code\PackTest\PackTest\Class1.cs" target="content\Class1.cs" />
    <file src="C:\code\PackTest\PackTest\Class1.cs" target="contentFiles\cs\netcoreapp2.0\Class1.cs" />
  </files>
</package>

After adding another target to the project:

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

  <PropertyGroup>
    <TargetFrameworks>net452;netcoreapp2.0</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup>
    <Compile Update="**\*.cs">
      <Pack>true</Pack>
    </Compile>
  </ItemGroup>

</Project>

The nuspec has lost the content files:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    <id>PackTest</id>
    <version>1.0.0</version>
    <authors>PackTest</authors>
    <owners>PackTest</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Package Description</description>
    <dependencies>
      <group targetFramework=".NETFramework4.5.2" />
      <group targetFramework=".NETCoreApp2.0" />
    </dependencies>
  </metadata>
  <files>
    <file src="C:\code\PackTest\PackTest\bin\Debug\net452\PackTest.dll" target="lib\net452\PackTest.dll" />
    <file src="C:\code\PackTest\PackTest\bin\Debug\netcoreapp2.0\PackTest.dll" target="lib\netcoreapp2.0\PackTest.dll" />
  </files>
</package>

I'm using the Visual Studio 15.3.0 Preview 3.0 to test this, but I've also seen it on 15.2, so it's not a problem introduced in the preview release.

This seems to be true regardless of how the package is created, from inside VS, msbuild /t:pack, or dotnet pack.

MSBuild version: 15.3.388.41745
dotnet.exe --version: 2.0.0-preview1-005977

Sample project: PackTest.zip

Copied from original issue: NuGet/Home#5502

[rohit21agrawal]

From @mishra14 on June 29, 2017 1:11

tagging @rohit21agrawal

[rohit21agrawal]

From @bording on June 29, 2017 3:49

Here's an example of how I've been working around this problem for now: https://github.com/Particular/NServiceBus/blob/develop/src/NServiceBus.AcceptanceTests/NServiceBus.AcceptanceTests.csproj#L34

[rohit21agrawal]

@nguerrera @rainersigwald in the outer build , itemgroups like compile and content do not return any elements...is that by design?

I don't want to include these itemgroups in the inner build because everything might get included twice which might not be the intention of the user. For eg:

<ItemGroup>
     <Compile Update="**\*.cs">
       <Pack>true</Pack>
       <PackagePath>myFolder</PackagePath>
     </Compile>
   </ItemGroup>

This will cause all *.cs files to be included twice for projects with two target frameworks, which might not be the intention of the user.

[rohit21agrawal]

From @nguerrera on August 4, 2017 1:33

@rohit21agrawal I believe the issue is that the magic globbing that happens is only done in the inner build. cc @dsplaisted

You should be able to work around it by disabling that and taking over the globbing yourself:

<PropertyGroup>
  <EnableDefaultItems>false</EnableDefaultItems>
</PropertyGroup>

<ItemGroup>
   <Compile Include="**\*.cs">
     <Pack>true</Pack>
     <PackagePath>myFolder</PackagePath>
   </Compile>
</ItemGroup>

[rohit21agrawal]

From @nguerrera on August 4, 2017 1:34

There should be a bug on the SDK for this. I don't know that it was by design.

[rohit21agrawal]

@nguerrera if you or @dsplaisted can find the sdk bug and link it with this one, that would be great for tracking purposes

[rainersigwald]

Note that bringing the globs to the outer build will slow evaluation time while MSBuild grovels the disk. That doesn't necessarily mean it shouldn't be done, but it's unfortunate.

[dasMulli]

To cross-reference, there are already issues when imported build logic via NuGet adds items to inner builds like NuGet/Home#5281

[bording]

I see that this still doesn't have a milestone associated with it. Is there any update on when this might be addressed?