locked
RegAsm /codebase loads assemblies with LoadFrom() RRS feed

  • Question

  • Hi,

    I encounter a problem with a .NET dll made ComVisible, i cannot add this dll to GAC because it references .NET dlls which are not in GAC. So i have to register it with RegAsm /codebase. When i debug the Com activation of this dll, i see that the dll is loaded in LoadFrom context. And it's no good, because the LoadFrom context creates problems when loading .NET references, references to unmanaged dlls, and XML serliazation. Therefore my assembly loading fails with unresolved references.

    We have tried to add dlls probing in App.config but it's really complicated to maintain it, as we have to specify the assemblies version which can change after an update.

    Do you know how to force a clean load of references with RegAsm /codebase? I would like the COM dll to be loaded with Load() and not LoadFrom(). 

    Generally my question is: Is there a way to load a .NET dll in a folder different than the executable folder? It seems that it's impossible, except with GAC. LoadFrom doesn't work properly.

    Thanks.

    Olivier

    Tuesday, September 13, 2011 9:43 AM

Answers

  • I get the impression that a lot of the problem is due to versions changing a lot after updates. Are you really changing the interfaces that much? Generally people change AssemblyVersion only when the COM interfaces change, and tracking of code changes can be done using assemblyfileversion, incremented separately (and the file version increment means that higher versions replace lower during a conventional install). 

    I've also seen app.config files generated/updated automatically after builds to make maintenance less cumbersome. That shouldn't be too complicated as a post-build step.

     


    Phil Wilson
    • Proposed as answer by Paul Zhou Monday, September 26, 2011 8:11 AM
    • Marked as answer by Paul Zhou Wednesday, September 28, 2011 5:29 AM
    Wednesday, September 21, 2011 7:53 PM

All replies

  •  

    Hi,

     

    Why don't you install both this dll and the referenced .NET dll to GAC? So the problem could be resolved simply.

     

    Otherwise, we can use codebase element to specify where CLR can find an assembly. The version and folder of the assembly are necessary to specify the assembly. Then you can use Load() method to load the specified assembly in the application.

     

    I hope this can help you.


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Proposed as answer by Paul Zhou Wednesday, September 21, 2011 5:17 AM
    Thursday, September 15, 2011 2:58 AM
  • Hi,

    I can't install DLLs in GAC for several reasons: we have referenced assemblies which are unsigned, so our assemblies cannot be added to GAC. Moreover our assemblies reference some unmanaged C++ DLLs, how can we load them easily when we are in GAC? Put them in WINDIR, hugly... or specify a PATH, specifying a PATH for unmanaged C++ DLLs in a .NET DLL doesn't work. Load C++ DLLs manually with LoadLibrary, ok, but we will have to change all our DLLImport[] signatures and replace them by a late binding.

    I cannot use Load() since loading is not performed by myself, RegAsm technology is responsible for assembly loading. Debugging loading in Visual shows that once registered with RegAsm /codebase an assembly is loaded at the specified location with LoadFrom(). To my knowledge /codebase doesn't give any chance to specify the assembly version, if so, perhaps we can hope that a Load() will be used instead of LoadFrom(), but /codebase only specifies a location path.

    Olivier

    Wednesday, September 21, 2011 7:04 AM
  • I get the impression that a lot of the problem is due to versions changing a lot after updates. Are you really changing the interfaces that much? Generally people change AssemblyVersion only when the COM interfaces change, and tracking of code changes can be done using assemblyfileversion, incremented separately (and the file version increment means that higher versions replace lower during a conventional install). 

    I've also seen app.config files generated/updated automatically after builds to make maintenance less cumbersome. That shouldn't be too complicated as a post-build step.

     


    Phil Wilson
    • Proposed as answer by Paul Zhou Monday, September 26, 2011 8:11 AM
    • Marked as answer by Paul Zhou Wednesday, September 28, 2011 5:29 AM
    Wednesday, September 21, 2011 7:53 PM