Assembly names and versions

Question

I am wondering 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 dispite each of the dlls having different assembly version number.

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

Assemblies can coexist in the GAC (Global Assembly Cache) even if they have the same name given that the version is different. This is how .NET Framework shipped assemblies work. A requirement that must be meet in order for an assembly to be able to be GAC registered is to be signed.

Adding version numbers to the name of the Assembly just defeats the whole purpose of the assembly ecosystem and is cumbersome IMHO. To know which version of a given assembly I have just open the Properties window and check the version.

Answer 2

Giving different names to different assembly versions is the easiest way and surely works.

If your assembly (commonutils.dll) is strong-named (i.e. signed), you can think about installing it in the GAC (Global Assembly Cache - you can install different versions of the same assembly side-by-side in the GAC), therefore the calling application automatically gets the proper version from there because .NET Types include assembly version information.

In your VS project you reference the correct version of the library, but you don't deploy it in the application folder; you install it in the GAC instead (during application setup).

Answer 3

Here's what i've been living by --

It depends on what your are planning to use the DLL's for. I categorize them in 2 main groups.

1) dead-end Assemblies. These are EXE's/DLL's 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 spicific 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 -- 2 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 AppDomain. 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 AmiguousMatch 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.

I hope this helps. -Alan.