Resolving 'missing' assemblies where the assembly has been renamed

We've probably all seen assembly binding redirects kicking around in config files, looking like this:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-9.0.0.0" newVersion="9.0.0.0"/>
  </dependentAssembly>
</assemblyBinding>

What this doesn't allow us to solve is where the assembly has been (for whatever reason) renamed, as you can only redirect from one range of versions of a named assembly to a new version of a named assembly using assembly binding redirects.

I've recently had to get past this issue with a legacy codebase, where two applications are talking to each other via binary serialisation (yes, yes, I know!) but with differently named versions of what's fundamentally the same assembly. The solution I found to this was to handle the AssemblyResolve event for the AppDomain. Here's a simplified example that an sit in a Console app:

static void Main(string[] args)
{
    AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;

var thingThatProcessesSerialisedData = SomeClass.StaticInstantiationMethod(); var result = thingThatProcessesSerialisedData.Load(typeof(SearchEngine.SearchManager), "SerialisedContentKey"); } private static System.Reflection.Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args) { if (args.Name.StartsWith("SearchEngine")) { return typeof(SearchEngine.AdvancedSearchCriteria).Assembly; } else if (args.Name.StartsWith("Some.Other.Thing")) { return typeof(Some.Other.Thing.ClassInSomeOtherThing).Assembly; } else { return null; } }

The return null in the final else means that we haven't overriden the resolution of the assembly in question (as this method will be called for every assembly, not just the ones we care about) and have left it to the CLR to resolve.

About Rob

I've been interested in computing since the day my Dad purchased his first business PC (an Amstrad PC 1640 for anyone interested) which introduced me to MS-DOS batch programming and BASIC.

My skillset has matured somewhat since then, which you'll probably see from the posts here. You can read a bit more about me on the about page of the site, or check out some of the other posts on my areas of interest.

No Comments

Add a Comment