Geek Answers Handbook

Maintaining .NET assembly references common to several projects

My colleagues and I wondered how to do this for quite some time: what is a good / standard way to support .NET assemblies referenced in several projects? I will clarify a little:

Let's say you have projects A, B and C. They can be in the same solution or different solutions, it does not really matter. You also have D and E projects that output DLLs for A / B / C for reference. For good measure, we will throw a third-party assembly F, for which we have only the head of the DLL. Where is a good place to place assemblies from D and E, plus a file from F so that as many of the following events happen as possible:

  • Updates D and / or E do not need to manually update / change in projects A, B or C;
  • Projects A, B, and C can be downloaded to a new computer through source control and compiled with the least amount of problems; and
  • The DLL outputs for D and E, as well as the file for F, are located more or less centrally.

I probably ask too much, but is there any known way to accomplish most / all of this? It pretty perplexed us here.

+7
version-control reference tfs assemblies
source share
2 answers

The following should do the trick I think:

1) Have a release folder in which your third-party DLL will be present.
2) Also add a post build script to copy the D.dll and E.dll assemblies to the release folder when the build is successful.
3) Projects A, B and C will refer to D.dll and E.dll from the release folders.

It also makes no sense to add D.dll and E.dll from the release folder to the original control. The build engine should automatically work with this.

+2
source share

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

See this tutorial: Using Maven to Manage .NET Projects

+1
source share

More articles:


All Articles