MFC und CLR
-
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 :
-
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.
-
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/
-
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.
-
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
-
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
-
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
-
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.
-
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
-
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?
-
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.
-
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
-
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
-
Könnte man die Forensoftware nicht einmal so anpassen, dass Links mit runden Klammern vollständig angezeigt werden?
-
sri schrieb:
Könnte man die Forensoftware nicht einmal so anpassen, dass Links mit runden Klammern vollständig angezeigt werden?
OT: 100% ACK! Manchmal editiere ich die Links, weil dieser Wert in Klammern nicht nötig ist, aber oft genug bin ich zu faul.
-
Martin Richter schrieb:
Und besonders dieses?
http://msdn2.microsoft.com/en-us/library/ms239720(VS.80).aspxleider läßt sich das Beispiel nicht erstellen
Ausgabe
1>------ Erstellen übersprungen: Projekt: WinFormUserControl1 ------ 1> 2>------ Erstellen übersprungen: Projekt: WinFormUserControlView1 ------ 2> 3>------ Erstellen übersprungen: Projekt: EXTDLL2 ------ 3> 4>------ Erstellen übersprungen: Projekt: EXTDLL1 ------ 4> 5>------ Erstellen übersprungen: Projekt: EXTDLL3 ------ 5> 6>------ Erstellen übersprungen: Projekt: MFC04 ------ 6> ========== Build: 0 erfolgreich oder aktuell, Fehler bei 0, 6 übersprungen ==========
-
Gibt es im netz noch Beispiele die sich auch erstellen lassen??
-
CLR schrieb:
leider läßt sich das Beispiel nicht erstellen
ist zwar schon länger her aber:
doch das geht! schau mal im menü erstellen->konfigurationsmanager
bei mir war "Itanium" voreingestellt. Stell mal um auf "Win32".
-
Du musst in die Konfigurations-Einstellungen und die Projekt auswählen, welche gebuilded werden sollen!
-
es waren alle projekte ausgewählt. erst mit dem umstellen von "Itanium" auf "Win32" fing VS an die projekte zu berücksichtigen...
mir ist nur etwas schleierhaft, wieso die programmierer eine Itanium projektmappenplattform nutzten, oder sie zumindest so benannt haben. Itanium war doch eine prozessorreihe von Intel und HP alternativ zu den x86 CPUs.
