Force x86 CLR sur un assembly 'Any CPU' .NET

Question

Dans .NET, l'option de compilateur 'Platform Target: Any CPU' permet à un assembly .NET de s'exécuter en tant que bit 64   sur un ordinateur x64 et 32 ​​bits   sur une machine x86. Il est également possible de forcer un assembly à s'exécuter en tant que x86 sur un ordinateur x64 à l'aide de l'option du compilateur 'Platform Target: x86'.

Est-il possible d'exécuter un assembly avec l'indicateur 'Any CPU', mais déterminez s'il doit être exécuté dans le CLR x86 ou x64? Normalement, cette décision est prise par le chargeur CLR/OS (comme je le comprends) en fonction de la quantité de bit du système sous-jacent. J'essaie d'écrire une application C# .NET qui peut interagir avec (lire: injecter du code dans) d'autres processus en cours d'exécution. Les processus x64 peuvent uniquement injecter dans d'autres processus x64, et la même chose avec x86. Idéalement, je voudrais tirer parti de la compilation JIT et de l'option CPU pour permettre à une seule application d'être utilisée pour injecter dans des processus x64 ou x86 (sur une machine x64).

L'idée est que l'application serait compilée comme Any CPU. Sur une machine x64, elle fonctionnerait sous x64. Si le processus cible est x86, il devrait se relancer, obligeant le CLR à l'exécuter en tant que x86. Est-ce possible?

Answer 1

Cela fait un moment que j'ai essayé cela, mais je crois que la qualité du processus qui appelle l'assembly détermine s'il sera JITed comme x86 ou x64. Par conséquent, si vous écrivez une petite application console et que vous la construisez en tant que x86, et une autre en x64, l'exécution de l'une ou de l'autre entraînera l'exécution d'autres assemblys chargés en 32 ou 64 bits. Ceci, bien sûr, suppose que vous utilisez une machine 64 bits.

Answer 2

Je ne sais pas si je peux vous aider avec ceci. Mais ceci est mon expérience.

J'ai une application hôte, A.exe (compilée en tant que x86), et j'ai une application client, B.exe (compilée en tant que ANY CPU), à partir de l'application hôte. Et je lance B.exe de A.exe, en utilisant la classe System.Diagnostic.Process.

La question est maintenant si je mets les deux sur une machine x64, puis A.exe se déroulera comme x86, alors que le B.exe se déroulera comme x64.

Mais si A.exe Assemblée appelle c (c.dll, qui est compilé en tant Any CPU), et B.exe appelle également c.dll, puis c.dll suivra l'application qui l'appelle. En d'autres termes, dans la machine 64 bit quand A.exe l'appelle, il se comportera comme x86 dll, alors que quand B.exe l'appelle, il se comportera comme x64.

Answer 3

Vous pouvez trouver comment l'application s'exécute et la modifier statiquement en utilisant l'application CorFlags. Pour savoir comment l'application fonctionnera, utilisez:

corflags <PathToExe> 

Pour modifier la façon dont l'application fonctionnera, utilisez:

corflags /32bit+ <PathToExe> 

Cela rendra le fichier EXE exécuter comme un processus 32 bits. Les informations sur l'exécution de l'assembly sont stockées dans l'en-tête PE.Voir la question de dépassement de pile How to find if a native DLL file is compiled as x64 or x86?.

Si vous souhaitez injecter du code lors de l'exécution, vous devez écrire un profileur .NET dans C++/COM. Voir .NET Internals: The Profiling API et Profiling (Unmanaged API Reference) pour plus de détails.

Vous devrez implémenter le rappel JitCompilationStarted et y faire votre travail. Si vous êtes dans cette direction, vous devrez construire le fichier DLL d'injection à la fois en x86 et x64. Les fichiers DLL natifs seront chargés par le CLR une fois que les variables d'environnement suivantes seront définies:

Cor_Enable_Profiling=0x1 
COR_PROFILER={CLSID-of-your-native-DLL-file} 

Si vous avez réglé correctement alors la version 64 bits « voir » les 64 processus de bits et 32- La version binaire "verra" les processus 32 bits.

Answer 4

J'ai fait quelque chose de similaire en créant deux (vraiment trois) binaires. J'ai eu un détecter si le processus que j'essayais d'injecter était de 32 ou 64 bits. Ce processus lancera alors la version 32 bits ou 64 bits de votre binaire d'injection (par opposition à la relance comme vous l'avez mentionné). Cela peut sembler compliqué, mais vous pouvez facilement y parvenir au moment de la construction avec un événement post-construction qui copie votre fichier binaire en sortie et utilise l'utilitaire CorFlags pour forcer la copie à s'exécuter en 32 bits. De cette façon, vous n'avez pas besoin de déployer l'utilitaire CorFlags avec votre application, ce qui n'est probablement pas légal pour une raison quelconque.

Je pense que cela est assez similaire à votre idée initiale et ne nécessite vraiment pas plus de travail, sauf pour un événement de construction de deux lignes.