Transitively include targets and content files from referenced packages

[MikeRosoft]

Scenario: I have a solution with many projects, which we want to publish as NuGet packages. (In addition, we want to be able to debug them in Visual Studio.) The projects reference each other, and also reference other NuGet packages, e.g. to bring unmanaged libraries to project output.

By default, when I reference a NuGet package, its build targets and content files are brought to the first referencing project, but not to the projects that reference it. The same happens if I reference a package indirectly (project X references package A, package A references package B, package B has build targets and/or content files).

• I am happy about this behavior, because Visual Studio automatically copies the build output of the project to the referencing project. There is no need to execute the targets again in the referencing project; in addition, if they were executed again, this could make the build non-deterministic (if the build target depends on some property, it would need to be set in the referencing project as well).

But this also causes the build target to be excluded by the package generated by dotnet pack / msbuild /t:Pack. The generated package has the following dependency declarations:
<dependency id="PackageName" version="PackageVersion" exclude="Build,Analyzers" />
So the the package built from the project will ignore the build targets of the referenced package - if I reference this package in another project, they won't be executed (the files won't be brought to the project output).

Option 1: Set PrivateAssets. This is a problem, because I have to set this for every package and project reference in the solution, and there can be perhaps a hundred of them. In addition, this changes the behavior during the build, causing them to be executed in every referencing project. (As above, I only want the target to be executed once during build, and also I want it to be executed once if the generated package is referenced by another project.)

Option 2: Use buildTransitive. This requires me to modify every package in question, which may not be under my control. In addition, what will happen if another project references my project? Will this cause the transitive target to be executed again by the referencing project? (Again, this is behavior which I don't want.)

Option 3: Hook to some MsBuild target and modify the generated nuspec file before packing. I didn't succeed with that. If I run msbuild /t:Pack, then if I execute my target before GenerateNuspec, the nuspec file doesn't exist yet; if I run it after GenerateNuspec, it is too late because it has already been packed into the package. (In addition - as far as I know - there is no property containing the location of the nuspec file.) If I run msbuild /t:GenerateNuspec;Pack, it doesn't pack anything.

What other options are there? I want to preserve the default behavior of Visual Studio when building (to not bring the imported targets to referencing projects, and to instead depend on the copying of the output directory), but I also want to preserve the default behavior of NuGet (do not generate the exclude declarations to modify the default behavior; or, alternately, to perform arbitrary modification of the generated nuspec file and remove them before packing).

See related issues: dotnet/sdk#1266 , #3697 , #6388 .

[emamontov]

Same issue here...

We have thousands(!!!) of native/mixed/managed nuget packages that are using only "*.targets" files for reference and content injection, which works same for any project type(csproj,vcxproj...).
There are several reasons why we use custom targets:

1. It supports mix environment, where C#, C++ and C++/CLI reference each other like they are of the same type
2. It supports debug and release versions to put in the same nuget (Yeah! Development environment require debug too!)
3. It created before PackageReference and VS2017 were exists at all.
4. After 5 years, original nuget still does not support the UI: Action changes to updating previous version after installing #1 and UI: Review Changes should use a different order for the display #2

Now, some teams are moving to the new Pack method, and this issue makes it very annoying.
It actually breaks the community's "default expected" behavior, while migrating from VS2015 environment to VS2017+

[Thieum]

Here is a repro project I put together when describing the issue to @terrajobst in https://twitter.com/terrajobst/status/1376570583001931778?s=20 :

https://github.com/Thieum/PackageRefTargetsLost

[MichaelKetting]

I've git this issue, too. An update would be appriciated.

[msedi]

We are having similar issues with many packages and need to add .targets to each packagem but we only want to have the content files in the output executable and not in the built reference assembly output.