You're correct, but what happens when you use an assemblyBinding with a bindingRedirect, like this:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
</runtime>

The tradeoff is that I can support later versions with a config file setting. However, if I upgraded to MVC 4.0, then lower versions are no longer supported and break for existing applications. If I remove the MVC authorizer, then users have an extra dependency on another DLL.

I'm open to your ideas, but need to be cautious about creating a situation that causes problems.

@JoeMayo

Hi JoeMayo,

Actually i was getting the following exception;

Could not load file or assembly 'System.Web.Mvc, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I tried the assemblyBinding with a bindingRedirect with no success at all, my case was very special indeed, the hosting provider denied to install MVC2, i end up downloading the source code and build LinqToTwitter referencing the System.web.mcv 4.0.0.0 dll.


Rodrigo.