dotnet pack behaves differently depending on TargetFramework vs TargetFrameworks

[nguerrera]

From @jskeet on May 24, 2017 7:41

Steps to reproduce

Create a csproj file in an empty directory:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net45</TargetFrameworks>
    <Version>1.0.0</Version>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Grpc.Core" Version="1.3.0" />
  </ItemGroup>
</Project>

Run dotnet restore then dotnet pack. No problems, and a 3K nupkg.

Edit the project file to use <TargetFramework> singular, and repeat... warnings and a 19MB nupkg.

Expected behavior

The same behavior both times.

Actual behavior

Massive difference, basically baking a lot of Grpc.Core's contents into the nupkg when the singular XML tag is used.

The warnings are of the form:

warning : Description: The assembly 'content\grpc_csharp_ext.x86.dll' is not inside the 'lib' folder and hence it won't be added as reference when the package is installed into a project.

I don't want them in my package... I'm just trying to add a dependency within a library project. (If I were trying to create a standalone executable package or similar, I could understand it.)

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.4)

Product Information:
 Version:            1.0.4
 Commit SHA-1 hash:  af1e6684fd

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\1.0.4

Copied from original issue: dotnet/cli#6679

[nguerrera]

From @dasMulli on May 24, 2017 10:8

Quick analysis:

The reason seems to be that the Grpc.Core nuget package brings along a build/net45/Grpc.Core.targets file that emits Content items into the referencing project with CopyToOutputDirectory="PreserveNewest" metadata.
Since there are no targets in a buildCrossTargeting/ folder, this doesn't happen for multi targeting projects (plural TargetFrameworks).

A way to not consume this logic and force it onto referencing projects could be to use

<PackageReference Include="Grpc.Core" Version="1.3.0" ExcludeAssets="Build" PrivateAssets="Analyzers" />

[nguerrera]

From @jskeet on May 24, 2017 10:13

@dasMulli: Hmm. That sounds entirely plausible as the reasoning, but I don't think users should be exposed to that level of detail, necessarily - doesn't it make sense that a multi-targeting project with only a single target should behave the same way as a single-target project? This is one example of how they differ at the moment, but I can easily imagine there being more - it seems unnecessarily confusing.

[nguerrera]

From @dasMulli on May 24, 2017 10:30

The crazy part is that NuGet does create the restore targets correctly. The build logic of the imported package does run for inner builds of cross-targeting builds, but is not considered for the inner builds that the Pack target triggers.
Grpc.Core's target isn't even "fancy" - just contains a static <ItemGroup> that every target will see.

So even though the obj/tmp.csproj.nuget.g.targets contains:

<ImportGroup Condition=" '$(TargetFramework)' == 'net45' AND '$(ExcludeRestorePackageImports)' != 'true' ">
  <Import Project="$(NuGetPackageRoot)grpc.core/1.3.0/build/net45/Grpc.Core.targets" Condition="Exists('$(NuGetPackageRoot)grpc.core/1.3.0/build/net45/Grpc.Core.targets')" />
</ImportGroup>

It looks like this target is omitted for multi-targeting packs.

[rohit21agrawal]

duplicate of : #3927