none
Assembly in GAC RRS feed

  • Question

  • Hi,

    I have an Framework which is a set of libraries(assemblies) installed in GAC.
    And there are a lot of applications using those libraries.
    Now we want to update some libraries, but found out that after that applications are not working with the new versions of libs, so they should be recompiled.
    The issue is that, when the library is not in GAC application will work normally with the new version of library,but when the library is in GAC and after that it is uninstalled and then a new version is installed with the same name and version it is no t working and it needs to be recompiled.
    I am sure there must be a normal solution.

    Please help me on this issue.
    Thank you beforehand.

    With regards,
    Abijah
    Thursday, April 9, 2009 6:16 PM

Answers

  • I just switched off Build and Revision numbers autoincrement and everything start to work normal.
    I have changed
    [assembly: AssemblyVersion("1.0.*")]
    [assembly: AssemblyFileVersion("1.0.*")]
    to

    [assembly: AssemblyVersion("1.0.0.0")]
    [assembly: AssemblyFileVersion("1.0.0.0")]
    Seems the issue comes when the Build and Revision numbers are changed so application can load the new versions of DLL.
    I thought that it is only checking Major and Minor version numbers.
    Friday, April 10, 2009 6:26 AM

All replies

  • If you have a new version of a library which is incompatible with the old version, then it should have different assembly version. 2 assemblies with the same name and public key token, but with different assembly versions (e.g. 1.0.0.0 and 1.0.0.1), are considered different from CLR point of view.
    If you own the framework assemblies, bump up the assembly version when you do incompatible changes. If you don't own the assemblies, ask your vendor/owner to do that for you.

    Another common practice is to bump the assembly version more often (e.g. with each build or daily). If certain version is compatible with the old one, you can use binding redirection.
    You might find useful documentation about assembly versioning and assemblies in general.

    -Karel

    Thursday, April 9, 2009 7:11 PM
    Moderator
  • Thank you for your reply Karel,
    Actually there is no issue of compatibility.
    Lets imagine there is a assemble A which is installed in GAC, and there is an application which keeps a reference to that assembly, than when there is change made in that assembly although interface remains  the same. So we want just to change the existing assembly with the new one without changing the version and of course without recompiling the application which keeps a reference to that assembly.
    So the issue is that when we uninstall the old lib from GAC and then install the new one the application which calls a code from that lib crash.

    BR
    Abijah
    Thursday, April 9, 2009 7:39 PM
  • Sounds to me like you are in fact increasing the version number but are removing the old assembly from the GAC.  Only that could explain that it works fine when the assembly is not in the GAC.  The diagnostic you get for "not working" is key to tell you what is really going on.
    Hans Passant.
    Thursday, April 9, 2009 7:41 PM
    Moderator
  • Major and minor versions remain the same, only build number is increased.
    Thursday, April 9, 2009 7:52 PM
  • Note that incompatibility doesn't necessary mean change of a public interface. If you have an interface which everytime returns 1 and you change the implementation to return 2, then it can cause trouble, therefore it's incompatible.

    Re: Build number is increased ... do you mean File version build number? That should change with every build. If you rebuild, there is a risk that you changed some functionality which will break existing applications.

    As Hans suggested, try to find out why the application with new library in GAC crashes (attaching debugger should help) ... that will be the key. Is it because of changes in the library implementation? Or is it because of something else?
    Thursday, April 9, 2009 8:35 PM
    Moderator
  • I just switched off Build and Revision numbers autoincrement and everything start to work normal.
    I have changed
    [assembly: AssemblyVersion("1.0.*")]
    [assembly: AssemblyFileVersion("1.0.*")]
    to

    [assembly: AssemblyVersion("1.0.0.0")]
    [assembly: AssemblyFileVersion("1.0.0.0")]
    Seems the issue comes when the Build and Revision numbers are changed so application can load the new versions of DLL.
    I thought that it is only checking Major and Minor version numbers.
    Friday, April 10, 2009 6:26 AM
  • Yep, all 4 numbers in assembly version are important. See my answer above:
        2 assemblies with the same name and public key token, but with different assembly versions (e.g. 1.0.0.0 and 1.0.0.1), are considered different from CLR point of view.

    I would recommend to keep the file version attribute with 1.0.* string as CLR doesn't care about file version at all and you will have the information about 'real' version of your DLLs.

    -Karel

    Friday, April 10, 2009 3:33 PM
    Moderator
  • Thank you Karel,
    I will keep it as per your suggestion.
    Friday, April 10, 2009 5:03 PM