Determining the Referencing Assembly

Say you’re debugging your application and you see that version 1.0 of an assembly is being loaded when you thought it should be version 2.0. Where is the reference to 1.0 coming from?

The easiest way to find out is to look at the Fusion log for this bind. If the version 1.0 assembly was successfully loaded, use the ForceLog/”Log all binds” option of FusLogVw. Then, look for the line in the log showing the calling assembly:

Calling assembly : referencingAssembly, Version=, Culture=neutral, PublicKeyToken=12ab3bf24c56c45b.

It shows the display name of the calling assembly when available. It doesn’t tell you whether this is a static or a dynamic reference because Fusion doesn’t know or care (that doesn’t matter for binding purposes). So, this could mean that referencingAssembly was built against the other 1.0 assembly, or that it asked for it at runtime via Assembly.Load(), etc.

Sometimes the calling assembly is not specified in the log. There are a few possible cases where that happens:

  • The assembly was requested by unmanaged code (interop).
  • The calling assembly was in another appdomain (AppDomain.CreateInstance(), etc.).
  • The calling assembly had not been loaded through Fusion (Assembly.Load(byte[]), Assembly.LoadFile(), etc.).


Comments (2)

  1. Matt says:

    I have some code that works fine in the default domain, however if I create a new domain:
    AppDomain newDomain = AppDomain.CreateDomain("New"+FriendlyName);
    And run the code in this new domain, I get:
    Unhandled Exception: System.DllNotFoundException: Exception from HRESULT: 0x80131524.
    The fusion log shows me nothing, all the dll’s needed are in the EXE directory from which the EXE is being run from. It works in the default domain, but fails in a created domain. How do I resolve the exception, and find out the issue. Any help would be excellent, as I have tried everything I can think of so far with no joy.
    (The code that is running is a 10 line C# application that calls a Managed C++ wrapper around TIBCO RV, which send a message out on RV and listen to RV messages)

  2. Suzanne says:

    The owner of this code said that this means that user code called into an IJW dll without its managed part being loaded in the current appdomain. It’s hard to tell more without your callstack at the time of the exception.