Home/ Questions/Q 6079097
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T10:54:29+00:00

We’re building a PIP-installer for our plugin. The plugin consists of one module in

  • 0

We’re building a PIP-installer for our plugin. The plugin consists of one module in one DLL, lets call it MyCoolPlugin.dll (actually, this DLL consists of several merged DLLs). In addition the plugin has a few dependencies to third party DLLs (e.g. Infragistics2.Win.UltraWinChart.v10.3.dll).

The plugin installs fine, but the process embedded in the plugin has an UI depending on UltraWinChart. When creating the GUI for this process the plugin throws an exception about not being able to load Infragistics2.Win.UltraWinChart.v10.3.dll even though this file resides in the same directory as MyCoolPlugin.dll. The “This process does not have a defined description or user interface”-dialog then appears.

If we copy Infragistics2.Win.UltraWinChart.v10.3.dll to a directory listed in the probingPath defined in petrel.exe.config the plugin works fine. The plugin.xml looks correct, but has no references to the dependencies. The manifest contains one <File> entry for each file in the plugin directory, including Infragistics2.Win.UltraWinChart.v10.3.dll.

Why isn’t the dependencies loaded correctly?

EDIT:

I’ve come up with a workaround for the problems we’re seeing. By manually preloading dependencies (by filenames) on plugin initialization (the Initialize() function) I’m able to ensure that all dependencies are pre-loaded. However, I’m not sure if this solution is stable (I get occasional crashes on startup). The code I’m using is:

Assembly me = Assembly.GetExecutingAssembly();
FileInfo file = new FileInfo(me.Location);
foreach (FileInfo assembly in file.Directory.GetFiles("*.dll"))
{
    try
    {
        Assembly.LoadFile(assembly.FullName);
    }
    catch (Exception e)
    {
        CoreLogger.Error(string.Format("Failed to load assembly {0}.", assembly.FullName), e);
    }
}

Do you have any details on how you ensure plugin .NET assembly dependencies are loaded (external dependencies, not module dependencies)? Are you using the AppDomain.CurrentDomain.AssemblyResolve-event to intercept load failures? This answer shows how to use this event to load assemblies from the same folder as the executing assembly when all else fails. I think that the correct approach would be to use the calling assembly instead (as the executing assembly probably will be the assembly in which the event handler is defined). I haven’t successfully tested this workaround yet.

Note that I’ve tested with other assemblies to ensure that this isn’t an Infragistics-issue.

Edit 2:
As stated in the earlier, the plugin DLL is a merged DLL consisting of several assemblies. I’ve used this approach to determine the direct dependencies, and it seems Infragistics isn’t one of them. Could this be of relevance?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think the issue is related to obfuscation of our assembly. If we do not obfuscate the assembly (and hence merge all assemblies into one big assembly) everything works fine. I’m guessing that this is because Petrel is loading plugin assemblies, checking the reference assemblies and loading dependencies recursively. This won’t work in this case as not all assemblies are listed as reference assemblies.

    A workaround for this is to include the reference assemblies (Infragistics) in the merged assembly. This seems to work fine. However, I guess this isn’t always acceptable (e.g. for LGPL licensed libraries).

    Another, maybe better, apporach would be to listen to the AppDomain.CurrentDomain.AssemblyResolve-event to intercept assembly loading errors.

    • 0