Wir haben eine Software in 32 und 64 Bits, die unsere EXE aufruft und Ereignisse an sie weiterleitet (wie ein Plugin).
Die Sache ist die, dass unsere exe in derselben Bitheit (x86 / x64) wie die aufrufende Software ausgeführt werden muss (wenn die Software in 32-Bit-Version ausgeführt wird, muss unsere EXE in 32 Bits laufen, wenn die Software in 64 Bits läuft Version unsere exe muss in 64 Bits laufen). Die Windows-Version ist 64-Bit, aber der Client kann die Software in 32-Bit-Version oder 64-Bit-Version ausführen.
In Visual Studio (2015) hängt die Target AnyCPU-Option nur von der Windows-Version ab (+ 32-Bit-Kontrollkästchen bevorzugen), aber wir müssen von der aufrufenden Software Process abhängig sein.
Gibt es eine Option oder Lösung, die wir implementieren können, anstatt auf jeder Plattform (x86 und x64) zu kompilieren?
Es gibt keine Windows-Betriebssystemvoraussetzung, dass zwei separate Prozesse die gleiche Bitness haben müssen, um miteinander zu kommunizieren - also nehme ich an, dass Sie eine interne Anforderung haben, dass beide Prozesse die gleiche Bitness haben. Wenn Sie unbedingt sicherstellen müssen, dass dieselbe EXE entweder in 32-Bit- oder in 64-Bit-Ausführung dynamisch ausgeführt wird und diese Entscheidung zur Laufzeit getroffen wird, können Sie Ihre AnyCPU-kompilierte Anwendung zur Laufzeit mit corflags.exe Dienstprogramm, das mit Visual Studio ausgeliefert wird.
Sie können corflags.exe wie folgt starten (mit System.Diagnostic.Process):
%Vor%Um es zu zwingen, 32bit zu laufen, und
%Vor%Zurück zu AnyCPU (64-Bit auf einem 64-Bit-Betriebssystem)
Die Lösung wäre, dass Sie eine Kopie von corflags.exe in Ihrer Laufzeitumgebung bereitstellen würden. Dann kann Ihre Host-Anwendung ihre aktuelle Bissigkeit erkennen, indem sie sizeof (IntPtr) überprüft, um zu sehen, ob es 8 oder 4 ist; und erstellen Sie eine Kopie von corflags.exe entsprechend (mit System.Diagnostics.Process), bevor Sie die Datei ourapp.exe starten.
Das ist sehr HACKY . Achtung. Offensichtlich haben Sie viele Probleme, wenn Sie zwei Kopien Ihrer ourapp.exe gleichzeitig auf demselben Computer ausführen müssen. Es wäre ideal, eine eindeutige Kopie von ourapp.exe in einem lokalen Benutzerordner zu erstellen, bevor Sie sie ändern und von dort aus starten, um Race-Bedingungen von mehreren Instanzen und UAC-Eingabeaufforderungen abhängig von Ihrer Zielumgebung zu vermeiden.
Ist es unbedingt erforderlich, dass der Prozess auf der Registerkarte Prozesse des Task-Managers als solcher angezeigt wird? Oder kann es in einem anderen Host-Prozess enthalten sein?
Wenn Sie Letzteres verwenden, können Sie ein Stub-Projekt mit der folgenden Main -Methode erstellen und dann zwei Versionen der ausführbaren Datei kompilieren: eine als 32-Bit ( LaunchX86.exe ) und die andere 64 -Bit ( LaunchX64.exe ).
Hinweis: um die Dinge einfach zu halten, hat das obige sehr grobe Einfangen von Ausnahmen und bildet diese auf einige feste Rückgabewerte ab.
Beachten Sie auch, dass wir in der Methode Invoke() keine Parameter an die Methode Main() für WPF-Anwendungen übergeben, da die WPF-Anwendung automatisch die gleichen Parameter wie die des Launcher erhält. Dies ist nicht ideal, aber verschiedene Problemumgehungen sind möglich, z. B. das Setzen einer Umgebungsvariablen mit Environment.SetEnvironmentVariable() vor dem Start, das Prüfen auf diese Variable in der Zielanwendung mit Environment.GetEnvironmentVariable() und (falls vorhanden) das Verwenden ihres Inhalts anstelle der normalen Methode.
Dann starten Sie von Ihrer Hauptanwendung aus die ausführbare Datei des jeweiligen Hosts, abhängig von der Bissigkeit Ihres aktuellen Prozesses:
%Vor%Tags und Links c# x86 visual-studio-2015 target-platform anycpu