How to manage version control of common DLLs across multiple .NET projects?

Following SO thread开发者_如何学Python shows Managing DLL references in multiple projects across different solutions. Additionally I want to know how to manage the version control for these dependency DLLs ?

Should the DLL (which is published to other external projects) be committed too, every time code change happens ?

Team Development with TFS Guide (Final Release)

This guide has proven to be invaluable to my team. They describe several scenarios and what the pros and cons are of each. For anyone managing a TFS environment this is a must read.

With regards to the DLL's from external projects. We will keep a copy of the source in TFS if we can get access to the source some times, use your best judgement. We keep a copy of the DLL in source control always. The DLL goes into a "SharedBinaries" folder next to source code so that they can be branched together.

It is critical that you be able to branch these DLL's along with source. It is also critical that they be in TFS so that you can do an automated build with little or no build machine configuration. My own personal goal while managing TFS is to be ready for a new developer to join the team and with a single get of source code be able to execute a successful build for local debugging.

EDIT: Different department builds DLL

Like all good IT answers I have to start with "it depends". If the other department is truly segregated from your department and you have little or no knowledge of what they are working or when they will be working on it. If they just occasionally tell you that they have done some things and you should now incorporate the changes then I would lean towards the DLL being committed to the repository every time that the department consuming it wants to change it.

If on the other hand we are really just talking about different teams in the same department where there is lots of cross talk and water cooler communication then I would expect that you could making something else work with just some project references.

It sounds to me like it is the former and not the latter situation that you find yourself in today. I would try to get the department that is creating the shared code to "release" the shared code like Microsoft releases the .NET Framework. Get them to just build the API and give you some DLL's and some documentation. Then the groups that are incorporating those DLL's into there products can check them in separately into a repository of there own control and isolate themselves from code churn while the department working on the these reused DLL's can work on the next version of them.

You should take this all with a grain of salt. This is just one guy rambling on about what might be a good idea. There are many more ways to solve these problems and they are all correct given different circumstances. If you are asking 5 people and you get 5 different responses I wouldn't be surprised.