Maintaining .NET assembly references common to multiple projects

My colleagues and I have been wondering the best way to do this for quite some time: what's a good/standard way to maintain .NET assemblies that are referenced in multiple projects? I'll elaborate a little bit:

Say you have projects A, B, and C. They could be in the same solution or different solutions, doesn't really matter. You also have projects D and E that output DLLs for A/B/C to reference. For good measure we'll toss in a third-party assembly F, for which we only have the bare DLL. Where开发者_如何学编程 is a good place to put the assemblies from D and E, plus the file from F, so that as many as possible of the following things occur:

• Updates to D and/or E don't have to be manually refreshed/changed in projects A, B, or C;
• The projects A, B, and C can be downloaded to a new machine via source control and compile with the least amount of hassle; and
• The DLL outputs for D and E as well as the file for F are more or less centrally located.

I'm probably asking too much, but is there any known way to accomplish most/all of this? It's been puzzling us for quite some time over here.

The following should do the trick I think:

1) Have a release folder where your third party dll would be present.
2) Also add a post build script to copy assemblies D.dll and E.dll into the release folder on successful build.
3) The projects A, B, and C would reference D.dll and E.dll from the release folders.

Also it would not make sense to add D.dll and E.dll from the release folder into source control. Build mechanism should be automatically capable of handling this.

One (probably not optimal) solution is to use Maven for your dependency management.

See this tutorial: Using Maven to manage .NET projects