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.

Improve this question
0

2 Answers 2

Reset to default
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.

Improve this answer
5
  • You understood correctly. There is no other reason to use a nuget package then?
    – Giulio Caccin
    Nov 17, 2019 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.
    – Doc Brown
    Nov 17, 2019 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, 2019 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, 2019 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, 2019 at 6: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.

Improve this answer
1
  • 1
    Do you think could be less misleading then if project A get removed from the solution?
    – Giulio Caccin
    Nov 17, 2019 at 11:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.