Feature : Allow project reference DLLs to be added to the parent nupkg for pack target like IncludeReferencedProjects in nuget.exe

[joelverhagen]

Steps

1. dotnet new --type lib two .csproj class libraries: projectA and projectB.
2. Change <TargetFramework> to <TargetFrameworks> if you don't have #3865.
3. Make projectA have a ProjectReference to projectB.
4. Add <Type>project</Type> to the <ProjectReference>.
5. dotnet pack projectA
6. Open the resulting .nupkg's lib folder

Expected

projectB.dll should be in the .nupkg along with projectA.dll

Actual

projectB is still a package reference, not a DLL included in the package.

Environment

Tried latest dev's pack target.

dotnet --info

.NET Command Line Tools (1.0.0-preview3-004056)

Product Information:
 Version:            1.0.0-preview3-004056
 Commit SHA-1 hash:  ccc4968bc3

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64

UPDATE: Please see workaround posted as comment to see how to add ProjectReferences as DLLs in the package dynamically.

[rrelyea]

Please check spec on wiki for planned behavior

[joelverhagen]

Spec: https://github.com/NuGet/Home/wiki/Adding-nuget-pack-as-a-msbuild-target

This doesn't work:

<TreatAsPackageReference>false</TreatAsPackageReference>

The output .nuspec still has projectB as a package reference and only one file: projectA.dll under lib.

[emgarten]

This is a non-trivial feature that hasn't been implemented for RC yet.

Supporting this will require potentially walking the entire project closure to determine all projects that need to be merged into the package, or reading the assets file and matching the project closure with both the project reference flags and the pack flags found in the project (since it can be set either way).

This is also impacted by build outputs not flowing transitively to parent projects yet.

[joelverhagen]

Plan of action:

1. Build out some automated tests for pack task to cover basic scenarios and detect regression.
2. Add the original PackageSpec to the lock/assets file.
3. Add any missing properties to the assets file pack needs (e.g. path to child project output assemblies).
4. Update restore (no, not pack) to collapse project references when <TreatAsPackageReference> is true.
5. Move the PackTask away from looking at child projects. Look at restore's assets file instead.

This has repercussions on:

• Restore: basically all of the data pack needs should be collected by restore an put in the assets file. Restore should be the only guy doing a walk.
• Project/Package duality: what if a child project .csproj has a <Reference>. How is this collapsed?
• What collapsing occurs? Certainly build artifacts and <PackageReference>... what about <Reference>?

[joelverhagen]

@rohit21agrawal, I partially got through consuming the assets file from in the pack task:
https://github.com/joelverhagen/NuGet.Client/tree/jver/3891

This also has some progress on getting the output DLLs of child projects (using @(ReferenceCopyLocalPaths) MSBuild items).

This branch is pretty rough so let me know if I can clarify.

[rohit21agrawal]

As per @rrelyea : #3893 (comment)

"We don't plan to enable this in dotnet pack / msbuild /t:pack in 4.0 timeframe.
We'll listen to customer feedback and consider in the future."

[rohit21agrawal]

moving to future as this is post-rtm work.

[gulbanana]

building a nupkg from multiple projects seems like a major feature to be missing :/

[rohit21agrawal]

@gulbanana thanks for the feedback. this is something that is not planned for the 4.0 RTM release, but this is something we will definitely address in a future release.

[bbowman]

@kzu 's nugetizer 3000 does this?

[Cloudmersive]

When is this going to get fixed?? This is such a mess

[houseofcat]

I would love to have been in the room where they decided to make this a much more streamlined process. It is so much easier than old Framework package maintenance.... but then right at the end, the design topic of including other project references into dotnet pack comes up... and it looks like they figuratively drove the whole god damn bus off a cliff.

[josh-endries]

Two years, multiple issues, over a hundred comments, still not prioritized. Wow guys. Impressive.

This also doesn't work with dotnet build and <GeneratePackageOnBuild>true</GeneratePackageOnBuild>, by the way.

[ChristianSauer]

Honestly, we are considering ditchting .Net Core and nuget over this.
We are building microservices which share some commen infrastructure and deploying them using nuget is difficult due to this issue.
Even python packages work better than this.
Hell, I would be satisfied if I could write this by hand, but the whole mess (including sourcelink now) is so complicated that the amount of time needed is prohibitive.

[HristoHentov]

Just spent half a day thinking I was doing something wrong with my project setup, only to find out this behavior is by design. Really disappointed

[ruimsft]

We still didn't make this happen? It's not a good practise to make each dll as a package - we definitely need to hide some internal projects.

[chrfin]

We where facing the same problem here and so I put together a build-script which a lot of stuff I collected from all of the workarounds for this or related problems. Combined with some of our own juice I created a package which if included creates packages similar to the "old -IncludeReferencedProjects" flag of NuGet.exe. It works fine in our internal project-/build-environment and I would like to share it, as it maybe is useful to other too: https://www.nuget.org/packages/OmicronLab.Tools.NugetTargets
I'm sure it does not work in all cases, especially as our build-system has some strange configurations, but I guess it should work in most default cases.
Feel free to extract the targets-file from the package and send me feedback/improvements. If there is enough interest I can also move it from our internal source-control to a public repository, but I hope this script is only needed for a short amount of time until there is an "official way"...

[amang2205]

I'm highly disappointed that this is by design.

[ericdunn]

It's "by design", it's just a bad design :P

[SidShetye]

Who is the product owner for NuGet at Microsoft? Seems we’re all just customers complaining about a bad design but this needs review from the PM/owner

[mdschweda]

Wait... this is intentional? 😂

[dasMulli]

Btw i've put together a sample recently with the latest "workaround" at https://github.com/dasMulli/AdvancedMSBuildDemos/tree/master/IncludeP2P (esp. PublicLib.csproj).

Interestingly, I've looked at the code of some folks who needed to use that and found that in many cases, the design is questionable at best.
Needing to add other projects into the package was either required because of unnecessary splitting of assemblies ("shared" code that no one else used or no layering that required it) or because some wanted to share a subset of their projects, but didn't want to manage many packages. Last one nearly resulted in problems where two packages had the same dll files packaged into them which would lead to problematic behaviour if both packages were added to a consuming project (esp. if in different versions).
I really only have seen a handful of legit use cases, but I don't claim to have seen enough to make an informed judgement. I just think that the option of being there led to a lot of "well let's add this switch and we'll be fine" without weighing in or knowing about potential drawbacks.

[ericrini]

The design decision to drop support for using NuGet packages to encapsulate multiple assemblies is dissapointing.

[armitagemderivitec]

This really is disappointing

[voroninp]

@houseofcat You just don't understand the point. It's the way of coping with dll-hell: they just decided not to include dll's at all. =)

I had a faint hope .NET will be really cross platform without becoming a JVM. Alas.