tags:

views:

113

answers:

3

This is for research purpose. I have .Net framework 2.0 installed, and I want to load mscorlib.dll 1.1 dynamiclly to execute its specific inner function.

When I wrote this code in C#:

   static void Main(string[] args)
    {
        Assembly assem = Assembly.LoadFrom("C:\\mscorlib_my_private_1.1.dll");
        System.Type type = assem.GetType("System.Console");
        Type[] typeArray =new Type[1];
        typeArray.SetValue(typeof(string),0);
        System.Reflection.MethodInfo info = type.GetMethod("WriteLine", typeArray);
        object[] param = new object[1];
        param[0] = assem.FullName;
        type.InvokeMember("WriteLine",
        System.Reflection.BindingFlags.InvokeMethod, System.Type.DefaultBinder,
        "", param);
    }

The output is "mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Not the expected 1.1 version.

After Googling a lot, I know that mscorlib.dll is very special, but is it impossible?

Cheers~ Sean

A: 

This strikes me as impossible. What you could maybe do, though, is compile a program against every version of the .NET framework you want to target, and then run each of those programs from your main app.

zildjohn01
Hi, Joshua,Can you explain more about this?If you write multiple dll, I think they will still share the same mscorlib.dll as the mscorlib.dll will be loaded dynamically before program start.Please correct if I am wrong.Cheers~Sean
Sean
You're right. I meant compiling separate applications; not sure how I managed to translate that to "DLLs". Edited.
zildjohn01
A: 

You can't load any version of mscorlib other than the one for the .NET framework version you are running. If you request another, you get the one that is already loaded. This is why mscorlib has strict backwards compatibility.

Joshua
Obviously Sean's comment was targeting my post. The reason for strict backwards compatibility is so that an EXE written for .NET 4.0 can load a DLL written for .NET 2.0.
Joshua
+1  A: 

This is not possible: mscorlib.dll depends on internals of the .NET runtime it was written for. These internals will probably have changed in later versions of the .NET runtime!

So even if you could somehow trick the .NET runtime into loading the wrong mscorlib.dll, you'd find that some methods work and others create all kinds of weird errors (behavioral changes, binding errors or access violations).

Ruben