Using package management (on Windows: NuGet) is certainly a solid approach. You get dependency resolution "for free" and you can use semantic version control to transfer meaningful information for packaging consumers only through the package version number.
However, NuGet is actually a concrete implementation of some of the more fundamental patterns:
- Change code that has changed
- Divide systems into small, manageable units.
- Do not create frames
From your question, it looks like you are creating more code than necessary, and that your code is less modular than it could be. Using NuGet for modular code will help to implement these three patterns (of course, 1 and 2 - you will need to take additional steps for 3).
Using these templates will help @Fede too (for anyone - with C and C ++ code - NuGet is not applicable). As a rule, making your software more modular (but avoiding the trap of building a monolithic, all-knowing "framework", usually called * .Library.dll or * .Common.dll, etc.), you will achieve a better architecture .
Ultimately, each "piece" of code (Project or Solution in terms of Visual Studio) should be understandable to one developer; if it is too bulky or complicated, separate it. Projects, Solutions, .cs files, etc. - these are all abstractions for people , not for machines, so the size and relationship between them should reflect our human abilities and the need for understanding. Taking this parameter too far will lead to the need to change several packages to complete one function: in this case, the separation by definition will be grainy, and you will need to group the code together again.
(Disclosure: I am a co-author of Windows package management - PackageManagementBook.com )
source share