Extra files (i.e. build targets) and ProjectReference

[xen2]

I have a .nupkg that has a build\LibraryA.targets file. This works fine when used as a nuget package.
I did it by adding this to the LibraryA.csproj:

    <None Include="test.targets">
      <PackagePath>build/ClassLibRuntime.targets</PackagePath>
      <Pack>true</Pack>
    </None>

This works fine when used as a NuGet package.
However, I also use this project as a ProjectReference from LibraryB. I assumed the ProjectReference/PackageReference duality would make it work, but it doesn't seem to pick up the target file.

project.assets.json contains only compile/runtime dependency, no build section:

        "compile": {
          "bin/placeholder/LibraryA.dll": {}
        },
        "runtime": {
          "bin/placeholder/LibraryA.dll": {}
        }

What is the recommended way to achieve that?

[nkolev92]

This doesn't look like it's supported.

https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Commands/RestoreCommand/Utility/LockFileUtils.cs#L518-L534

It'd be very hard for restore to know if a build target is going to be part of a potential package.

Don't really have any ideas/pointers here.
//cc
@rohit21agrawal @zhili1208 for ideas.

[xen2]

Even when packing from csproj, those targets are non-indentified and are manually added with something like <None Include="build/**/*.targets" PackagePath="build" Pack="true" />.

Maybe the build targets should have a way to be explicitely defined in .csproj (with either custom ItemGroup or PropertyGroup) or implicitely (i.e. in a specific subfolder with glob pattern).
It then becomes easy to also list them from ProjectReference as well.
The last step would be to adjust BuildAssetUtils.GetMSBuildOutputFiles to support it.

@nkolev92 @rohit21agrawal @zhili1208 If you agree with such a design, I wouldn't mind helping implement it.

[dasMulli]

How well would this work for existing applications packing targets?
At the moment, many targets do things like loading assemblies from known locations of the resulting package, e.g. <UsingTask> directives with $(MSBuildThisFileDirectory)..\tools\netcoreapp2.0\foo.dll (usually based on $(MSBuildRuntimeType)).

When these kind of files are suddenly imported into other projects' generated obj*.nuget.g.targets, it may cause issues.

[xen2]

@dasMulli good point. Maybe one approach would be to choose if you target applies for ProjectReference, PackageReference or both. If you choose both, you would have to write it so that it can support both layouts.

[dasMulli]

A different approach could be to introduce a special type of item that forwards target files over P2P references.

To "send" things to a referencing project, you'd typically extend a project's output groups (built product, documentation, copy local files output group etc.).

For imports, this doesn't work since you can't add imports to MSBuild after static evaluation. Everything related to P2P references happens at run time where you can't add project XML.
This would need to be implemented in NuGet with special items and targets only for the P2P use case.

And even then it could create chicken-or-egg problems - If you need a <UsingTask> in these targets before the ResolveReferences task, the dll files you need may not have even been built (apart from finding the right path to them).

For trivial targets, it seems easier to just modify the projects accordingly rather than finding an abstract solution that may work in some cases and be unusable in others.