Search code examples
c#.netgitvisual-studioprojects-and-solutions

Setting up a Git repository for a .NET solution

I have a solution with 15 C# projects and I'm trying to set up an efficient git repository for them. Should I create a repository on that level or for each project under the solution?

WebServices/
|- WebServices.sln
|- WebService1/
 `- WebService1.csproj
|- WebService2/
 `- WebService2.csproj

The solution has a project reference to ../framework/framework.csproj which is a seperate repository and all the other projects have a reference to. The projects under the solution are not linked in any way, but they all use the framework.

I would like any changes to the framework would be passed to the projects.

Do you have any guide for me how to achieve that in the best possible way?

Solution

  • There is no one answer to how to set up your repository. It depend on your specific needs.

    Some questions you should ask yourself include:

    1. Are all projects going to be released and versioned separately?
    2. Are the projects really independent of each other?
    3. How is your development team structured? Do individual developers stick to a single project?
    4. Is your framework project stable?
    5. Does your build process build each project separately?

    Assuming that the answers to all of the above is "yes", then I would set it up like so:

    • Continue maintaining the framework code in its own repository, and publish it to an internal server using NuGet (as suggested in ssube's comment).
    • Create a separate repository for each project, each with their own solution file.

    If you can say "yes" to all except #5 (and possibly #1), above, then I would add one more repository that consists of submodules of each of the individual projects and a global solution file that your build server can use. If you add a new project, you have to remember to also update this repository!

    If you have to say "no" to #2, then just build a single repository.

    If you have to say "no" to #3, then you'll have to make a judgement call, between separation of the code and developers' need to switch between repos. You could create a separate repository including submodules, but if all your developers wind up using that repo, you are really only introducing new maintenance with little gain.

    If your framework is not stable (#4), then you may want to include that as a submodule in any of these cases. I recommend that once it becomes stable, then you look into removing the submodule and switching to NuGet at that time.