メモリに.NETアセンブリを実行するためにAssembly.Load()、次にEntryPoint.Invoke(null, null)を使用しています。これは、ホストプロセスがx86で実行されているアセンブリがAnyCPUである場合を除き、動作します。この場合、実行されたアセンブリはx86コンテキストで実行され、したがって誤動作します。Assembly.Invoke（）がx86およびAnyCPUと競合します
ホストプロセスがx86であっても、AnyCPUコンテキストでAssemlyオブジェクトを実行する方法はありますか？
AnyCPUコンテキストでアセンブリを実行することは、実際には意味がありません。 AnyCPUをターゲットとするアセンブリは、64ビットプロセスにロードされた場合は64ビットに、32ビットプロセスの場合は32ビットにJITされます。このアセンブリが64ビットであるホストプロセスに依存する場合、そのプラットフォームのターゲットは任意のCPUではなくx64でなければなりません。
ほとんどの場合そうです。私のプロジェクトの一環としてやっていることは、.NETアセンブリを圧縮することです。アセンブリは、EntryPoint.Invokeを使用して読み込まれ、実行されます。ホストプロセスが32ビットであるため、アセンブリが64ビットとして実行され、32ビットとして実行されると想定される場合、動作しません。子プロセスがx86の場合、ホストプロセスをAnyCPUとしてコンパイルすることはできません。 – bytecode77
独自のAppDomainで読み込むことができます。もちろん、リモート通信技術を使用して（リモーティング、WCFなど） – RQDQ
AnyCPUとしてビルドされた後、x86でロードされたときにアセンブリが誤動作するのはなぜですか？ AnyCPUは、定義上、AnyCPUで動作するはずです。何かがそれを壊した場合、プロセスのビット安全性がどこかで違反されています。 – ssube
@RQDQ AppDomainはビット数の問題を解決しません。 – vcsjones