AppDomain.CreateInstanceAndUnwrap fails if library's name has been changed

Greetings,

I have an application that allows users to import libraries (.NET DLLs) they've created, as long as the library conforms to specific guidelines I've given them (use my namespace, decorate methods with my attribute, etc.). I copy each user lib to an internal directory and then load it into its own app domain (so user can unload it if desired). Therefore, I have the limitation that you can't load two libs with the same name.

I'd like to remove this limitation without placing each user lib into a unique subdirectory of my internal directory. I tried renaming the user lib when I copy it to my internal directory. For example, if the user says to import c:\SomeLib.dll and I detect I already have a lib named SomeLib.dll loaded, I copy the new file to ...\MyInternalDir\SomeLib2.dll. However, when I do this, my load command:

(ISomeInterface) iSomeLib = someAppDomain.CreateInstanceAndUnwrap(
                                    "SomeLib2", 
                                    "SomeNamespace.SomeClassInSomeLib");

throws an exception:

FileLoadException: Could not load file or assembly 'MyLib2' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Is there some way to tell .NET "Ignore that fact that the file name has been changed since it was compiled"?

Have you considered trying the overload:

someAppDomain.CreateInstanceFrom(string assemblyFile, string typeName)

Given that you know the new dll name, since you did the rename, you can ask the App Domain to create the instance from the specified dll. That way it .Net shouldn't care whether the assembly name and the assembly filename match.

I should have prefaced this with "I haven't actually tried it", but it is just a suggestion!