NuGet and Git Submodules

Question

I've already extensively searched for a solution, tried different approaches but none worked, thus I'm asking here.

My current need is to have separate Git repositories each containing a .Net solution file with related projects. One or more of those repositories will contain only class libraries and I need to use those libraries inside other repositories solutions.

My first though was to use Git Submodules to avoid ugly copy-paste and still have the source code of the class libraries available when developing the applications.

So my attempt was to include the submodule, then in my current Solution do "add existing project" and load the desired class library(ies).

The huge problem I've been unable to overcome is Nuget package restore. The imported projects reference libraries in "..\Packages*" but when imported as submodule they are located in an additional subfolder so they can't find the required dependencies:

- MySolution.sln
- Packages folder
- MyAppProject folder
- Submodule folder
-- EXPECTED packages folder for MyLibraryProject that I cannot generate
-- MyLibraryProject folder

One solution I found and tried was this but it has two major problems:

• It's supposed to work using MsBuild package restore and I absolutely don't want to use it
• Even trying to use MsBuild package restore it didn't work at all, I still have a single Packages folder in my current solution folder. Maybe I did something wrong but again, I don't want to use MsBuild approach.

Now I'd really like to know if there's a clean way to solve this problem, or if the only thing I can do is to give up having libraries source code available in my application solutions and publish my libraries on a private NuGet feed and reference them from there.

Thanks.

Isocrates

Have you considered using NuGet for MyLibraryProject instead of git submodules? Run a local NuGet server, generate a NuGet package for the library, and add a reference to that in your app. Just an option... – Burck

Thank you for your suggestion. I have indeed considered this option, but we are thinking of using an online CI service like AppHarbor and that would force us to use a public (paid) nuget service as well, like MyGet, in order to be able to restore the packages from the CI server, and we'd like to avoid that. – Isocrates

Okay. And you have to have the two directory levels for the library project? (Could the submodule directory just be the library project directory itself?) – Burck

I'm not sure I understood correctly what you meant. Git forces at least 1 subdirectory level for submodules, so you can't just put your submodule in your current repository root. This is enough to throw off the packages position for the submodule. – Isocrates

Perhaps have a look at fsprojects.github.io/Paket/github-dependencies.html ? – Haunt

Answer 1

It sounds like your issue is that the projects from the submodule are in a different directory level than their repo's solution. This is a common Nuget issue because it restores at the solution level. You can use the fix hint path script here to replace your references with $(SolutionDir) and likely solve the issue. https://github.com/owen2/AutomaticPackageRestoreMigrationScript/blob/master/README.md#fixhintpathsps1

Overstudy

I see there's a clean powershell script that fixes the hintpaths so I could script that. I will evaluate this possible solution, thank you. – Isocrates

While this is indeed viable, we are still in the decision making process, although it looks like we'll be using Nuget for internal dependencies instead of git submodules, as @jon-skeet suggested. – Isocrates

Unfortunately NuGet overwrites the HintPath when you update a package, so you have to run the script again. Maybe a git pre commit hook would be convenient here. – Arbitress

Answer 2

You can resolve this issue by changing ..\packages everywhere in all *.csproj files to $(SolutionDir)\packages. Works pretty well. This script covers it:

find -name "*.csproj" | xargs sed -i 's/\.\.\\packages/$(SolutionDir)\\packages/g'

Hightest