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
  • 7

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
  • 199,015
  • 33
  • 367
  • 565
  • You understood correctly. There is no other reason to use a nuget package then? – Giulio Caccin Nov 17 '19 at 17:38
  • 1
    @GiulioCaccin: not as long as it is ok that the current version B always references the newest version of A. And if you come a point where you want this differently, you can always switch to a different reference model afterwards. See also [this older SO question](https://stackoverflow.com/questions/9784186/why-use-nuget-over-installing-libraries-directly-on-my-machine). – Doc Brown Nov 17 '19 at 17:48
  • That is assuming that there won't be a C, D, E, ... which will be developed in the future to rely on this Nuget package. I know it may seem pedantic but it's important to highlight that future expectations can change what is justifiable today. – Flater Nov 18 '19 at 13:39
  • 1
    @Flater: Brevity is often a virtue, that's why I try to avoid putting too many "what ifs" into an answer. But I think there is one "future" scenario here which may be worth an extension of my answer, give me a minute. – Doc Brown Nov 18 '19 at 16:03
  • @Flater I simplified the question, it's different the real scenario. And in fact the problem on maintainability of the application I'm actually handling is that someone created a lot of unnecessary packages for a future that will never be... – Giulio Caccin Nov 22 '19 at 06:54
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
  • 70,664
  • 5
  • 76
  • 161