I have now tried many different things and at least now I end up with a different error. However, I don't know if this error happens before or after the previous one (if I have solved the first one or created one that hides it).

What I have done is to change all projects (by manually editing) so that no references reference a specific version, so they look like

<Reference Include="EPiServer">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\[Library]\EPiServer CMS\6.0\bin\EPiServer.dll</HintPath>
    </Reference> 

instead of

<Reference Include="EPiServer, version...publickeytoken...">

This is how I have the references set up in my other (working) Relate project.

The error I get now is a type loader exception in the constructor of the application Global class:

[ReflectionTypeLoadException: Unable to load one or more of the requested types. The following information may be a subset of the Type/LoaderException information present - inspect with debugger for complete view.
Check assemblies [] and/or types []. Information from LoaderExceptions property [Could not load file or assembly 'EPiServer, Version=5.2.375.7, Culture=neutral, PublicKeyToken=8fe83dea738b45b7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)].]
   EPiServer.Framework.Initialization.InitializationModule.StaticInitialization(HostType hostType) +372
   EPiServer.Framework.Initialization.InitializationModule.FrameworkInitialization(HostType hostType) +53
   EPiServer.Global..ctor() +76

I have an assembly redirect for EPiServer.dll and a lot of other assemblies so that they should use the correct version (6.0.530.0), so I'm very annoyed that it tries to load 5.2.375.7.

The runtime section is however exported to an external file (<runtime configSource=...) which is a setup we have had working for quite some time. Now though, there seems the external files are ignored, because if I copy-paste the contents of the external file into web.config it produces yet another error: a null reference in the episerver config section (which is also exported). Trying the same copy-paste trick for that yields no further results though.

Is there a tool you can recommend which can give any hints to what assembly is trying to load the old episerver version? I have a feeling that these latest changes only mask the first error and that the real problem is that two versions of EPiServer.dll get loaded causing the interface mismatch.

Any ideas are very welcome, I am getting very frustrated by this.

I had a simular problem once, and the faulty dll was

    <Reference Include="System.ComponentModel.Composition, Version=2009.22.10.0, Culture=neutral, PublicKeyToken=8fe83dea738b45b7, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\ExternalLibs\System.ComponentModel.Composition.dll</HintPath>
      <Private>True</Private>
    </Reference>

Had to spesify as above to get it to work. this was with a IInitializableModule and a relate+ site running .net 4

To get a closer look you can try to set

HKLM\Software\Microsoft\Fusion\LogResourceBinds registry value to 1 (the value is a DWORD).

this will give you what "inner" dll is causing the problem

//http://stackoverflow.com/questions/5616673/how-to-find-out-which-dependency-is-failing-to-load

Thanks, I'm checking these things out. I had a specific reference for the System.ComponentModel.Composition, but with SpecificVersion true, no hint path and private missing (defaults to false?). I had the same thing in my working project. I tried your combination of parameters as well (different path of course) and the working project still works while the non-working project still doesn't work...

I tried to get the bindings to log but it seems I can only get windows programs to log their binds, not the IIS...

I'm gonna try to get back to the state where I got the composition error and try your suggestion from there.

I get the IIS bindings, but maybe I rebootet to get it ti activate

Are you running IIS7 with a 64-bit only app pool? I have som 64-bit assemblies so I can't enable 32-bit compatibility on the app pool or use cassini.

I got it logging now by changing the application pool user to my own user account instead of network service. Hunt goes on...

Edit: There's no need to hack the registry to enable logging, just launch the Assembly Binding Log Viewer (fuslogwv.exe) and use it's settings to enable logging for assembly binding errors or all assembly binding.

I got back to the old composition error by removing the EPiServer.Common.Web.Authorization.Multiplexing.dll file from the bin folder. That was the one calling the old EPiServer.dll version. Something is very strange though, I have this file in my other project without any problems, probably because the assembly redirect takes care of it. For some reason it doesn't in this project...

Problem solved. It seems it was the fact that we had moved the runtime section with assembly redirects to an external file. This was masked by other errors. Strange though that it worked before I installed episerver mail, and does for that application in all environments. I guess we were just lucky that there were no assembly conflicts so the "missing" redirect section wasn't a problem. Or something... If I ever figure it out I will post back.