5

Scaling down for the sake of the example, my project is structured like this:

  • solution X
    • project A
    • project B

Project A is exposed as nuget packages externally, project B need the functionality provided by project A.
Those projects are there because of proper namespace attribution and logic isolation, not because of usage external to solution X: when project A updates no external solutions needs updates.

Is it OK to reference directly project A from project B without using the nuget package? Am I missing some best practices? Because I see no point on adding complexity on dll release management with nuget to use projects only internally the same solution.

Giulio Caccin
  • 169

2 Answers2

6

If I got this right, as soon as you replace the nuget reference from B to A by a project reference, there is no project left which consumes A as a nuget package, right?

So if there is no consumer any more, it is pretty obvious that the nuget package is superfluous.

Let me scetch one additional scenario here: what if there will be another external project C in the future which wants to consume A by a nuget package - should B then be changed to consume A as a nuget package as well? Or is it ok to let B reference A directly, using a simpler project reference?

To my experience, as long as B wants to consume always the newest version of A, and A & B are part of the same product, the sheer existence of C does not justify a change of the reference mechanism. It can be perfectly sensible to let A expose itself "internally" by one mechanism, and externally by another.

However, if B is mainly a test project, written for making sure the externally exposed project A works as intended, then it is probably a good idea to let B use the exact same reference mechanism as an external consumer C. Tests for components should simulate the aspects of a real consumer as similar as possible.

Moreover, if C also references B, and you are start deploying A, B, and C as one product, it is probably a good idea not to mix the different reference mechanisms. Otherwise you end up with C referencing version 1.0 of A directly, and version 1.1 indirectly through B, which will end up in some kind of DLL hell. For this case, however, one may consider however to have A, B and C part of the same solution and use only project references.

Doc Brown
  • 218,378
1

Generally speaking, if project A is published as a nuget package then consume it as a nuget package.

Now, we all know that if you are editing B and A together, its just easier to do a direct reference. Plus if your build chain builds and versions the solution its tricky to get the nuget reference correct.

But when you come to publish B you will want B to have a nuget dependency on A. Not a direct reference.

So ideally, you develop and publish A and B separately to ensure your tests are reflective of the final product.

I do think its common practice to skip this though and the new .net core build chain likes to make every project a nuget. Which isnt always optimal.

Ewan
  • 83,178