ASP.NET Hosting

Versioning Hell

There have been voices talking about the lack of updates to the .NET Framework and Visual Studio, especially since we learnt that the next versions won't be released before 2005. Microsoft did not release fixes while some well known problems exist. If you don't know the "Help | Check for Updates" command in Visual Studio, it's not worth looking for it, you won't find updates there. All we got was the .NET Framework 1.1 and Visual Studio 7.1.

I may have an idea why there is no lighter and interim updates: maybe it's not easy or even possible to release updates!

How did I come to that conclusion?

Let's take the following situation with one assembly referencing another:


Not trying to compete with Rory here ;-)

If you want to update Ass1, and have Ass2 use that updated assembly, you have to update Ass2. This is because each assembly references the other ones using their name and their version. If you don't update Ass2, it will continue to use Ass1 version 1.0, the version it has been built with.
If you take that to the Framework level, it's all a bowl of spaghetti with dependencies everywhere. Don't forget also that applications, components and Visual Studio are also part of this Italian delicacy and tied to it as well.

Releasing a fix to one assembly requires releasing new versions of all the assemblies referencing it. If you touch a part of the framework, you need to review the whole of it. This is not bad, this is even a good thing in fact. This ensures that the framework is consistent. But it is understandable that Microsoft cannot release multiple version of the framework. We all know how difficult it is to get a new version of the framework (like any other software, especially from some companies) to be validated by administrators. Imagine what a mess it would be if there were versions 1.2 and 1.3 in addition to versions 1.0 and 1.1... You would also have to update your application so they benefit from the new versions.

Do I miss something? What solution do you see to that problem?
Trying to get rid of the DLL Hell, are we locked in an Assembly Versioning Hell?

11 Comments

  • You can solve this by also issuing a policy file :)

  • to solve your problem : when updating Ass 1.0 to 1.1 delete 1.0, Ass2 will use the new version :)

    In fact you change the version number when there are new functionalities or big changes in Ass1. If there are only bug fix or small improvments, just change the build number.

  • I kinda view this as a good thing myself. But if I need an app to use the new dll, you could just change the bindingRedirect stuff in the .config file or put in a policy file to take care of it too.

  • part of this is the whole idea that an app has rules about how it binds to other code....



    part of this is the fundamentals of developing software....



    and it all goe back to what Ms has published about how .net is supposed to work.



    if the app has a local assembly in say it's bin\ folder then fine... thats what it uses.



    if it's looking for a GAC'ed public assembly then it can keep using that version.



    and when you make a new version you should *KEEP THE OLD ONE* not delete it....

    why?

    the old one is say 1.1.0123 and has a tested set of functions etc...

    the new one is say 1.1.8763



    if the assembly is "local" then it's only in the bin\folder of an app that can use it.



    if it's in the GAC then it's clear that this is a new version and you can bind to ither version at runtime.

    the application can select which one to bind with ...



    and using the diagram above I think the real problem is the Vs.NET bindings to the rest of it...

    the other depends have more to do with how you build new versions....



    for example is Microsoft going to break all the public interfaces to SYSTEM.* namespaces?



    I hope not.... I'll even bet they will keep the number of breaking chnages to public interfaces down to less then 20.



    why? how would they ever get anyone to use V2 of dot net???



    so the logic that follows here is that if you don't break the Interfaces then you can have many assemblys that impliment it with different versions.



    does this start to explain why .net should be able to be updated in chunks?

  • TImaniac: "In fact you change the version number when there are new functionalities or big changes in Ass1. If there are only bug fix or small improvments, just change the build number"



    Not sure to understand. When an assembly asks for 1.0.0.1 and all that is available is 1.0.0.2, does this assembly loads version 1.0.0.2?

  • If I recall unless it is a strong named assembly, it will just load up whatever file is there.

  • Wally, in French we say "prêcher le faux pour connaître le vrai". A good way to know the truth ;-)

  • Phil: this is what I discovered. And this participates in making difficult to understand the binding process :-(

  • I don't think its that hard technically to release an update to the framework, though it is impractical. As far as I am concerned, .NET is not meant to be completely backwards compatible, which is why we have side-by-side execution. So releasing an update *shouldn't* break any existing systems.



    The other thing to note is version unification. It's the EXE that selects what version of the framework will be used to run the application, regardless of what version the assemblies it references were built against. As another reader pointed out, you CAN override this with policy settings (or in the application manifest). In fact, you can override most of the versioning settings in .NET if required.



    So I think the reason for the lack of updates is not the technical issues, but probably more political reasons. After the inital naming fiasco with .NET, how good would it have been to have .NET 1.1, 1.2, 1.3, 1.4, etc?

  • Fabrice : You seem to speak french so ;)

    vi vi s'il cherche le 1.0.0.1 et que y'a que le 1.0.0.2 celà n'est pas considérer comme un changement de version. De toute façon si le 1.0.0.1 n'est pas là il cherchera forcement une nouvelle version présente et l'utilisera s'il ne trouve pas de problèmes dans les interfaces des éléments définis dans l'assembly (si par contre une interface à changé, une méthode supprimée par exemple, pif paf il râle)

    C'est pas compliqué : tu veux réparer un bug ? tu remplaces l'assembly par un nouveau (avec un nouveau numéro mineur), si tu veux vraiment tout changer tu change de numéro majeur et tu laisse l'autre version à côté (par prudence).

  • Kalay, you may have to use assembly binding redirection.
    http://msdn.microsoft.com/en-us/library/2fc472t2.aspx

Comments have been disabled for this content.