How to manage different releases of supporting DLLs in Visual Studio 2010?

Question

I have a VB.NET/C# Visual Studio 2010 Solution with a bunch of projects that depend on about 30 third-party DLLs all from 1 vendor. This third-party vendor recently released a new version of their software so I would like to parallel test their new software and my enhancements until I am comfortable to switch over. What is the best way to setup a solution in Visual Studio 2010 so that I can use the code I have developed on top of these third-party DLLs and have the opportunity to easily switch between:

(1) the new version of the third-party DLLs [for my testing] and
(2) the old version of the third-party DLLs in case I need to debug some problem a user is having

Third party assemblies ARE NOT in GAC (they're currently in a folder on a network drive). They are NOT strongly signed (ran sn -vf ). They are changing from version 5.4.618.0 to 5.4.619.60.

You could probably switch just by using a different binding policy in the config file(s). — H H, Nov 18 '11 at 17:42
@Henk, I don't know what that means, maybe you can show me an example... — Denis, Nov 18 '11 at 17:43
Start by providing more info. are they in the GAC, are they signed, major/minor version upgrade? — H H, Nov 18 '11 at 17:46
Just make a copy of your solution folder and its subdirectories. — Hans Passant, Nov 18 '11 at 18:28

score 1 · Answer 1 · answered Nov 18 '11 at 17:50

The way we handle this is to create an Assemblies folder associated with the project/solution at the file system level.

Whenever we have third-party DLLs that we need to use, they go into this folder and the reference in the projects are made to the files in the folder, not to the versions in GAC.

This allows us to update dev machines with new releases and test them. Since all of our code, including the assemblies, are stored in subversion, if we need to test a version that the customer is having problems with, we check that release out of subversion into a different directory and we have an exact replica of what the customer is using.

We've been doing this for about 8 years on some very large projects and it has worked very, very well for us.

Adam Tuliper · Answer 2 · 2011-11-18T17:51:03.470

0

If there is simply a minor version change and these haven't been signed, then you can just swap out the libraries. Otherwise you will need to add bindings redirectsin your app.config to point a prior reference to the new version or just create a second project file with the updated references in it for your second folder.

edited Nov 18 '11 at 17:51

answered Nov 18 '11 at 17:44

Adam Tuliper

29,982
4
53
71

but how can I setup the solution to quickly do this? I don't want to copy this manually all the time - I might forget to do it. – Denis Nov 18 '11 at 17:59

score 0 · Answer 3 · answered Nov 18 '11 at 17:50

You can use binding redirect and codebase combination to logically group the assemblies. It also helps in the case where you need to support multiple versions of same assembly. If the assembly is not strongly named or is not found in the GAC, the runtime looks for applicable codeBase elements in your machine and application configuration files. The codeBase element maps an assembly name to a file or a uniform resource locator (URL). If the assembly is strongly named, codeBase can refer to any location, including Internet-based URLs; otherwise, codeBase must refer to a directory relative to the application directory.

In case of Windows Workflow it is very common to have multiple versions of workflow, executing side by side. In that case the assemblies are strongly named and then appropriate entries are added in codebase section of web.config file. You can check out any standard documentation on WF and see as how it is implemented.

How to manage different releases of supporting DLLs in Visual Studio 2010?

3 Answers3