Project reference VS NuGet - visual-studio

Question

How should I reference to another project A from project B in the same solution?
What do I gain and what do I lose if I:
Add the reference to project A as a project reference.
Install the NuGet package of project A in project B.
Things that would bother me are build dependencies, versioning..?
Or does this totally destroy the purpose of a solution?

Answer 1

Project reference VS NuGet
Project reference or NuGet is a very common problem in our development process, we need to choose which one to use based on our actual situation.
For example, if the referenced project A is modified frequently during the development process, we recommend to use Project reference. Because if you use nuget, you have to rebuild the referenced project, recreate the nuget package, reinstall that nuget package to the project B, even you have to publish it to the server. This will bring a lot of unnecessary work and we often forget to update our nuget package after we modify the referenced project A. If you use the project reference, you will not have these problems. The modified referenced project A will be update automatically before we build the project B.
On the other hand, when we share our referenced project A out of solution, or share that project to others, nuget will be a better choice. It has more portability.
So the project reference will be recommended when you reference to another project A from project B in the same solution, the nuget is more appropriate when share the reference project out of solution or share project to others.
Besides, there is a Visual Studio extension NuGet Reference Switcher, which which automatically switches NuGet assembly references to project references and vice-versa.
Hope this helps.

Answer 2

With the first approach, you gain in simplicity, since you don't need to generate a new version of the ProjectA nuget package, every change you make in it (i.e. ProjectA.nupkg).
However, with the second approach, you gain in portability, since you can easily share the same nuget package with other projects / solutions.
Personally, I create nuget packages only for projects whose goal is to share with other solutions. (E.g. libs and frameworks).
Hope this helps you decide!

Answer 3

Nowadays with the new csproj format the you can use both at the same time (if you have both projects in the same solution).
In your example, you could reference project A from project B as a project reference. Then, if you want to release project A as a NuGet package you just need to add the following tag to it's csproj inside a PropertyGroup:
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
The plot twist: If you want to release project B as a NuGet Package too just add the GeneratePackageOnBuild target - MSBuild will set projectA.nupkg as a dependency in projectB.nupkg.
This way you can work internally with your projects while at the same time release them as packages to third parties or other teams.

Answer 4

You could use both: project references during development (faster), and package references during production.
In your .csproj project file:
<ItemGroup Condition="'$(Configuration)'=='Debug'">
<ProjectReference Include="../../../Library1/Library1.csproj" />
<ProjectReference Include="../../../Library2/Library2.csproj" />
</ItemGroup>
<ItemGroup Condition="'$(Configuration)'!='Debug'">
<PackageReference Include="Library1" Version="1.0.0" />
<PackageReference Include="Library2" Version="1.0.0" />
</ItemGroup>
In development: project compiled in debug mode, so the project reference will be used.
In production (CI server, docker container): project compiled in release mode, so the package reference will be used.