Home: Allow transitive dependency NuPkgs with .targets to be available in MSBuild

[TheRealPiotrP]

Consider the following dependency graph:

  foo.csproj --> publishtargets.nupkg --> buildtargets.nupkg

PublishTargets.nupkg provides a Publish.targets and BuildTargets.nupkg provides a Build.Targets.

In Publish.targets we have a:

 <Target Name="Publish" DependsOnTargets="Build"...

In Build.targets we have a:

  <Target Name="Build"...

Today, only Publish.targets will be added to foo.csproj. It would be great to enable the top-level dependency on publishtargets.nupkg to transitively bring in buildtargets.nupkg.

[rrelyea]

Please work with Justin to work out plan.
The key change is likely to put the targets in dependency order (C then B then A if A depends on B depends on C).
Please review with msbuild team (rainier&mihai perhaps)

[davkean]

Build targets should also transitively flow across project-to-project graphs, in the same way that packages references do.

This means that:

Project -> Package Reference -> Package Reference (with targets)

Should have the same behavior as:

Project -> Project -> Package Reference (with targets)

For a few reasons:

1. This becomes consistent with references and copy local items from packages, which are also transitive.
2. This enables us to implement the ability to swap package references with project references with zero impact to the build. If targets are not transitive, this could result in different a build result because that package that was converted to a project reference no longer flows its targets that it used to inherit from any package references that it had.
3. From a user perspective, it's also very useful. I can reference a package like the Common Project System from our root core project, and all downstream projects also get the references. However, today I do not inherit build behavior - so as soon as I add a asset (in this case a XamlPropertyRule) that requires an MSBuild target, I must install the package into my downstream projects (which means that now that I need to upgrade them every time I install a new version of CPS).

I believe the push back previously was that some packages come with targets that might only be meant to apply to a single TFM, but if these are inherited might apply unexpectedly to additional TFMs (think UWP -> portable reference, or desktop -> portable reference). Given we're moving to the model of TFM-specific build targets - I believe that we should revisit this.

[davkean]

tag @emgarten as we've discussed this before.

[emgarten]

@davkean would you open a separate issue for this? The work needed for this issue just involves ordering the imports.

[PrashanthKarnam]

Hi

I am using Visual Studio 2017 version and i do not see the transitive dependency for build.targets being resolved.

Can you please tell me if the fix has any particular update to be considered to make it work ?

@jainaashish @emgarten

Repro Steps :

Create a .Net Core Console Application targeting x64 architecture.

Add the nuget package : https://www.nuget.org/packages/IBM.EntityFrameworkCore/

Install-Package IBM.EntityFrameworkCore -Version 1.2.2.100

This package depends on another package called IBM.Data.DB2.Core which has a IBM.Data.DB2.Core.targets file shipped along with the IBM.Data.DB2.Core.1.2.2.100.nupkg

Compile and build the package. It is expected that a folder named "clidriver" must be copied to the application bin folder, but it does not get copied. So transitive package dependency of .targets file is not working.

Where as if you install the IBM.Data.DB2.Core separately and then rebuild, you can see the "clidriver" being copied to the application bin folder.
Install-Package IBM.Data.DB2.Core -Version 1.2.2.100

The fix for this github issue should have resolved the problem, but it isn't.

Can you please help me resolve this issue ?

Thanks,
Prashanth.

[PrashanthKarnam]

@KevinGosse Please refer to this issue https://github.com/NuGet/NuGet.Client/pull/853 . That helped me solve the transitive dependency issue.

[kevingosse]

@kevingosse Please refer to this issue NuGet/NuGet.Client#853 . That helped me solve the transitive dependency issue.

Yup I noticed shortly after, thanks :)

For the others who would find this issue: transitive targets are supported, but you need to opt-in when declaring the PackageReference. This did the trick for me:

<PackageReference Include="MyDependency">
    <IncludeAssets>All</IncludeAssets>
    <PrivateAssets>None</PrivateAssets>
</PackageReference>