2009-04-02 3 views
2

Wir haben mehrere große MFC-Anwendungen, die derzeit ein COM-Objekt aufrufen, um einen komplexen Dialog zu erzeugen. Wir möchten den Dialog in die Anwendungen integrieren - wir wollen nicht weiter ein COM-Objekt verwenden.Wie kann ich ein .NET-Formular von einer MFC-Anwendung aufrufen?

Ich untersuche die Möglichkeit, den Dialog in .NET als ein separates Projekt zu erstellen (Windows-Formulare, nicht WPF) und ein zweites C++/CLI-Projekt bereitzustellen, das es aufruft und aus normalen C++ - Code aufgerufen werden kann. Diese Struktur ist so, dass die verschiedenen Anwendungen, die den Dialog enthalten müssen, nur die Projekte in ihren Lösungen aufnehmen können. (Die Apps sind Legacy-Apps, deren Umschreiben nicht möglich ist - wir verschieben sie langsam nach .NET, aber dies ist ein mehrjähriges Projekt. Die Konvertierung der Apps in C++/CLI ist keine Option.)

Ich habe dies erstellt und getestet von einer Modellanwendung, aber bis jetzt kann ich es nicht in der einfachsten der großen Apps arbeiten, und basierend auf einigen Dingen, die ich gelesen habe, fange ich an bezweifle, dass es möglich ist. (Siehe this link, besonders. Ich bin mir der this Stackoverflow question bewusst, aber es scheint nicht relevant zu sein.)

So. Ist das überhaupt möglich? Irgendwelche Vorschläge zum weiteren Vorgehen?

Antwort

0

ich endlich dieses Problem mit Hilfe eines sehr guten Microsoft Support-Spezialisten gelöst. Es gab zwei Probleme, eines war, dass das Threading der Boost-Bibliothek mit C++/CLI in seinem Standardzustand inkompatibel ist. Eine Lösung besteht darin, mit einer anderen Gruppe von Flags zu kompilieren und sie dann statisch zu verknüpfen. Der andere ist, es als eine dynamisch verknüpfte DLL zu verwenden, was ich gerade gemacht habe.

Der zweite Teil der Lösung besteht darin, CLR-Threading in der verknüpfenden Eigenschaft auf STA festzulegen, da OLE-Initialisierungen mit einer nicht hilfreichen Nachricht fehlschlagen, wenn dies nicht der Fall ist.

1

Waren Sie erfolgreich beim Aufruf des C++/CLI-Projekts in Ihre .NET-Komponente? Ich würde versuchen, einzugrenzen, zwischen welchen der beiden Schichten es nicht durchkommt.

Da C++ - Code COM-Komponenten aufrufen kann, können Sie einfach die .NET-DLL mit COM-Unterstützung kompilieren. Ich habe COM in C++ noch nicht selbst gemacht, deshalb kann ich Ihnen die Einzelheiten nicht erklären. Aber ich habe viele COM .NET DLLs gemacht und diese Seite ist ziemlich einfach. Normalerweise nur ein paar Checkboxen in den Projekteigenschaften (ich denke, unter einer erweiterten Schaltfläche in der Registerkarte Montage).

+0

Wir haben bereits eine C++ - basierte COM-Komponente. Der Zweck dieses Projekts ist es, die Notwendigkeit von COM zu beseitigen. – mlo

+0

Ich bekomme Fehler in der OLE-Initialisierung, bevor die Ausführung überhaupt in die Nähe des betreffenden Codes kommt. Das Googlen dieses Fehlers führte mich zum ersten Link. – mlo

0

Warum brauchen Sie den Zwischenhändler? Warum nicht einfach

Native C++ app --> C++/CLI class library 

Die C++/CLI-Bibliothek bietet eine native Wrapper um einen CWinFormsView oder CWinFormsDialog.

Aber, warum müssen Sie COM beseitigen? Es ist viel schnell und sobald Sie die Schnittstellen gut implementieren können, ist die Zeremonie nicht so schlecht.

+0

Es gibt eine Menge C++ - Code im vorhandenen COM-Objekt, das ich lieber nicht auf .NET portieren würde. Die Struktur, die ich verwende, hat zwei komplizierte Dialoge als separate C# -Projekte, die aus dem Großteil des Codes aufgerufen werden, der der alte C++ - Code ist.Das heißt genau wie jetzt von der Haupt-App aus. – mlo

+0

OK, dann bin ich verwirrt, was die Frage ist. Hast du das funktioniert oder nicht? –