.NET assembly binding failure (different versions with a redirect), weird!

Question

I'm trying to troubleshoot an application built against version 9.1 of a vendor's libraries on a machine that has their 9.3 version installed. The vendor provided a publisher policy file that redirects all versions from 9.0 onwards to their 9.3 dlls, and it is installed in the GAC.

With a newer version of our application, built against version 9.2, the publisher policy file is found and everything Just Works. With the 9.1-linked version, the publisher policy file is never mentioned at all in the fuslogvw results.

Here is an example of a successful load from fuslogvw:

LOG: This bind starts in default load context.
LOG: Using application configuration file: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe.Config
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Publisher policy file is found at C:\WINDOWS\assembly\GAC_MSIL\policy.9.2.ESRI.ArcGIS.System\9.3.0.1770__8fc3cc631e44ad86\ESRI.ArcGIS.System.config.
LOG: Publisher policy file redirect is found: 9.2.0.1324 redirected to 9.3.0.1770.
LOG: ProcessorArchitecture is locked to MSIL.
LOG: Post-policy reference: ESRI.ArcGIS.System, Version=9.3.0.1770, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86, processorArchitecture=MSIL
LOG: Found assembly by looking in the GAC.
LOG: Binding succeeds. Returns assembly from C:\WINDOWS\assembly\GAC_MSIL\ESRI.ArcGIS.System\9.3.0.1770__8fc3cc631e44ad86\ESRI.ArcGIS.System.dll.
LOG: Assembly is loaded in default load context.

And, here is the failure:

LOG: This bind starts in default load context.
LOG: Using application configuration file: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe.Config
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: ESRI.ArcGIS.System, Version=9.1.0.722, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Program Files/NatureServe/Vista/ESRI.ArcGIS.System.DLL.
LOG: Attempting download of new URL file:///C:/Program Files/NatureServe/Vista/ESRI.ArcGIS.System/ESRI.ArcGIS.System.DLL.
LOG: Attempting download of new URL file:///C:/Program Files/NatureServe/Vista/ESRI.ArcGIS.System.EXE.
LOG: Attempting download of new URL file:///C:/Program Files/NatureServe/Vista/ESRI.ArcGIS.System/ESRI.ArcGIS.System.EXE.
LOG: All probing URLs attempted and failed.

Note: the display name, culture, and public key tokens are identical.

So, what is different (besides the version #)? Why isn't .NET finding the policy file? What black magic will we need to do to overcome this (until we can just drop our support for their 9.1 platform)?

Answer 1

Ah, the magic of posting your problems on the internet:

It looks like the path to the policy file includes the '9.2' version string as part of a folder name, which I'm can only assume means it will be resolved only for requests for the 9.2 version of the vendor's libraries.

So it looks incompletely installed (since the policy file itself redirects version 9.0 onwards).

We could include the redirects ourself in an application config file, as described here; although it would need to be conditional on what version of the vendor's software is present.

I admit I'm not too psyched about that as a solution...