This forum has been archived. Please start a new discussion on GitHub.

Icebox dll loading


I am Running into issues loading Dlls in an icebox which are in subfolders in the Distribution Folder. This comes up when loading 32 or 64 Bit Dlls depending on the architecture which are in bin32 and bin64 subfolders. These Dlls Arent Found which i thought would be because the Folders have to be relative to the icebox.exe Folder however this also doesnt work.

How exactly are Dlls loaded internally when an icebox process is initiated ?

Many thanks


  • bernard
    bernard Jupiter, FL
    Hi Daniel,

    Unfortunately your question is not clear.

    Are you using Ice 3.5.1 for C++ on Windows? Note that the folders in the Ice binary distribution are named "bin" and "bin\x64", not bin32 and bin64.

    Did you configure C++ IceBox to load your service using a relative path? Can you show this configuration?

    The Ice Manual describes how IceBox handles different types of path:
    IceBox Properties - Ice 3.5 - ZeroC

    Relative paths are relative to the current working directory of your application, which is typically not the folder where icebox is installed.

    Best regards,
  • Hi Bernard,

    Apologies for the lack of Information - I posted this on my iPad so it was harder to go into Detail :-)

    We are using Ice 3.5.1 for Windows. The application is primarily .NET (F# with a Little C#). The landscape is complicated further in that we reference some native libraries and run highly parallel calculation on the GPU.

    Naturally native library loading has been problematic in General (i.e. not on the ice grid) however our solution appears to work well with the ice grid with no Special tweaks.

    We have done some further Investigation and it is definitely to do with the relative paths.

    The dll in question is available in the Directory referenced by the ice box server, however Debugging has shown that the dl is being searched for in the Ice/bin Directory, i.e. the Location of iceboxnet.exe, which I assume is the Default working Directory.

    I have tried to set the working Directory to the Directory referenced by the ice box Server using the pwd Attribute as per this snippet:

    <icebox id="${application}.PCNServer" activation="always" exe="iceboxnet" application-distrib="false" pwd="C:\IceGrid\Machines\Build-Agent-01\Node\servers\grid.PCNServer.Build-Agent-01.dotnet.0\distrib\PCN\dotnet">

    However this doesn't seem to have any effect :-(

    The Team here has the following possible explanations for why this dll is being treated differently in the ice assembly loading logic:

    1) The dll is strong named and signed
    2) The dll is ILMerged

    Would either of these explain why the dll is not being looked for in the Server Directory ?

    At the Moment I think we are going to deal with this using an assembly resolve Event handler.

    Many thanks for your help,

  • xdm
    xdm La Coruña, Spain
    Hi Daniel,

    If you use a strong name in your entry point, the assembly must be installed in the GAC or in the executable (iceboxnet.exe) directory, so if you entry point is:
    <service entry="helloservice,Version=,Culture=neutral:HelloServiceI" ....

    iceboxnet will try to load the assembly from the directory where iceboxnet.exe resides and from GAC (Global Assembly Cache), If you enable development mode it will also look in the directories specified by DEVPATH.

    If your entry point is a file name it must end with .dll and it is relative to the iceboxnet.exe working directory.
    <service entry="helloservice.dll:HelloServiceI" ....

    If you service DLL depends on other native libraries those must be available in iceboxnet.exe PATH
  • Hi,

    Many thanks for the detailed response, that makes sense now.