Attempts at Dll rebasing in .net4 don't appear to work

I'm experimenting with Dll rebasing on a small test solution running on .net4 consisting of one small .exe and three small .Dlls. The assembly references have been set up correctly and the program compiles and runs just fine.

The aim of this exercise is to examine how rebasing works so that I can tie it in with ngen and get performance increases in a massive project I'm working on.

I've tried many different methods of rebasing the Dlls and monitored the results using vmmap, the visual studio module debugger window and process explorer; nothing has been successful so far:

1. I've set the Build->Advanced->DLL Base Address setting to 0x41000000, 0x42000000 and 0x43000000 for Dll1.dll, Dll2.dll and Dll3.dll respectively. These addresses were definitely saved as the preferred base address in each of the Dlls, but for each run the Dlls rebased their images erratically to many different locations in memory.

2. I've tried using this application. The logs it generate show that the Dlls do indeed have the preferred base address (as selected by me) built in, however at runtime the results are still erratic

3. I've tried using ngen. This results in the .ni versions of the Dlls being loaded alongside the original Dlls, and all 6 of them having erratic memory locations nowhere near the ones I asked for.

4. I've tried sticking my images in the GAC. It was heartening to see that only the GAC'd versions of the Dlls were loaded, however their memory locations were still erratic.

5. I've tried what feels like every combination of the above. No success.

Poking around at runtime using VMMap shows that there is a massive ga开发者_StackOverflow中文版p of available memory in the address space between 0x10000000 and 0x50000000, so there should be no collisions and no need for Dll rebasing to occur. The Dlls are also very small and the 0x01000000 gap I'm leaving between them is extremely generous, so they shouldn't be colliding with each other.

What am I missing?

My main reference during this exercise has been this article, which is highly informative, but was written in 2006 for .Net2: Has something fundamental changed between then and now?

I seriously doubt it makes much difference, but here's the code I'm using just in case:

Program.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using Dll1;
using Dll2;
using Dll3;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            Thread.CurrentThread.Name = "Poodle";
            Console.ReadLine();
            //Thread.Sleep(10000);
            Blah();
        }

        static void Blah()
        {
            Console.WriteLine(Class2.shrooms(5, 'h'));
            Class3.teenAngst();
            Class1.Wait();
        }
    }
}

Class1.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Dll1
{
    public static class Class1
    {
        public static void Wait()
        {
            Console.ReadLine();
            Console.Write("   ");
        }
    }
}

Class2.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Dll2
{
    public static class Class2
    {
        public static string shrooms(int argc, char argv) 
        {
            return "Ranchdaddyx   ";
        }
    }
}

Class3.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Dll3
{
    public static class Class3
    {
        public static void teenAngst()
        {
            Console.Write("Belonging   ");
        }
    }
}

It is not necessary to rebase JIT compiled code:

JIT-compiled code does not have a rebasing problem since the addresses are generated at run time based on where the code is placed in memory. Also, MSIL is rarely affected by base address misses since MSIL references are token-based, rather than address-based. Thus when the JIT compiler is used, the system is resilient to base address collisions.

.NET assemblies and DLL rebasing

If I want to rebase my DLL's, how do I go about doing it?

http://msdn.microsoft.com/en-us/magazine/cc163610.aspx

http://support.microsoft.com/kb/969305

It turns out that ASLR (Address Space Layout Randomization) is the culprit of my confusions. Apparently you can turn it off, but you're sacrificing safety/making a lot of work for yourself. I consider the whole adventure a failed experiment.

.Net .dll's are a very different beast from their unmanaged equivalents. I honestly didn't think that rebasing was relevant.

Check out this MSDN article. Which, among other things, encourages you to NOT rebase. And gives at least one compelling reason NOT to (it could invalidate the signature of a strongly signed assembly). The article also discusses the potential benefits of NGEN (as does your link):

CLR Inside Out