Let’s say you have two .Net applications: A and B and a shared component C. From a source code versioning point of view you could have:
- RepoFor(A, B, C)
- RepoFor(A, B) and OtherRepoFor(C)
- RepoFor(A, C) and OtherRepoFor(B)
- RepoFor(B, C) and OtherRepoFor(C)
- RepoFor(A) and RepoFor(B) and RepoFor(C)
Except for scenario (1), all the other scenarios would require to clone more than repo, and at the same you could have additional issues when dependencies AC and BC are established at source code level.
The «elegant way» of solving this situations is to establish the dependency at binary level, that is: A and B should depend on C.dll not on C source code. So to do that you need NuGet.
NuGet is a package manager for .Net that will allow to publish packages containing .dlls (and some other stuff too).
The following diagram illustrates the suggested solution:
Here are 2 short videos I recorded to show how to create and publish NuGet packages.
Blog de NicoPaez 
Imagine the «A» app depends on version 1.0 of «C» and the «C»-Team releases a new version of «C» let’s say 2.0. If you are a new «A» developer and want to download the repository, when you try to get the C Package from NuGet you will get the last version i.e. 2.0. But version «C 2.0» brakes «A» because it was designed to be used with «C 1.0″… and you don’t need the new features at all. In fact, updating «A» to make it «C 2.0» compatible costs a lot. How would you manage that case? Is still NuGet good this reason?
The key point here is that NuGet stores all versions of your components, so when you get a package C from NuGet, you will have to specify which version you want (by default you will get the latest but you could specify a previous one).
This this way, you could have at the same time:
A depending on Cv1 and
B depending on Cv2