4. MFC und CLR

MFC und CLR

  • ?

    Kann ich ihn einem MFC Projekt ohne Common Language Runtime Support
    ein MFC Projekt der Common Language Runtime Support unterstützt aufrufen?

    Für jeden rat, Beispielt bin sehr dankbar

    0
  • Mod

    Was verstehst Du unter einen "Projekt aufrufen"?

    Wenn Du in VS-2005/8 ein MFC Projekt baust, dass die Standard-DLLs der MFC und CRT verwendet, dann hast Du ale Vorraussetzungen um auch .NET Komponenten direkt aus der MFC heraus aufzurufen.

    Wenn das "andere Projekt" eine in sich geschlossene DLL ist, die wenn möglich eine normale/native Schnittstelle hat, dann spricht doch sowieso nichts dagegen.

    Wenn das "andere Projekt" sich per COM ansprechen lässt, dann spricht auch hier nichts dagegen.

    Meine Kristallkugel schweigt sich aber leider über die genaueren Hintergründe Deiner Frage aus... 😃

    0
  • ?

    Sorry für die Ungenauigkeit 😡

    Unter einen "Projekt aufrufen" verstehe ich eine DLL die eben clr unterstütz in einem
    "reinem" MFC Projekt (exe) ohne clr Unterstützung aufzurufen bzw. einbinden.

    Mein Problem/Überlegung ist folgendes, ich habe eine MFC - Applikation die mehrere
    Dialogen (DLL's) einbindet, das ganze ist relativ groß, so das ich es nicht von heute auf morgen auf .NET umstellen kann.
    Jetzt habe ich mir überlegt das ganze langsam angehen, spricht erst nur neue Anforderungen als .NET (C#) DLL's zu programmieren und die eben in das "alte" MFC Projekt einbinden, da ich so wenig wie möglich an dem alten Projekt basteln möchte will ich es folgender maßen machen.
    Die alte MFC exe bleibt so wie sie ist, dazu baue ich eine neue MFC DLL clr dort binde ich meine C# View und das ganze erst in der MFC exe.

    0
  • Mod

    Warum eine neue MFC DLL? Baue eine pure DLL in C++/CLI mit entsprechenden Nativen Einstiegspunkten.
    Klar MFC DLL geht auch und ist für den Aufruf von WinForm Objekten auch gut geeignet. Aber dennoch musst Du auch intern die Nahtstelle zwischen altem und neuem Code gut konzipieren. Hier ist das größere Problem im mehr Design als im Machen.

    Ich weiß nicht wie gut, Du das alles Kapseln möchtest und kannst. Davon wird extrem viel abhängen um solch eine schrittweise Migration durchzuführen.

    0
  • ?

    Martin Richter schrieb:

    Warum eine neue MFC DLL? Baue eine pure DLL in C++/CLI mit entsprechenden Nativen Einstiegspunkten.

    hm.. und wie rufe ich die dann im eine MFC Applikation auf.

    Martin Richter schrieb:

    Aber dennoch musst Du auch intern die Nahtstelle zwischen altem und neuem Code gut konzipieren. Hier ist das größere Problem im mehr Design als im Machen.

    Genau hier liegt mein Problem, denn ich habe reines unmanage code der viele unmanage dll's aufruft uns so soll muss es erstmal bleiben, in dem will ich die Möglichkeit einbauen managed code (C# ) einbauen.

    Martin Richter schrieb:

    Ich weiß nicht wie gut, Du das alles Kapseln möchtest und kannst. Davon wird extrem viel abhängen um solch eine schrittweise Migration durchzuführen.

    Wie wurdest Du auf mein stelle vorgehen?

    0
  • J

    Ja, Du kannst einfach eine DLL aufrufen, welche die CLR benötigt.

    Es ist zwar sehr unschön, aber es geht. Zu beachten ist aber: Wenn Du dann noch eine weitere DLL "aufrufen" willst, die auch die CLR benötigt aber gegen eine andere Version der CLR gelinkt wurde, so geht dieser Aufruf schief!

    Dies ist auch der Grudn warum Explorer-Extensions keine CLR erlauben!

    0
  • ?

    Jochen Kalmbach schrieb:

    Ja, Du kannst einfach eine DLL aufrufen, welche die CLR benötigt.
    Es ist zwar sehr unschön, aber es geht

    wie ist denn schön, bzw Gegenfrage kann ich aus eine CLR Applikation reine MFC DLL's aufrufen und wie groß ist der Aufwand?

    0
  • Mod

    @CLR:
    Ich würde ein Konzept aufbauen in dem ich klar trenne was ich demnächst managed mache und was nicht.

    Einfach mal jetzt so ein bisschen WinForms Code einbauen wäre nicht nach meinem Geschmack, obwohl es die MFC erlaubt. Du bekommst irgendwann den Managed/Unmanaged Teil nicht mehr auseinander.

    Grundsätzlich glaube ich nicht, dass sich ein MFC Projekt schrittweise nach .NET migrieren lässt. Das ist mein persönlicher Eindruck. Die Welten sind zu unterschiedlich. Am Ende kommt es aufs Neuschreiben raus.
    Hier meine ich nicht, dass man Module austauscht, die normierte Schnittstellen haben. Das ist ein Kinderspiel, aber hier ist es ja auch wurscht wie die Module programmiert waren. Wenn sie gut gebaut sind, sind sie austtauschbare schwarze Kisten.

    Kommt nun die Frage dazu: Warum glaubst Du dies tun zu müssen?
    Warum lebst Du nicht mit der MFC und schreibst dann das Projekt neu, wenn es sowieso sich überlebt hat.

    @Jochen: Warum ist es unschön eine native DLL-Schnittstelle zu bauen, die die CLR benötigt oder intern Managed Code nutzt? Die bekannten Probleme hast Du angesprochen, aber es oft der einzige Weg.
    Ich muss dies auch mit einigen Komponenten machen. Eleganter ist oft die COM Anbindung, aber letzten Endes ist es das selbe und man lebt mit dem selben Restriktionen wenn es Inproc Server sind.

    0
  • ?

    Dh. du wurdest neu Komponenten neu in .NET schreiben und alte Sachen
    schrittweise nach .NET portieren bzw. umschreiben.

    Aus drei Gründen:
    1. MFC stirbt irgend wann
    2. .NET programmiert man schneller "schöner"
    3. Mein BOOS will so 9
    Das Projekt neu zu schreiben ist wie ich schon sagte ein großer Aufwand der durch mehre Jahre gehen wurde, deshalb auch versuch auf die sanfte art und weise :

    0
  • S

    CLR schrieb:

    Aus drei Gründen:
    1. MFC stirbt irgend wann
    2. .NET programmiert man schneller "schöner"

    1. Jeder stirbt irgendwann einmal. Aber es ist ziemlich unwahrscheinlich, dass die MFC in den nächsten Jahren abnippelt.

    2. Kommt darauf an. Ich finde es immer faszinierend, wie oft .NET-Programme doch Windows- oder COM-Funktionen über P/Invoke aufrufen müssen. Also lieber gleich beim Original bleiben.

    0
  • J

    CLR schrieb:

    1. MFC stirbt irgend wann

    Irgendwann vielleicht aber sicherlich nicht in den nächsten Jahren; im Gegenteil, es wird von seiten MS massiv ausgebaut und unterstützt:
    http://blog.kalmbach-software.de/2007/11/07/mfcupdate-mfc-now-has-a-visual-manager-and-will-add-office-2007-ribbon-controls-and-many-more-features/
    http://blog.kalmbach-software.de/2008/01/08/mfc-update-mfc-feature-pack-for-vs2008-now-available-als-beta/

    0
  • J

    Martin Richter schrieb:

    @Jochen: Warum ist es unschön eine native DLL-Schnittstelle zu bauen, die die CLR benötigt oder intern Managed Code nutzt? Die bekannten Probleme hast Du angesprochen, aber es oft der einzige Weg.
    Ich muss dies auch mit einigen Komponenten machen. Eleganter ist oft die COM Anbindung, aber letzten Endes ist es das selbe und man lebt mit dem selben Restriktionen wenn es Inproc Server sind.

    Hallo Martin,

    es ist aus den gesagten Gründen unschön, da es schlimmsten Falls passieren kann, dass Du eine DLL nicht mehr laden kannst, weil schon jemand anders eine inkompatible CLR Version geladen hat, ohne dass Du es mitbekommen hast.

    0
  • ?

    ok, abgesehen davon ob es schön und sinnvoll ist weis jemand einen Beispiel wie man managed code (C# ) in unmanage aufruft/einbindet

    Danke im voraus

    0
  • J

    CLR schrieb:

    ok, abgesehen davon ob es schön und sinnvoll ist weis jemand einen Beispiel wie man managed code (C# ) in unmanage aufruft/einbindet

    Das geht nicht.

    Du kannst nur:
    - die CLR hosten und dann Methoden aufrufen (sehr aufwendig)
    - eine C++/CLI DLL schreiben die "native" C-Funktionen exportiert aber intern CLR verwendet; diese native Funktionen kannst Du dann direkt aufrufen
    - erstelle Deine Anwendung als C++/CLI, dann kannst Du direkt die CLR Sachen verwenden.
    - und natürlich noch via "regasm" und COM-Interop

    0
  • ?

    Hm, dieser Thread wirft einige Fragen bei mir auf, vielleicht könnt ihr diese beantworten..

    Angenommen ich habe ein MFC Programm welches eine C++/CLR DLL in .NET 2.x als Plugin verwendet und später ein neues Plugin mit CLR Unterstützung hinzukommt, welches z.B. in 3.x entwickelt wurde, läuft nur die DLL die zuerst geladen wird?
    Wenn zuerst die 3.x geladen wird, läuft dann noch die 2.x wegen der Abwärtskompatibilität?

    Um dem Problem zu entgehen, könnte man ja in der Hauptanwendung ebenfalls die CLR einbinden um z.B. 2.x zu erwzingen, aber wie verhält sich dann die Anwendung, wenn ein 3.x Plugin geladen werden sollte?

    Vielen Dank für eure Antworten!

    Frank

    0
  • J

    CLR+CPLUS schrieb:

    Angenommen ich habe ein MFC Programm welches eine C++/CLR DLL in .NET 2.x als Plugin verwendet und später ein neues Plugin mit CLR Unterstützung hinzukommt, welches z.B. in 3.x entwickelt wurde, läuft nur die DLL die zuerst geladen wird?

    Naja... Es gibt bisher nur die Versionen 1.0, 1.1 und 2.0. Es gibt keine 3.0 oder 3.5! Aus diesem Grunde stellt sich die Frage hier so nicht.

    Machen wir das Beispiel eher mit "v1.1 wird geladen und dann möchte eine DLL v2". Das geht nicht.

    Dies ist wie gesagt der Grund, warum man Shell-Extensions (also Explorer-Extensions) *nur* in native-Code schreiben darf!

    CLR+CPLUS schrieb:

    Wenn zuerst die 3.x geladen wird, läuft dann noch die 2.x wegen der Abwärtskompatibilität?

    Naja, es gibt ein paar Dinge die nicht laufen; Es ist eben nicht 100% kompatibel. (v3 lädt v2.0sp1).

    CLR+CPLUS schrieb:

    Um dem Problem zu entgehen, könnte man ja in der Hauptanwendung ebenfalls die CLR einbinden um z.B. 2.x zu erwzingen, aber wie verhält sich dann die Anwendung, wenn ein 3.x Plugin geladen werden sollte?

    Wie gesagt, was Du machst ist falsch. Aber in ferner Zukunft soll es möglich sein mehrere CLRs in einem Prozess zu laden.

    0
  • ?

    Jochen Kalmbach schrieb:

    - erstelle Deine Anwendung als C++/CLI, dann kannst Du direkt die CLR Sachen verwenden.

    gibt es für den fall kleine Beispiele 😕

    0
  • Mod

    CLR schrieb:

    Jochen Kalmbach schrieb:

    - erstelle Deine Anwendung als C++/CLI, dann kannst Du direkt die CLR Sachen verwenden.

    gibt es für den fall kleine Beispiele 😕

    Verstehe ich nicht... Du kannst doch mit dem Wizard eine eigene C++/CLI Anwendung erzeugen. Dann hast Du ein Beispiel.

    Für was willst Du den genau ein Beispiel?

    0
  • J

    CLR schrieb:

    Jochen Kalmbach schrieb:

    - erstelle Deine Anwendung als C++/CLI, dann kannst Du direkt die CLR Sachen verwenden.

    gibt es für den fall kleine Beispiele 😕

    Dazu brauchst Du ein Beispiel. Du musst einfach in den projekteinstellungen unter "Common Language Runtime Support" den Schalter auf "/clr" einstellen. Dann kannst Du C#-Assemblies (DLLs) einbinden und verwenden. Da braucht man kein grosses Beispiel dafür... einfach machen. Fertig.

    0
  • ?

    Schon klar, nicht das habe ich aber gedacht. 🙄

    Ein Beispiel wie ich ein C++/CLI Projekt in ein MFC Projekt ohne \clr Unterstützung einbinde und am besten noch der umgekehrte weg

    0
  • Mod

    Und diese
    http://msdn2.microsoft.com/en-us/library/x0w2664k(VS.80).aspx
    http://msdn2.microsoft.com/en-us/library/ms235211(VS.80).aspxhttp://msdn2.microsoft.com/en-us/library/ed57y7kf(VS.80).aspx
    hast Du auch alle schon gelesen?

    Und besonders dieses?
    http://msdn2.microsoft.com/en-us/library/ms239720(VS.80).aspx

    0
Anmelden zum Antworten