The MSBuild "pack" target is missing a property for explicit assembly references

[MaxG117]

I can't figure out how the NuSpec <references> element maps to a csproj or MSBuild property. I believe it is because this mapping was omitted. The following articles:
https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#pack-target
https://docs.microsoft.com/en-us/dotnet/core/tools/csproj#nuget-metadata-properties
fail to mention this.

Please let me know how to specify an explicit assembly reference for the pack target in a csproj file, explain why this capability does not exist, or use this issue to implement the mapping. Thank you.

[jainaashish]

@rohit21agrawal can you quick peek into this and respond accordingly?

[rohit21agrawal]

currently this capability does not exist. We will add this to our feature backlog. Thanks for reporting!

[MaxG117]

I have an additional question/request.

My nuget package consists of two assemblies: A.DLL and B.DLL, The consumer of my package (a.k.a. the target project) only needs to reference A.DLL, but A.DLL requires B.DLL at runtime. This is why I added an explicit assembly reference to A.DLL using the <references> NuSpec element. This worked as expected when targeting .NET Framework -- building the target project placed both A.DLL and B.DLL into the build output directory and the target project executes successfully.

However, I'm now targeting .NET Standard and I found out that dotnet publish does not copy B.DLL into the publish directory. The only way to get B.DLL into the publish directory was to remove the explicit assembly reference to A.DLL from the NuSpec file. I believe this is a dotnet publish bug, If B.DLL is copied to the build output directory, it should also be copied to the publish directory. Please let me know if I should open a separate issue.

[rohit21agrawal]

@MaxG117 can you show us the nuspec you use to build your package, and the nuspec that's present inside the generated package, along with the contents of the obj folder (*.g.props, *.g.targets, project.assets.json) , after you run a restore?

[TechnikEmpire]

I've seen this as well. Microsoft.Data.Sqlite suffers from the same/similar problem if I'm understanding the notes here. If I reference that package in a .NET Standard library, then have a consumer reference my package (which references Microsoft.Data.Sqlite), the targets that unpack the Sqlite native assemblies into the bin folder on build will not get executed. I have to explicitly reference Microsoft.Data.Sqlite to get the package to work properly in this use cause (which I was argue is not only normal, but fundamental) and it's extremely annoying to pass this on to consumers. You're basically forced to hand out broken packages.

[MaxG117]

@rohit21agrawal I finally had some time to look into this again, sorry for the delay.

In my previous comment I said that B.DLL was copied to the build output directory, but dotnet publish did not copy it to the publish directory. Either I was wrong or something changed since then, as B.DLL is not copied to the build output directory either. So at least there's consistency.

Here's the summary of my problem with creating a nuget package. I hope someone can guide me to a solution (I renamed A and B to make it easier):

1. My project produces two class libraries: PublicLib.DLL, containing public API for my customers, and PrivateLib.DLL, containing code that is only used by PublicLib.DLL.
2. PrivateLib.DLL is an internal implementation detail and may change at any time. I don't want my customers using it, because future changes will break their applications.
3. My nuget package must contain both libraries, because PublicLib.DLL requires PrivateLib.DLL at runtime.
4. If I place both DLLs into the lib\{tfm} directory, the customer's application automatically gets assembly references to both DLLs, permitting violations of # 2 above.

This problem is somewhat similar to #6614 -- my customer could start using the functionality in PrivateLib.DLL, but I cannot solve it the same way as #6614, because my PrivateLib.DLL is not and cannot be in a public nuget package.

I tried creating an explicit assembly reference to PublicLib.DLL in my .nuspec file. Unfortunately, this doesn't just prevent an automatic assembly reference to PrivateLib.DLL, it also completely ignores PrivateLib.DLL -- even if I get this DLL into the nuget lib\{tfm} directory, the customer's application doesn't copy it to either build output or publish directory. I need to be able to specify that PrivateLib.DLL is required by PublicLib.DLL at runtime only, so it appears in the "runtime" section of the customer application's .deps.json file and gets copied to the publish directory when the customer publishes.

Is this possible? Perhaps if not with nuget/nuspec/csproj settings, are there any other ways to accomplish this?