Where should you store 3rd party assemblies?

Okay, so we have a rather large solution with about 8 different projects inside it. Each of these projects depend on various different 3rd party assemblies. This solution is in the trunk branch of source control. We also have about 5 different branches off of trunk.

What is the best way to manage these 3rd party assemblies? When you add a reference to an assembly and then click it and view the properties window I notice that it has a hard coded path to the assembly.

For example: All our branches are mapped to "C:\Code\". So trunk would be "C:\Code\Trunk" and a branch would be "C:\Code\somebranch".

If I create a folder in "C:\Code\Trunk" called "Assemblies" and then drop all our 3开发者_运维百科rd party assemblies in that folder, and then I add a reference to an assembly in there is that assembly reference relative? If I click the added assembly I see the grayed out path property says "C:\Code\Trunk\Assemblies\someassembly.dll".

What happens if I then branch off of trunk? Would "somebranch" still have a reference to "C:\Code\Trunk\Assemblies\someassembly.dll" or would it then reference "C:\Code\somebranch\Assemblies\someassembly.dll"?

Currently we actually have a branch in source control called "Assemblies" which is mapped, just like any other branch, to "C:\Code\". So all branches with projects referencing assemblies have references to "C:\Code\Assemblies\someassembly.dll" no matter which branch the project is in, the path would be the same.

Unfortunately this means that you have to get the latest version of the branch you are working in AND the assemblies branch in order to get the solution to build successfully.

To sum it all up:

• How do you add a reference that is relative to the solution? (i.e. Add a reference to C:\Code\Trunk\Assemblies\someassembly.dll and have that path be relative to the project that added it, so that when creating a branch it references the branched assemblies folder and not trunk's assemblies folder. Or is this reference already relative?

• What are other recommended strategies for managing 3rd party assemblies?

Now we have nuget you can use it for all supported oss packages and even create your own nuget packages for other 3rd party assemblies. It is worth mentioning openwrap as an alternative to nuget.

nuget stores packages at solution level

so each branch (and trunk) would keep a version of these.

I'd suggest this is preferable behaviour. You would want to keep your assemblies version separate if upgrading a 3rd party for example.

In the past I've used svn's externals command to build the specific version from the internally developed dependencies. There's no reason you couldn't stick those in a repository and use externals (or you scm's equivalent) to get the right version.

I've used build events to get the dlls into the right place too.

Yes use an assemblies folder off of the trunk. I like the name lib better then assemblies.

Yes the path is already relative. When you branch your projects will get the correct assemblies folder.

Depending on how many third party assemblies you are using you make also want to organize your assemblies folder so it is not one big mess of dlls.

We have a SolutionItems folder in our solution for the 3rd party references. Every branch of the solution has it's own copy.

When we add a reference we use the 'Browse' tab in the add reference dialog and select the assembly relative to our current project.

The Project file contains this:

<Reference Include="SomeAssembly, Version=0.1.0.0, Culture=neutral, PublicKeyToken=8xxxxxxxxxxx, processorArchitecture=MSIL">
    <SpecificVersion>False</SpecificVersion>
    <HintPath>..\Solution Items\SomeAssembly.dll</HintPath>
</Reference>

I usually create a common project that all the others reference. Inside that common project, I create a folder called deps (for dependencies). Each of the other projects then references the copy of the DLL in the common project's deps folder.