As you may noticed from my previous post loader treats v1.0 and v1.1 managed executables as 32bit only regardless of the ILONLY flag. The main reason for this is that before v2.0 there was no way to express that an executeble has or does not have dependencies on a particular platform. However everything was supposed to run on 32bit. So, to be on the safe side loader on 64bit machines treats pre-v2.0 managed executables as 32bit only. Basically if you do not have dependencies on 32bit components such as COM32 libraries or native dlls, the code could potentially run in 64bit mode, but loader cannot know that.

There is one interesting observation - v2.0 runtime is backward-compatible with previous versions and you can load and use v1.0 and v1.1 assemblies from a v2.0 assembly. Also the decision on whether to run as 32bit or 64bit is done only once per process based on the format of the entry point executable. As a result you can create a simple wrapper/launcher in v2.0 which will run natively and in turn load and execute pre-2.0 executables. By the time they are loaded the process will be already running as 64bit.

NOTE. This is basically a way to get around loader safekeeping so should be used for demonstration only.
Also this will obviously work only as long as your pre V2.0 code is not using 32bit dependencies.

'compile this as an "anycpu" application, say Launcher.exe
'run this as " Launcher.exe  my_V1_1_foo.exe "
Sub Main()
 'get the name of the executable
Dim exe_path As String = My.Application.CommandLineArgs(0)
'find the entry point of the executeble
Dim entry_point As Reflection.MethodInfo = Reflection.Assembly.LoadFile(exe_path).EntryPoint
'run it!!
entry_point.Invoke(Nothing, New Object() {})
End Sub