Source: own resources, Authors: Agnieszka and Michał Komorowscy
Some time ago I decided to publish my projects on GitHub. This decision had very positive repercussion because it mobilized me to do more refactoring and to clean my solutions. Additionally, I switched totally to management of external references via NuGet. Earlier, I had some binaries in a dedicated directory on my computer. It took me some time but it was worth doing it.
I also had to solve the following problem. I have a solution called
Common. It is a collection of libraries, utilities, algorithms, helpers etc. that are used in my other projects. Before migration to GitHub, after a build, all
Common binaries were copied to the well known location i.e.
N:\bin Thanks to that all other projects could reference them from this location. It works. However, if someone wants to download my projects from GitHub, he or she will need to create a mapped drive
N manually. I din't like it.
The next step was to switch from absolute references to binaries to relative references to projects. For example let's consider a library
MK.Utilities and a project
LanguageTrainer that uses it. Initially
LanguageTrainer was referencing:
N:\bin\MK.Utilities.dll
After migration this reference was changed to:
..\..\Common\MK.Utilities\MK.Utilities.csproj
Much more better, isn't it? Still, it is not perfect. This relative path will work only if the folder with
Common and
LanguageTrainer solutions will be in the same place on the disk. Besides, in order to compile
LanguageTrainer solution
Common solution must be built first. What's more
Common and
LanguageTrainer are two separate repositories which have to be downloaded individually. My goal was to be able to download any repository/solution and then be able to compile it without any further steps.
I started reading about possible solutions and I found information about
git submodules and g
it subtrees. There is so much about them in Internet so I will not repeat others. For example see this
post. At the end I decided to use
subtrees. Simplifying a subtree is a copy of some repository in the another one. Returning to my earlier example, by using subtrees I got a copy of
Common repository/solution in
LanguageTrainer repository/solution. Then I could change the reference to
MK.Utilities as follows:
..\Common\MK.Utilities\MK.Utilities.csproj
Besides, I needed to add
MK.Utilities project to
LanguageTrainer.sln solution so that all projects could be build at the same time. Finally, my
LanguageTrainer repository/solution looks in the following way. On left side you can see GitHub and on the right side Visual Studio:
If needed I can refresh a copy of
Common repository/solution inside
LanguageTrainer at any time. Why I used subtrees? Well, they work for me and are
extreamly easy to create via
Source Tree ;) By the way, I like
git but I hate all this complex commands. Source Tree solves this problem and allows me to use
git via friendly GUI. I strongly recommend it.
At the end I had to solve one more problem with Nuget. Let's return again to my example and let's assume that
LanguageTrainer solution is located here:
C:\LanguageTrainer
In that case, by default, Nuget packages will be located here:
C:\LanguageTrainer\packages
However, we also have a subtree:
C:\LanguageTrainer\Common
And projects from a subtree expects that their packages will be here:
C:\LanguageTrainer\Common\packages
Of course they won't be there so
Common projects will not compile. To overcome this problem I had to manually update
csproj files and replace
..\packages with
$(Solutiondir)packages. For example:
..\packages\structuremap.3.1.6.186\lib\net40\StructureMap.dll
Was changed as follows:
$(SolutionDir)packages\structuremap.3.1.6.186\lib\net40\StructureMap.dll
I hope that this post will help you in your struggles with GitHub, Subtrees and Nuget.