How do you share external dependencies between Visual Studio solutions?

Question

I have a Java background so I’m used to having Maven handle all problem around downloading and keeping dependencies up to date. But in the .NET environment I have not yet fo

Answer 1

I usually have a separate folder structure on the source control for extrenal or Internal dependencies, and these filders have the assemblies according to build or version number for example

public\External\libraries\Nunit\2.6\

or

Public\Internal\libraries\Logger\5.4.312\

and inside the solutions all the projects that need to use any of the dependencies just adds a reference to that assemblies in the public internal or extrenal folders.

Answer 2

Adding to what everybody else is saying, it basically comes down to two things:

1. Making sure that all developers have the same versions of external libraries
2. Making sure that all developers have the external libraries located in the same place (at least, relative to the source code)

As Richard Berg points out, you can use ReferencePath and/or AdditionalReferencePath to help solve #2. If you're using msbuild in your build process (in our case, we're using CruiseControl instead of MS Team Build), you can also pass ReferencePath to it on the command line. To solve #1, I've found svn:externals to be useful (if you're using SVN).

My experience with Maven is that it's way overkill for most purposes.

Answer 3

1. Find some place to store the assemblies. For example, I store the .Net core assemblies like so:

   • <branch>\NetFX\2.0527\*
   • <branch>\NetFX\3.0\*
   • <branch>\NetFX\3.5\*
   • <branch>\NetFX\Silverlight 2\*
   • <branch>\NetFX\Silverlight 3\*

2. Use the ReferencePath property in MSBuild (or AdditionalReferencePath in Team Build) to point your projects at the appropriate paths. For simplicity and easy maintenance, I have 1 *.targets file that knows about every such directory; all of my projects Import that file.

3. Make sure your version control strategy (branching, merging, local<->server mappings) keeps the relative paths between your projects & your reference paths constant.

EDIT

In response to the update in the question, let me add one more step:

4) Make sure every assembly reference in every project file uses the full .Net strong name and nothing else.

Bad:

<Reference Include="Microsoft.SqlServer.Smo">
  <SpecificVersion`>False</SpecificVersion>
  <HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\100\Shared\Microsoft.SqlServer.Smo.dll</HintPath>
</Reference>

Good:

<Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" />

Advantages of the latter format:

• Using a HintPath in a collaborative development environment will inevitably lead to situations where "it works for me" but not others. Especially your build server. Omitting it forces you to get your reference paths correct or it won't compile.
• Using a weak name invites the possibility of "DLL hell." Once you use strong names then it's safe to have multiple versions of the same assembly in your reference paths because the linker will only load ones that match every criterion. In addition, if you decide to update some assemblies in place (instead of adding copies), then you'll be notified of any breaking changes at compile time instead of whenever the bugs start coming in.