This may be a pretty stupid question, and if it is please point it out. But I'm just trying to improve my knowledge of the best way to structure a source control repository for multiple people and multiple projects with some shared parts. In short I work with a number of vastly different codebases that have shared libraries for some bits that are common across all implementations our company works with (logging, mail sending etc).
The specific scenario I'm questioning is if I have client A project in one repository & client B's project in a second repository then a set of 'tools' in a third repository what is the best way to share the code and still keep the repositories separate?
In an ideal world we want to be able to open Client A's project and see/edit/check in the code of the 'tools' and the same in Client B's. Currently I'm managing this through just having a second instance of Visual Studio running and manually copying and updating DLLS when changes are made but I feel like there must be a better way.
Thanks in advance!
To answer your question in one word: NuGet.
What you should be doing is turning any shared components into NuGet packages that are published to a NuGet feed, and are referenced by any projects that need them. Modern versions of TFS both VSTS have native Package Management feeds (available as an extension). However, a package management feed can be as simple as a file share somewhere on your network.