How can I use GitLab with multiple project folders inside a solution?

Question

I am new to versioning, and have implemented a GitLab group and a project within it on gitlab.com.

I have several apps developed in Visual Studio - the solutions use projects that reside in separate folders on my computer.

For instance:

• DLLs A and B are in different folders of my work area, and application X might use A, while application Y might use A and B.
• DLLs X and Y are in their own folders.

I implemented version control for one of the DLLs, but when I try to do the same e.g. for application X from inside MSVS I get an error message because the different projects that make up the solution (in this case A and X) are in different folders.

Is this a limitation, or is there a way to have two repos for a solution, one of which dealing with the versioning of DLL A, and one with the remainder of the executable code for X.

When I open the X solution, I see all the A versioning in the team window, but have not tried to add a git repository for the code that builds the app, i.e. X in the description above.

Answer 1

The Visual Studio Git or “Team” functionality only handles a single repository.

There is a feature request in state “On Roadmap” for this feature, so they plan to implement it.

You can still use Visual Studio to switch between individual repositories and handle them then, or you can use a third party tool to handle Git versioning. For example TortoiseGit, which you can use in Windows Explorer from the right click context menu.

Disregarding Visual Studios limitation you have quite a few options how you want to handle dependencies and their versioning.

If they are distinct components you could make them produce NuGet packages, and add those as dependencies.

If you want to edit them in one workspace and repository checkout at once (without the indirection of a separate VS instance and having to build the NuGet package separately), then you will probably want to use git submodules - to make one reference and check out another in a subfolder.

Submodules make it a little bit harder and less simple to manage code, because you will have a repository in a repository. And having some technical knowledge about them certainly helps when working with them.