CODEWITHSUNDEEP
c#visual-studiogitproject-managementprojects-and-solutions
siride
siride

Reputation: 209445

Splitting up a .NET solution/Git repo for multiple apps

I currently have a single solution that contains both the one application developed so far and projects for all of the homegrown libraries. This entire solution is also kept in a single Git repo. I am now going to be developing a second application that will make use of those same libraries. That application will have different release cycles than the first and different versions. The question (or questions) I have is how to split up the code, both in terms of the solution set up and in terms of Git.

A few other useful details before talking about answers:

  1. The applications are deployed to a shared network drive, not to individual computers, so I have complete control over when they are deployed and what gets deployed with them
  2. The library DLLs are not shared by the applications once built. Each application has in its folder a full copy of all the DLLs, PDBs and config files.
  3. Currently, I'm the only one doing releases, but another one or two may end up doing releases, so I'd like to keep that in mind.

I've been rolling around a couple of ideas in my head, but none of them seem satisfactory. I've considered just keeping everything in one solution/one Git repo. I've also thought about splitting up the solution across several Git repos using submodules, but submodules are cumbersome. I've also thought about making each application its own solution and all of the libraries in yet another. The question then is whether I can have multiple solutions open in visual studio. The libraries frequently need to change with the applications, so separating them too much in separate solutions or Git repos is going to make it hard to keep the libraries and apps in sync. Another concern I have is branching. If I split the solution into several Git repos, I can have branches for each application, but if I keep one Git repo, I can only have one set of branches for everything.

I may not even be asking the right questions to myself, and it's also possible that I just have a mental block keeping me from solving a simple solution. Either way, I defer to the SO community to give me some ideas. I hope everything is clear, but if not, I'll be glad to clarify.

Upvotes: 8

Views: 3112

Answers (2)

brycemcd
brycemcd

Reputation: 4513

While they might be cumbersome, I think submodules are the way to go on this one. I'm just going to guess your directory structure is something like:

mainapp
 \mainappdir
   \somefiles
    ...
|
|
 \library1
|
 \library2

In that case you'd want library1 and library2 to be submodules (that's probably obvious). They're really not that bad, just something to get used to in Git IMHO.

Another route to consider would be to symbolically link library1 and library2 on your filesystem for both apps to use. In that case, each library could be it's own repo but not managed with submodules (I think you'd have to add them to your .gitignore file though). By using symbolic links in each application, repo/source management would just be on the two library directories. Pulling/branching in one place would have affects on both apps on not require admin'ing the library files of each app.

Upvotes: 4

Bernard
Bernard

Reputation: 7961

I would split everything up into separate solutions, especially the libraries that will be used in multiple applications. As you mentioned, different applications and libraries have different release cycles and might end up being developed separately. It's up to you to split them up into logic units and ensure that the libraries are independent of the applications they will be used in.

As for what to do in Git, it would make sense to have separate repositories for each logical unit of work (application or library), or at the very least, separate branches within the same repository.

Good luck and don't be discouraged. This will be beneficial to you in the long run.

Upvotes: 0

Related Questions