none
XCopy and assembly resolving issues.... RRS feed

  • Question

  • Hi,

    I have an application which is deployed using an XCopy approach (its a daily build).I see a strange behaviour when I try to replace some of the existing DLLs with my local (development) copy and try to run the application....

    The DLLs I replace are also dependent...Let's say A.dll and B.dll,where A is dependent on B.   Also A.dll executes the code in B.dll via some method...

    When I did a code change(changed a constant string) in B.dll and replaced only this in the daily build application folder, it somehow is still considering the code with the content of the "old" B.dll.    But then when I built the app again locally and replaced both A.dll and B.dll in the daily build folder then the right behavior is achieved(changed code is considered).

    The only difference I saw using ILDisassembler.exe is that previously A.dll in the daily build folder pointed to a certian version of B.dll.So when I replaced only the A.dll(local) obviously into the daily build folder it would point to a version of B.dll (local).

    In such a case I expected that if there was any issue in the versioning of the DLL in the case where I replaced only A.dll
    1)Why did it not throw an exception based on version mis-match?
    2)Howcome the previous code of old B.dll still executed when I replaced it completely...with the new one?

    Note: I've used no special probing algorithm used for Assembly resoving nor does any part of the daily build folder have a back-up copy of the DLL nor is it there in the GAC...

    Is there a possibility that the above behaviour can occur?

    Thanks and Regards,
    CRP










    Thursday, October 8, 2009 10:32 AM

Answers

  • Beware of the difference between const and readonly.  A const declaration should *never* be public.  The compiler implements it by substituting the identifier for the literal at compile time, it does not appear in the assembly's metadata.  Which means that when you recompile one assembly, the other will still use the old definition of the const.  Use a static readonly instead.

    Version numbers are only checked for non-local assemblies, they need to be in the GAC.  Assemblies found on the probing path of the program are only checked for their name.

    Hans Passant.
    • Marked as answer by crp2k Friday, October 9, 2009 8:31 AM
    Thursday, October 8, 2009 11:32 AM
    Moderator

All replies

  • Beware of the difference between const and readonly.  A const declaration should *never* be public.  The compiler implements it by substituting the identifier for the literal at compile time, it does not appear in the assembly's metadata.  Which means that when you recompile one assembly, the other will still use the old definition of the const.  Use a static readonly instead.

    Version numbers are only checked for non-local assemblies, they need to be in the GAC.  Assemblies found on the probing path of the program are only checked for their name.

    Hans Passant.
    • Marked as answer by crp2k Friday, October 9, 2009 8:31 AM
    Thursday, October 8, 2009 11:32 AM
    Moderator
  • Hi Hans,

    Thanks for the info on const v/s int.this was the problem.

    Regards,
    CRP
    Friday, October 9, 2009 8:33 AM