Question

What is considered as best practice when it comes to assemblies and releases?

I would like to be able to reference multiple versions of the same library – solution contains multiple projects that depend on different versions of a commonutils.dll library we build ourselves.

As all dependencies are copied to the bin/debug or bin/release, only a single copy of commonutils.dll can exist there despite each of the DLL files having different assembly version numbers.

Should I include version numbers in the assembly name to be able to reference multiple versions of a library or is there another way?

Answer 1

Here’s what I’ve been living by —

It depends on what you are planning to use the DLL files for. I categorize them in two main groups:

1. Dead-end Assemblies. These are EXE files and DLL files you really aren’t planning on referencing from anywhere. Just weakly name these and make sure you have the version numbers you release tagged in source-control, so you can rollback whenever.

2. Referenced Assemblies. Strong name these so you can have multiple versions of it being referenced by other assemblies. Use the full name to reference them (Assembly.Load). Keep a copy of the latest-and-greatest version of it in a place where other code can reference it.

Next, you have a choice of whether to copy local or not your references. Basically, the tradeoff boils down to — do you want to take in patches/upgrades from your references? There can be positive value in that from getting new functionality, but on the other hand, there could be breaking changes. The decision here, I believe, should be made on a case-by-case basis.

While developing in Visual Studio, by default you will take the latest version to compile with, but once compiled the referencing assembly will require the specific version it was compiled with.

Your last decision is to Copy Local or not. Basically, if you already have a mechanism in place to deploy the referenced assembly, set this to false.

If you are planning a big release management system, you’ll probably have to put a lot more thought and care into this. For me (small shop — two people), this works fine. We know what’s going on, and don’t feel restrained from having to do things in a way that doesn’t make sense.

Once you reach runtime, you Assembly.Load whatever you want into the application domain. Then, you can use Assembly.GetType to reach the type you want. If you have a type that is present in multiple loaded assemblies (such as in multiple versions of the same project), you may get an AmbiguousMatchException exception. In order to resolve that, you will need to get the type out of an instance of an assembly variable, not the static Assembly.GetType method.