Version selection in CLR

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

nilesh.shah.uk@gmail.com - 09 Mar 2007 12:29 GMT

I have multiple projects that reference a dll say common.dll. Now I
would like to change common.dll in a backward compatible way and drop
it in to each of the projects so that it is used without any recompile
of the projects. However each change of common is a new version so I
need a way of indicating to the projects to allow a common.dll that is
later than a given version without explicitly giving the particular
version.

For example :

9th March
Project1, Project2 compiled and released with Common.dll v1.1.0

12th March
Common.dll compiled to v1.1.2

14th March
Common.dll compiled to v1.1.3

So would like Project1 and Project2 to be able to use v1.1.2 or v1.1.3
(not at the same time but whenever its available) without changing any
config in them.

Reply to this Message

Patrick Steele - 10 Mar 2007 02:06 GMT

> I have multiple projects that reference a dll say common.dll. Now I
> would like to change common.dll in a backward compatible way and drop
[quoted text clipped - 18 lines]
> (not at the same time but whenever its available) without changing any
> config in them.

You should be able to drop the new DLL in the same directory as Project1
and Project2. If they're not strong-named, I don't think the version
numbers are taken into account during assembly resolving.

Signature

Patrick Steele
http://weblogs.asp.net/psteele

Reply to this Message

David Browne - 11 Mar 2007 16:53 GMT

>I have multiple projects that reference a dll say common.dll. Now I
> would like to change common.dll in a backward compatible way and drop
[quoted text clipped - 14 lines]
> 14th March
> Common.dll compiled to v1.1.3

Incrementing the AssemblyVersion breaks backwards compatibility. That't
what AssemblyVersion is for.

You should not ever allow a .dll to use automatic versioning for the
AssemblyVersion. The fact that Visual Studio does that by default is a bug.

The AssemblyVersion controls assembly loading, and you will break all of the
dependent assemblies every time you build. Instead hard-code
AssemblyVersion and increment it only when you want to break backwards
compatibility. Use AssemblyFileVersion to track version changes.

David

Reply to this Message

Ben Voigt - 12 Mar 2007 15:55 GMT

>>I have multiple projects that reference a dll say common.dll. Now I
>> would like to change common.dll in a backward compatible way and drop
[quoted text clipped - 17 lines]
> Incrementing the AssemblyVersion breaks backwards compatibility. That't
> what AssemblyVersion is for.

I think that a manifest can be embedded into the updated dll, stating that
it is a drop-in replacement for the previous version. But I can't find the
syntax for that right now.

> You should not ever allow a .dll to use automatic versioning for the
> AssemblyVersion. The fact that Visual Studio does that by default is a
> bug.

Hardly. You should never deploy differing binaries with the same version
number.

Reply to this Message

David Browne - 13 Mar 2007 04:55 GMT

>>>I have multiple projects that reference a dll say common.dll. Now I
>>> would like to change common.dll in a backward compatible way and drop
[quoted text clipped - 21 lines]
> it is a drop-in replacement for the previous version. But I can't find
> the syntax for that right now.

Here's the reference:
Redirecting Assembly Versions
http://msdn2.microsoft.com/en-us/library/7wd6ex19.aspx

>> You should not ever allow a .dll to use automatic versioning for the
>> AssemblyVersion. The fact that Visual Studio does that by default is a
>> bug.
>
> Hardly. You should never deploy differing binaries with the same version
> number.

That's your choice, but may often want to deploy an updated library without
recompiling the client programs. Of course the new version should have an
incremented AssemblyFileVersion.

David

Reply to this Message

Rate this thread:

Version selection in CLR

Free Magazines