Breaking your solutions up into manageable chunks (libraries) is one of the most important aspects of code maintainability. This article is .NET centric, but the principle applies to any technology and packaging manager such as NPM. Generally speaking, a library (or project/assembly in the .NET world) should only be concerned with one thing and should have as few external dependencies as possible. This leads to a situation where you will have a mesh of dependencies. The simplest way to deal with this is to keep all projects in a single repo under a single solution. However, if you’re doing something right, other people in your organization or the general public will want to use some of your libraries. The question is, should they reference them as NuGet packages? Or, as Git Submodules? This article discusses some pros, cons, and pitfalls of both.

Just a little heads up. This topic will probably end up spanning a few posts because dependency management is very complicated!

Some Scenarios

Let’s take a look at my scenario. I created an app called Hardfolio. It is a cryptocurrency portfolio app that gathers balances for multiple currencies. It is available on the Google Play Store, the Microsoft Store, and talks to two different cryptocurrency hardwarewallets: Trezor, and KeepKey. The app started it’s life in a single repo with a few different projects. As I worked through building the app, I noticed a clear delineation between the layers of the app: USB/Hid, cryptocurrency APIs, and the rest. I hunted around for 3rd party, cross-platform libraries to fill in the abstractions for this, but there were none. A few libraries roughly did the job, but nothing that worked across platforms, so I separated the code into multiple repos in the hope that the community would contribute. This is how the dependency graph looks.

Note: this app is languishing and requires funding, so hit me up if you want to help me relaunch it.

#.net #c# #coding #git #.net #dependency #git #nuget #submodule