CODEWITHSUNDEEP
visual-studiodependenciesgit-submodules
RadioMan85
RadioMan85

Reputation: 349

Git-Submodule dependencies vs. Visual Studio dependencies

I do have the following respsitory dependencies:

enter image description here

Using submodules clonging Repo 1 recursivly (git clone --recurse-submodules -j8 {repo-path}) would add the following folder structure to my drive:

enter image description here

Of course I have a clone of the Repo 2 somewhere else, where I use to develope the project inside Repo 2. So, open the project inside Repo 2 in visual studios there I would have a solution containing both projects of Repo 2 and Repo 4, whereas Repo 2 will get a dependency assigned to the project from Repo 4.

The same for the solution when developing on the project in Repo 3 that depends on the project in Repo 4 as well.

When I set up the visual studio solution for the "Application" project (i.e. Repo 4) I would have to add all projects from each repositorie once (only once as the IDE obviously doesn't take the same projects twice, so far so clear). This means that only 1 of 3 possible Repo 4 projects will be added (so lets choose that one that came with Repo 1).

Now the problem occurs, where I have to reassign the dependency path of Repo 2 and Repo 3 to that other Repo 4 that came with Repo 1. This consequently will affect the project file of these repositories which leads to the request to commit that new path which I don't want of course!

So how do you handle this issue as I guess that this isn't a rare problem (correct me if I am wrong).

And as every time: If you dislike it feel free to -1 it, but leave a comment below why. Else its simply discouraging.

Upvotes: 1

Views: 434

Answers (1)

VonC
VonC

Reputation: 1323953

So how do you handle this issue as I guess that this isn't a rare problem

It is a problem that is generally actively avoided.

"git submodule" suggests source dependencies, as opposed to binary dependencies

The workarounds are:

  • depend on binary only, meaning you depend on Repo4 built artifact (like a dll or library), not on Repo4 source (which would involve cloning)
  • monorepository approach, where all projects are in the same repository, with symlinks in order Repo2 or Repo3 to point to the same Repo4.

Upvotes: 1

Related Questions