PackageReference or ProjectReference to a component inside the same solution?

Question

Let's consider the scenario in which we have two .NET Standard projects that we want to expose and create NuGet packages for:

LibrarySolution

ClassLibrary1 (CL1)

∟ ClassLibrary2 (CL2)

It is important to mention that CL1 has a ProjectReference to CL2.

NuGet's documentation states that ideally we should generate one package with one single assembly, so we create a NuGet package for each of them.

The problem arises when we need to determine, in the scope of LibrarySolution, which version of CL2 is required in CL1, since we have direct project reference.

Two following approaches come to my mind:

1. Maintaining project references in the solution, meaning that we would need to store the package version in the csproj file, committing version bumps and so on, so that the version constraints and dependency requirements are correct (we currently handle versioning in the CI pipeline and current version is stored there and not in code).

2. Convert the dependency on CL2 into a PackageReference. This way, CL1 will always have a dependency on a version of CL2 that has already been published. However, doing so would imply going through all the dancing around publishing and updating NuGet packages (approving PRs, merging, CI, etc) which could be very time consuming.

I think that option 1 is better, but it still feels a bit manual. Is there an optimal way to solve this? I would prefer not to use a package to reference a project that is inside the same solution as it feels an unnecessary indirection.

Answer 1

In my experience, the cleanest, fewest-headaches approach is #2 using PackageReference. Yes, there's more overhead but it makes everything explicit and this is the officially-supported solution.

(If you're hesitant to this route because you need to update CL1 every time you change CL2, perhaps you need to consider whether your componentization makes sense. Ideally CL2 should define relatively stable interfaces and can be changed independently of CL1.)

Otherwise, there are 2 approaches you haven't mentioned:

3. Including both dlls in a single NuGet package. While this isn't officially supported with the existing tooling, several workarounds are described here: https://github.com/NuGet/Home/issues/3891

4. Merging both projects into a single library, since they seem to be tightly coupled anyway like I mentioned above.

Answer 2

First of all, you are doing things correctly with ProjectReference . There is no reason for two projects in the same solution to even be aware of the existence of a package of the other. Now since you have CL1 and CL2 in the same solution, I guess CL1 needs an up-to-date version of CL2.

With the previous into account, you can just generate your packages of build by adding the <GeneratePackageOnBuild>true</GeneratePackageOnBuild> tag, and MSBuild will change it to a NuGet dependency to the latest version in the package.