.NET application compiled with Any CPU as a target and without "Prefer 32-bit" set, will run in 64 bits whenever it can. If application is developed and tested in that manner, this is actually a good thing. Even if you don't care about a vastly more memory you can use, you should care about the fact Windows Server these days exists only in 64-bit flavor. Yes, with prefer 32-bit checked, your application is going to be capable of running on it. However, on all development machines you will run it in 32 bits and thus find some errors only once your application is running 64-bit on a (headless) server. Every developer should run his code in 64-bit. No excuses.
Saying that, if you stumble across a signed Any CPU .NET application that used to work on 32-bit OS just fine but stopped working with a move to 64 bits, you have a problem. Even if your environment does support 32-bit computing, stubborn code will hit bug again and again. If application was unsigned, you might go the route of editing binary directly. With signed binaries you'll have to be a bit more sneaky.
One trick is to re-configure .NET loader:
> C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe SetWow
loading kernel32...done.
retrieved GetComPlusPackageInstallStatus entry point
retrieved SetComPlusPackageInstallStatus entry point
Setting status to: 0x00000000
SUCCESSHowever, this is a machine-wide setting and requires administrator access.
Another way is cheating the system and creating a loader application with settings you want (e.g. x86). Then load destination assembly and simply start it:
var targetAssembly = Assembly.LoadFrom("AnyCpuApplication.exe");
targetAssembly.EntryPoint.Invoke(null, null);As "proxy application" is 32-bit, .NET loaded will load assembly into its domain with the same settings and our problem is solved.
Example code is available.