views:

421

answers:

1

Does anyone have any idea what would cause the Fusion loader to simply skip over a DLL with no warning or acknowledgement?

I'm seeing this problem when attempting to do (in C#)

Assembly.LoadFrom("c:\Deploy\bin\WebServices.dll")

from a command-line application.

That DLL has a dependency on Platform.DLL, but the loading of that dependency fails so this line of code throws an exception. When I check the Fusion assembly loading message, this is what I see:

=== Pre-bind state information ===
LOG: DisplayName = Platform, Version=9.0.0.0, Culture=neutral, PublicKeyToken=null (Fully-specified)

...

LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\\Windows\\Microsoft.NET\\Framework64\\v2.0.50727\\config\\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Project/bin/Debug/Platform.DLL.
LOG: Attempting download of new URL file:///C:/Project/bin/Debug/Platform/Platform.DLL.
LOG: Attempting download of new URL file:///C:/Project/bin/Debug/Platform.EXE.
LOG: Attempting download of new URL file:///C:/Project/bin/Debug/Platform/Platform.EXE.
LOG: Attempting download of new URL file:///c:/Deploy/bin/Platform.DLL.
LOG: Attempting download of new URL file:///c:/Deploy/bin/Platform/Platform.DLL.
LOG: Attempting download of new URL file:///c:/Deploy/bin/Platform.EXE.
LOG: Attempting download of new URL file:///c:/Deploy/bin/Platform/Platform.EXE.

The thing is, the DLL -is- present at c:\Deploy\bin\Platform.DLL, with proper version and no signed public key.

Things I've thought of:
1. maybe it's really a dependency of Platform.DLL that's broken, causing this behavior? (I chased the dependency tree in Reflector but found no missing DLLs)
2. maybe there's a release/debug mismatch, or a 64-bit vs 32-bit? but everything was built on the same machine
3. maybe I'm misreading the logs -- but shouldn't it stop when it hits a DLL that it finds? I don't see either the "successful" OR the "unsuccessful" message in this log. I just know it failed because of the exception.

Thanks for any help!
Steve

PS more tech details:
Machine environment is Windows 2008 64-bit, with .NET 2.0, 3.0 & 3.5 installed.
This same application runs just fine on another machine (Vista 32-bit), with the same directory structure and DLLs, although those were built on that machine

A: 

Yep it should stop when it finds the required dll so the fifth "Attempting to download..." should have found it...

However where is the command line app being run from? If it's the Debug folder then a few things you can try are

  1. Have the dependent dll's in the same folder
  2. Sign the assembly and reference through a .config file in the following format

    <dependentAssembly>
        <assemblyIdentity name="WebServices.dll" publicKeyToken="<whatever this public key it>" />
        <codeBase version="1.0.0.0" href="..\WebServices.dll" />
    </dependentAssembly>
    
  3. Sign them and then put the dependent assemblies in the GAC.

I might be way off but that's a few things to try.

Michael Prewecki
Thanks for the ideas. I've added a little more info to the original question - this same application does work on another machine (altho different OS). The EXE/DLLs involved were each built on the different machines, but they all have the same size. I'll try copying the dependencies locally into the bin\debug dir, but in the end it has to be able to run from another dir :( Thanks!
Steve Eisner
That's ok it can run from another directory, but it'll need to be signed I believe, so that it can be added to the config file as in item 2 above.
Michael Prewecki