0

I have two class library projects (single VS solution) and a GUI app (another solution), which uses these libraries. Both solutions are stored in separate git repos. There's no problems when working on a single machine (I just reference dlls once in a GUI project), but in order to work on the other machine I have clone both repos, rebuild the dlls, then modify the references in the project.

Now I'm thinking about creating the "lib" directory in the main app solution, put dlls in there and push it on git repo, but that seems incorrect way of doing things. The easiest way is to put all projects in the same solution, but it is not a good option, since libs will be used in other projects as well and are also constantly updating, so eventually libraries source code may become uncontrolled mess with such approach.

How to store dlls in projects using version control systems correctly?

Ideally, it should be possible to simply clone the project on any machine, open it in VS or VS code and continue working.

Does Deos
  • 31
  • 7
  • 3
    Sounds like you need some kind of package feed, like Nuget. You can find info about creating your own nuget feed here: https://learn.microsoft.com/en-us/nuget/hosting-packages/overview – Natrium Aug 14 '23 at 09:26
  • 1
    Publish your libraries as nuget packages. See https://learn.microsoft.com/en-us/nuget/nuget-org/publish-a-package how to publish to nuget.org. You can also publish to private package repositories (e.g. on GitHub). See https://learn.microsoft.com/en-us/nuget/hosting-packages/overview for more information – Jeanot Zubler Aug 14 '23 at 09:26
  • Thanks, I have created NuGet packages, uploaded on a git package registry and added these packages to the project. – Does Deos Aug 14 '23 at 10:02
  • Additionally you can setup a [github action](https://github.com/MintPlayer/MintPlayer.AspNetCore.SpaServices/blob/master/.github/workflows/publish-release.yml) to automatically build/publish a nuget package. Then you need to [cherry pick feature commits into your release branches](https://stackoverflow.com/a/76889549/8941307) or bump the version in a version commit in order to trigger a release. Some developers trigger a release workflow when a tag is created on a release branch, and pluck the version from there – Pieterjan Aug 14 '23 at 11:05
  • How many projects are you talking about? Maintaining multiple solutions require you to be careful with version management to avoid introducing backwards incompatible changes. The most suitable architecture will likely depend on how many projects you have, and how related they are. – JonasH Aug 14 '23 at 11:18
  • @JonasH, for now there are two class library projects in one solution and one GUI app in another. There possibly will be 2-3 another my solutions. Also, these class library may be used in any project by any developer in our company, so I try to keep the library projects separate and don't use any OS specific features. – Does Deos Aug 14 '23 at 11:24
  • Are the projects likely to be related, or released together? Using a single repo & solution will simplify a lot of things. But with the downside that projects can not be developed and released independently. If you develop a library used by a third party, even within the same company, you need to be really careful to not introduce breaking changes, and that can be surprisingly difficult to do. Main point is to keep things as simple as possible until you are sure you need something more complex. Is is usually easier to increase complexity than the reverse. – JonasH Aug 14 '23 at 11:36
  • Unfortunately, no. My projects are classic desktop apps for Windows+Linux heavily depending on that libs. Also that libs are already used in some web applications by another developer. I'm not sure that having to clone several gui apps alongside with needed libraries in order to use some methods in web app is the right way to go. – Does Deos Aug 14 '23 at 11:46
  • 1
    A risk with a separate library repository is that changing the library becomes more difficult and time consuming the more users there are. So users might put code in the applications that should really be in the library, leading to duplication. Or the reverse, put code in the library that is only used by a single application, and therefore making it more difficult to debug and change for no real benefit. Not saying that a separate library repo is a bad idea, just be aware that there are tradeoffs. – JonasH Aug 14 '23 at 11:47
  • I understand that mantaining the shared library needs extreme attention. Actually the initial task was to create the library, which will be used in a team later. So now I just wanted to know how to better organise my own projects. Thanks for advices. – Does Deos Aug 14 '23 at 12:00

2 Answers2

4

Now I'm thinking about creating the "lib" directory in the main app solution, put dlls in there and push it on git repo, but that seems incorrect way of doing things

You are absolutely right, that is not a way to do things. 3 main alternatives here would be:

  1. Package the libraries and expose them as Nuget via custom feed (the default go to approach in this case)
  2. Use git submodules (also see Git Submodules Vs. NuGet Dependencies)
  3. Migrate to monorepo

Every of the approaches has it's own cons and pros. For example using nuget's can result in some kind of Nuget hell (like dll hell but with nugets) and can increase development time when the dependent libraries a changed often. Second approach can be more cumbersome in terms of set up and management. And mono- vs polyrepos is a whole other holywarish debate.

Guru Stron
  • 102,774
  • 10
  • 95
  • 132
  • Current project is small, so nuget's are easy to setup and use. The only drawback what I've found for now it's that I'll have to store the changelogs for packages somewere, so other developers in our company wouldn't have to guess what I have changed in the new version and whether it will break their projects or not. – Does Deos Aug 14 '23 at 10:45
  • 1
    Submodules solutions also looks worth digging into it. Monorepo most likely will become a hell to maintain. – Does Deos Aug 14 '23 at 10:46
  • @GuruStron: Meh, i answered earlier, you just exploites reputation's impact) – Ryan Aug 14 '23 at 10:50
  • @DoesDeos my personal opinion on mono vs polyrepo debate is that for "small" projects monorepo is better (though it can be a problem to enforce the separation, yes, but that is what code reviews and possibly custom Roslyn analyzers are for), for "medium" ones (especially in popular microservices approach) - polyrepo, for (extra)"large" - again monorepo (for example Microsoft is moving to something called ["Virtual Monolithic Repository"](https://github.com/dotnet/announcements/issues/241)). – Guru Stron Aug 14 '23 at 10:52
1

What are best practices of handling referenced dlls in projects using version control systems?

Well, most .NET developers extremely encourage code reuse in binary format - via nuget packages.
But for those, who wanna be sacred knowledge keepers - git submodules exist.
Git submodule - is a repository inside other repository.
First one can be called dependency.
Your current repository (submodule holder) is termed superproject.
Short reference: (full reference is here)

  1. Create submodule: git submodule add -b <branch> <repoUrl> <localPath>
  2. Init submodule (if repo with submodule cloned incorrectly): git submodule update --init
  3. Clone repo with submodule dependencies: git clone --recurse-submodules <repoUrl> <localPath>
  4. Universal way to update any number of submodules in superproject: git submodule foreach git pull origin <branch>

That's it.

Downside of submodules: the fact you have to learn working with them (can be tedious a bit firstly).
Benefit: NO need in any extra activities for code reuse (building your nuget packages, deploy them, keep up versioning, etc..).
Just use git and get profit.
Cheers!

Ryan
  • 609
  • 6
  • 13
  • It could be the way to go, but a huge drawback is that it confronts the standard way it is done within the .NET ecosystem. Sounds more like reinventing a (much more poor) Nuget. Because of that I actually downvote: this wouldn't generally work well for more or less complex .NET projects over the years. – Zazaeil Aug 14 '23 at 10:28
  • @Zazaeil _"Sounds more like reinventing a (much more poor) Nuget"_ I would argue it does not and in some cases allows to far easier dependency handling then is possible with nugets. – Guru Stron Aug 14 '23 at 10:31
  • @Zazaeil it is code reuse on a level of *repositories*, not in binary format. So, it's not the same, no any *reinventing* here - completely other way to go. – Ryan Aug 14 '23 at 10:34
  • Please read the OP attentively: author explicitly confirms that these libs are to be used in other projects, which immediately involves more problems like version resolution, for example. Even cactus might become a dildo if you try hard enough, however, while doing a .NET project, it is reasonable to stick to a common sense and __the ecosystem__ making sure that lots of tools would just work. With that being said, I agree that for __some special cases__ submodules work better. – Zazaeil Aug 14 '23 at 10:46