A: 

Use a policy or a redirection in the application config file to tell the framework to use the new version as substitute for the old one requested by the plugin.

MSDN has some info on this.

Lucero
We're not talking 1 or two versions difference, though. It is a concern here that the newer version is almost certainly partly or wholly incompatible with the version we currently use and would break our UI code (possibly in hard-to-detect ways).
Mike Burton
One way you can deal with this is by keeping the old API calls with [Obsolete] markings (you can make the Obsolete attribute throw an error on compile, so that new code cannot be compiled against the obsolete methods).
Lucero
+1  A: 

Where has the common UI come from and how difficult would it be to upgrade?

It would seem to me to be the best approach.

ChrisF
It's about a half million lines of "difficult" code (not technically difficult, just Big Ball of Mud), and a small team that has 10 other things on our plate at any given time as well as an infinite stack of direct support work. There are 5 framework versions between us and the version the other app is using. In addition, I don't really want to tie us to the other app's version of this framework if I don't have to.
Mike Burton
Ah - have you investigated linking to specific versions of the framework? Not sure whether that's possible given your set up though.
ChrisF
The difficulty is not with our code, unfortunately - the application is trying to load its copy of the framework and encounters the type conflict.
Mike Burton
We ended up going with this strategy. I was considering having the entire plugin loaded into a separate AppDomain via a bridge, but we decided that would be significantly more work and more prone to breakage in the future. I don't like it, but I guess the universe is not particularly worried what I like in this instance.
Mike Burton
+1  A: 

I do not think the .NET Framework (up to 3.5 at least) can actually load two different versions of a single assembly into an application. I believe I read somewhere that 4.0 may have some additional capabilities in that space, but I would not necessarily count on it.

The only way this can work is if the application loading the plugins loads them into separate AppDomains, but I assume that you have no control over the loading application.

To summarise, I think short of upgrading the version of the library that you use for implementing the plugin I do not think you can work around this issue at this point in time.

jerryjvl
By way of addendum, for a separate plugin where I have more control over the loading scheme, we are using the AppDomain approach. It's not simple to set up, but I think it's worth the day or two it takes to get things working properly.
Mike Burton
A: 

I answered this here http://stackoverflow.com/questions/440675/compile-error-cs0433-on-pre-compiled-asp-net-2-0-site/932840#932840

you can use the extern and alias keywords in your code, and specify a new (other than the default global) Alias when referening an assembly.

extern alias global2;
using global2::System;
RandomNickName42
This works for compile errors, but not runtime ones. I've already attempted to use aliases and they don't solve the issue.
Mike Burton
A: 

Right, I was thrown off that you were looking for dynamic information from the title as it say's "building".

Have you tried this app.config setting?

<configuration> Element
  <runtime> Element
    <assemblyBinding> Element for <runtime>
      <qualifyAssembly> Element

<qualifyAssembly partialName="PartialAssemblyName"
                                  fullName="FullAssemblyName"/>

How about this one?

<configuration>
   <runtime>
      <assemblyBinding>
         <dependentAssembly>
<bindingRedirect  
   oldVersion="old assembly version"
   newVersion="new assembly version"/>

Assuming you allready tried Assembly::Load, the replacement for Assembly.LoadWithPartialName, both should let you load w/o specifying any version info.

Have you read over Dave Grimes workshop for fusion? It's relly comprehensive and goes into the depths of how to manage the type resolution systems of the CLR. He also has a good security and .net instrumentation workshop to boot.

RandomNickName42
I forgot to say, you may need to get a bit more specific about this architechture to really answer any better than those of us who have so far, it's really ambiguious as to which layer you are operating, which leaves quite a few open-ended "did ya?"...
RandomNickName42