Home: dotnet pack converts ProjectReference to package dependency even when the referenced project has IsPackable=false

[thomaslevesque]

Details about Problem

NuGet product used: dotnet pack

NuGet version: 4.1.0.2450

dotnet.exe --version: 1.1.0

VS version: VS2017 15.3.3

OS version: Windows 10 v1703 (15063.540)

Worked before? I don't think so

Detailed repro steps so we can see the same problem

1. Create two library projects (SDK-style csproj) A and B. A has a ProjectReference to B
2. dotnet pack A => creates a package A with a dependency to package B (which is nice, but I didn't see it documented anywhere)
3. Now suppose that I don't want to publish B as a standalone package; I just want both DLLs in package A. I assumed that setting IsPackable to False would do this, but IsPackable is ignored, so package A ends up with a dependency on a package B that doesn't exist.

Other suggested things

Verbose Logs

dotnet-pack-log.zip

Sample Project

See this repo: https://github.com/thomaslevesque/TestDotnetPackBug

Or the attached project: TestPack.zip

[jainaashish]

If you just want to build A and ignore B from there. Then you can set PrivateAssets to all which will skip generating package B.

<ProjectReference Include="../B/B.csproj"> <PrivateAssets>all</PrivateAssets> </ProjectReference>

[thomaslevesque]

Thanks, but it's not really what I want... Doing that wouldn't include assembly B in package A.

[dasMulli]

@thomaslevesque you may want to use a custom msbuild target to do that as I described in https://github.com/NuGet/Home/issues/3891#issuecomment-330668337

[thomaslevesque]

@dasMulli interesting. I'll consider it, thanks!

But the thing is, I really think the current dotnet pack behavior is a bug. Generating a package reference to a project that can't be packaged is clearly wrong. PrivateAssets="all" doesn't solve the problem, because it implies that it's a development dependency, not needed at runtime, which might not be the case.

IMO, for a project A with a reference to project B, dotnet pack should do the following:

• if B is packable: generate package A with a dependency on package B
• if B is not packable: include the output of project B in the lib folder of package A

[jainaashish]

@dasMulli thanks for referencing this to #3891 Marking this dupe of that.
@thomaslevesque please up-vote on the original issue. It's a P0 for us and we would like to take it as soon as we can for earliest release.

[replaysMike]

Relying on PrivateAssets="all" (while works) is not a great solution here because this prevents you from returning any data types defined in those assemblies. Ideally, we would be able to just suppress the dependency generation in nuget packages on its own without resorting to manually editing it after.