none
Add dependentAssembly sections dynamically to the CLR from a dll host in a 3rd-party exe (kind of .dll.config) ? RRS feed

  • Question

  • Hi all,

    My question is about .exe.config & .dll.config config files.
    I work with an API which consists in a set of pure assemblies / mixed / C++ native DLLs,  with security parameters (the DLLs are strongly named).

    In the "standard" configuration (i.e. when the API is loaded through our main software or from any toolkited executable), you only have to add lines as below in the runtime section of the .exe.config host executable config file :
          <dependentAssembly>
            <assemblyIdentity name="name" publicKeyToken="1234567891234567" culture="neutral" />
            <codeBase version="1.0.0.0"
                      href="*****.dll"/>
          </dependentAssembly>

    But I'm using a third-party software (a grid-computing engine) to host and load the API upon client service request.
    The host .exe file launches a "bridge" that loads our entrypoint DLL (mixed with native C++ entry-points), and it still does work fine.
    But the underlying API that is launched by the entrypoint DLL crashes when attempting to load the first needed assembly.

    It appeared that it worked fine when adding our <dependentAssembly> sections to the .exe.config third-party executable, but obviously we'd like to have our own ".dll.config"-like config files to keep our clients from modifying a third party config file.

    I can force the load of the first managed code using System::Reflection::Assembly::Load( ... ) giving good credentials and the debugger confirms that the managed part is actually loaded, but the first managed method call still fails :-(

    Also I could read a .dll.config associated with the DLL, but in no way could I add its dependentAssembly sections to the actual CLR configuration.

    So my questions are (but any other solution would be welcome ;-))

     - Is it that the CLR takes into account a .dll.config config file when it loads a DLL from an host .exe file ?

     - Is it possible to change at runtime the CLR's configuration regarding dependent assemblies ?


    Thanking you in advance,

    Regards

    Fabien










    Monday, June 9, 2008 2:35 PM

Answers

  • It is not clear from your description but it sounds as though this is failing because the Windows loader cannot find the unmanaged DLLs.  That's likely, the location of the managed DLL won't have any effect on its probing path.  Things you could try:

    - Store those DLLs in a directory that is listed in the PATH environment variable
    - Add a manifest with mt.exe to your managed DLL that contains <dependentAssembly>.  Murky if that would work.
    - If you can, change Environment.CurrentDirectory to the folder that contains the DLLs just before they would get loaded.
    - If you can, P/Invoke SetDllDirectory() before they would get loaded.
    - Store the DLLs in the same folder as the host .exe



    Hans Passant.
    • Marked as answer by Bruno Yu Thursday, June 12, 2008 6:39 AM
    Monday, June 9, 2008 8:03 PM
    Moderator

All replies

  • It is not clear from your description but it sounds as though this is failing because the Windows loader cannot find the unmanaged DLLs.  That's likely, the location of the managed DLL won't have any effect on its probing path.  Things you could try:

    - Store those DLLs in a directory that is listed in the PATH environment variable
    - Add a manifest with mt.exe to your managed DLL that contains <dependentAssembly>.  Murky if that would work.
    - If you can, change Environment.CurrentDirectory to the folder that contains the DLLs just before they would get loaded.
    - If you can, P/Invoke SetDllDirectory() before they would get loaded.
    - Store the DLLs in the same folder as the host .exe



    Hans Passant.
    • Marked as answer by Bruno Yu Thursday, June 12, 2008 6:39 AM
    Monday, June 9, 2008 8:03 PM
    Moderator
  • Thank you very much for your help.

    My problem was really coming from bad assembly load. Finally I used a hook on the AssemblyResolve event and it did work fine.

    For those who could encounter the same problem, the solution could be something like that :
    http://www.codeplex.com/smartclient/Thread/View.aspx?ThreadId=22785

    F.
    • Proposed as answer by Bruno Yu Thursday, June 12, 2008 6:39 AM
    Wednesday, June 11, 2008 11:39 AM
  • For anyone still looking,

    I've had a similar issue. Trying to load classes from referenced assemblies worked fine from My.exe because My.exe.config has the <codebase> and <bindingRedirect> bits added. But unfortunately my code to access the third party (strongly typed) assemblies had to be in a dll because it got called from MS Access. There doesn't seem to be any support for my.dll.config files to make this work.

    What I didn't realize is that I could create a config file for MSAccess.exe

    Creating the msaccess.exe.config file with the relevant bits in works great. I now loads the assemblies from the path specified and overrides the version number to the one set in the xml.

    A few useful links:

    Config file info on the dependentAssembly section:

    http://msdn.microsoft.com/en-us/library/yx7xezcf(VS.80).aspx
    http://msdn.microsoft.com/en-us/library/4191fzwb(VS.80).aspx
    http://msdn.microsoft.com/en-us/library/7wd6ex19(VS.80).aspx

    The AssemblyResolve event mentioned by Fabien above:

    http://www.codeplex.com/smartclient/Thread/View.aspx?ThreadId=22785
    http://blogs.msdn.com/junfeng/archive/2004/04/25/119589.aspx


    Monday, June 30, 2008 2:00 PM