0

I'm developing a plugin to a application. My plugin uses WPF Toolkit 1.6.0.0. The WPF Toolkit assembly is strongly named and I have ensured that I all references to the assembly is Specific version is true.

The host application uses a previous version of WPF Toolkit (1.5.0.0). When my plugin attempts to load WPFToolkit, it loads the version from the host application, even though the correct assembly is located in the same folder as my plugin assembly (I load other dependencies from this folder without problems).

How can I ensure that the correct version of the library is loaded?

Below follows the assembly binder log.

*** Assembly Binder Log Entry  (29.11.2012 @ 09:35:17) ***

The operation failed.
Bind result: hr = 0x80131040. No description available.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable  C:\Path\To\Host\Application\Application.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = XXXXXXXXXXXXX
LOG: DisplayName = WPFToolkit.Extended, Version=1.6.0.0, Culture=neutral, PublicKeyToken=3e4669d2f30244f4
 (Fully-specified)
LOG: Appbase = file:///C:/Path/To/Host/Application/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = application.exe
Calling assembly : PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Path\To\Host\Application\petrel.exe.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: WPFToolkit.Extended, Version=1.6.0.0, Culture=neutral, PublicKeyToken=3e4669d2f30244f4
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Path/To/Host/Application/WPFToolkit.Extended.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\Path\To\Host\Application\WPFToolkit.Extended.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: WPFToolkit.Extended, Version=1.5.0.0, Culture=neutral, PublicKeyToken=3e4669d2f30244f4
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: The assembly reference did not match the assembly definition found.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
larsmoa
  • 12,604
  • 8
  • 62
  • 85

1 Answers1

0

I still do not know why I encountered this issue, but I found a workaround. By hooking up to AppDomain.CurrentDomain.AssemblyResolve and manually loading the assembly I was able to load the assembly correctly.

Here's the code for the resolver:

private static Assembly HandleAssemblyResolve(object sender, ResolveEventArgs args)
{
    Assembly requestingAssembly = (args.RequestingAssembly ?? Assembly.GetExecutingAssembly());
    AssemblyName assemblyName = new AssemblyName(args.Name);

    string currentLocation = requestingAssembly.Location;
    string baseDirectory = Path.GetDirectoryName(currentLocation);
    string assemblyLocation = Path.Combine(baseDirectory, assemblyName.Name + ".dll");

    if (File.Exists(assemblyLocation))
    {
        return Assembly.LoadFile(assemblyLocation);
    }

    return null;
}
larsmoa
  • 12,604
  • 8
  • 62
  • 85
  • 1
    You are well on your way to create your own version of DLL Hell. Especially LoadFile() is super dangerous. Also the probable reason you got this problem in the first place, sounds like you are using it to load the plugin as well. Always use LoadFrom, *never* LoadFile. This is otherwise why the GAC exists. – Hans Passant Nov 29 '12 at 12:15