Da in 64-Bit-Anwendungen keine 32-Bit-Prozesse eingebunden werden können, überlege ich, wie ich visuelle 32-Bit-ActiveX-Steuerelemente dennoch für das Design verfügbar machen kann. Irgendwie müsste ich den 32-Bit-Prozess mitsamt dessen Oberfläche in einen Windows-Forms-Dialog übernehmen, dass seinerseits der 64-Bit-Anwendung angehört. Das 32-Bit-Steuerelement müsste demnach über einen Out-Process-Server angeboten werden, dessen Fensterinhalt auf das 64-Bit-Formular umgeleitet werden (das müsste über die Fensterkennung und per API-Funktion theoretisch möglich sein). Wer hat sowas schon einmal probiert? Lohnt sich der Aufwand, oder sollte ich das alte Steuerelement besser ersetzen (ggfs. Durch ein eigenes 64-Bit-Steuerelement)?
Ich habe die Erfahrung gemacht, dass es aus Performancegründen besser ist, ActiveX-Controls durch ihre .NET-Pendants zu ersetzen. In einem Migrationsprojekt musste ich eine größere VB6-Anwendung, welche zwei komplexere ActiveX-Controls (ein selbst geschriebenes und ein gekauftes) verwendet, nach .NET portieren. Wir hatten zunächst mit massiven Performance-Problemen zu kämpfen (die Anwendung war ca. um den Faktor 10 langsamer), die erst gelöst wurden, nach dem wir das gekaufte Control durch eine .NET-Komponente erstzt haben und aus dem selbst geschriebenen Control eine Managed-C++ dll gemacht haben.
Andererseits, wenn du mit Visual Studio arbeitest, kannst du ActiveX-Controls bequem über den Designer verwalten, da VS eine 32-Bit Anwendung ist. Du hast dann aber dein Problem nur verschoben, da die Referenzen zur Laufzeit nicht aufgelöst werden können.
Wenn die Anwendung selbst nicht unbedingt als 64-Bit Anwendung laufen muss, kannst du zum Kompilieren auch die Plattform X86 definieren. Dann läuft deine Anwendung als 32-Bit in der SysWOW64 Emulation und kann auf die ActiveX-Controls zugreifen.
