Workflow for using git submodules in Visual Studio

Question

I have some shared code I want to share among a number of solutions. Most examples use the command line, but I want to do it using Visual Studio 2013 (and/or TortoiseGit)?

- SolutionShared
  - .git
  - Project1Shared
  - Project2Shared
- Solution1
  - .git
  - ProjectFoo
  - ProjectBar
  - [SolutionShared]
    - [Project1Shared]
    - [Project2Shared]
- Solution2
  - .git
  - ProjectBaz
  - ProjectQux
  - [SolutionShared]
    - [Project1Shared]
    - [Project2Shared]

What I did was to create a new solution SolutionShared, add all my shared code there, and add it to its own git repo. I then used TortoiseGit (as I couldn't figure out how to do it Visual Studio) to add that shared repo as a git submodule to Solution1 and Solution2.

1. What do I do in Visual Studio?
My two solutions now have a SolutionShared directory. Do I simply add its two child projects (Project1Shared and Project2Shared) in Visual Studio?

2. How do I make changes to the shared code from within the non-shared projects
If I'm in one of the non-shared solutions and make a change to something in the submodule, how do I commit and push it back to the shared solution's repo (SolutionShared) so that it's available to all solutions that reference it?

Solution 1

After much experimenting...

In VS, add the shared projects from the submodule to the solution. They seem to live "outside" the parent solution as far as versioning.

If you make an edit to the submodule's projects, they are local. They need to be committed and pushed to the source repo, and then you need to merge them there. If you make changes at the source, you need to pull them manually into your solution's git submodule.

Problem is VS doesn't do any of this for you, so you need to use something like TortoiseGit or the command line.

Solution 2

We have found that the easiest way for us to do this is to move each of our shared units of code into their own Visual Studio Project and put each shared Visual Studio project in its own repo.

We then add each one of those projects as a submodule to any Solution that needs them. This is helpful since many of our projects can be very large in size and share many of the same chunks of code. We have made extensive use of nuget packages for this purpose, as well, but have generally had better success and a much better design/debug experience with submodules.

Much has changed at Microsoft in relation to Git in the last few years. Visual Studio Team Services (TFS Online) and On Prem-TFS (since TFS2015) both now have a good understanding of how submodules work and can now do CI Builds that incorporate submodules right out of the box.

Support in on-prem TFS 2015 can be a bit buggy, however. TFS Build's references to the submodules have a habit of becoming corrupted resulting in builds that stop working without warning until whichever submodule is at fault is completely removed and re-added - not a fun process. For this reason (among a few others), we are now using VSTS (TFS Online) for everything and have had none of those same types of problems. I would assume that this is fixed in on-prem TFS 2017, as well.

As was mentioned, Visual Studio itself (the IDE) does still have a hard time understanding submodule relationships. It really just can't handle them. I have tried a number of standalone Git Tools to find the easiest way to manage an environment like this. Tortoise seems to provide the easiest and most performant experience when pushing, pulling, and checking in to repos containing submodules. I usually use commands to add the submodules, but I suspect Tortoise's add submodule functionality works just fine, too.

When you commit code to a repo using Tortoise, it notices when a submodule is dirty and will prompt you to check-in the submodule before checking in the parent repo. That's really nice. Pulling or Fetching the parent repo can be a little confusing, though. It doesn't actually refresh the submodule from it's remote branch, it only refreshes it to whatever level is currently checked into the main repo remote which is not always the latest. In reality, this is the desired behavior, it's just not immediately intuitive if you're not expecting it.

Comments

[mbx]

sounds like we cannot yet use them in CI builds without pain

[Steve Drake]

@mbx you can get tfs online to PULL submodules its under advanced settings, its a pitty that VS client does not do this.

[mbx]

@SteveDrake yep, we removed our workaround (a few lines in powershell) once submodule support shipped with tfs

[Steve Drake]

@mbx have you managed to get VS to just work with submodules? eg another dev opens the project and it pulls the sub modules I have asked it here at stackoverflow.com/questions/44498755/…

[mbx]

@SteveDrake haven't tried as we only have 1 project with submodules and I added the submodule update to the build script.

[RHarris]

Has any of this (particularly in reference to VS IDE support) changed in 2019?