This is one of those questions that unfortunately doesn’t have a single answer – it depends.
The easiest solution is always to have a single repository. This avoids many of the problems of managing multiple repositories with different versions. But this only really works if you have a single version of everything; it’s almost impossible to have different release cycles for two products in the same repository. That way lies madness. As repositories grow to any non-significant size it also doesn’t really scale.
As Till points out, one option is Git Submodules. This will allow you to dynamically load the source of one repository in another at a specific commit or branch. Of course this comes with a whole host of problems, some specific so submodules and others are just the nature of linking repositories.*
Some people really like Git Subtree, which is somewhat cheating and lets you repeatedly extract and then import the history of a folder across repositories, and back again.
Finally, you can rely on a dependency management tool, depending on your build environment. I don’t know enough about Visual Studio to comment. At Atlassian we (currently) use Maven to solve this. If you were using JS it might be NPM/Bower, on Ruby it’s Gems. It can be frustrating to have to release a new version of Library X just to make a trivial change for Program Y, but for the most part it works well enough.
This is really an ongoing problem, and something I know vexes me on a daily basis. I feel like there could be an opportunity for a better solution that combines the best of submodules and dependency management, but I haven’t found it yet.
I hope that helps?
* My own biggest gripe with submodules, tooling issues aside, is that it encourages people to check in absolute URLs to other repositories. This works perfectly until you decide to migrate your Git server, or one of the repositories, and now everything is broken. I found out the other day you can use relative paths, which is neat but doesn’t solve the problem.