Was tun bei Assembly-Inkompatibilität? (unterschiedliche Framework-Versionen)

Hallo allerseits,

ich habe ein Problem mit mehreren Assemblies, die jeweils mit anderen Framework-Versionen erstellt wurden.

Hintergrund ist, daß wir ein Plugin für eine Anwendung schreiben, die nur die Framework-Version 3.5 unterstützt. Unsere Programmlogik liegt aber in Assemblies mit der Framework-Version 4.0. Leider verwenden wir so viele 4.0-spezifischen Funktionen, daß ein "Downgrade" auf 3.5 sehr aufwändig wäre.

Ich habe deshalb daran gedacht, die beiden Programmteile (Plugin und die Datenverarbeitung) zu trennen und unabhängig voneinander laufen zu lassen, z.B. die Datenverarbeitung als Dienst, (Web-)Service oder eigenständiges Programm. Die Kommunikation zwischen beiden Programmteilen würde dann über eine eigene (XML- oder binäre) Schnittstelle ablaufen.

Zufrieden bin ich mit diesem Design allerdings nicht, vielleicht gibt es noch eine andere Alternative?

Schöne Grüße,
Christian

Hallo MrSparkle,

Hier ein kleiner Thread: .NET 3.5 runtime and .NET 4 runtime compatibility

Damit man dein Plugin nutzen kann, müsstest du wohl das Hauptprogramm unter .Net 4 starten.. zwar auch nicht die Ideallösung, aber .Net 4 würdest du ja sowieso benötigen.

Gruß
Roland

Hi Roland,

vielen Dank für den Hinweis. Das heißt ja im Prinzip nichts anderes als: Es geht nicht 😃
Wir können nämlich die Anwendung nicht verändern, die ist nicht von uns, sondern von AutoDesk.

Ich überlege daher, beide Programmteile (die mit Version 3.5 und die mit 4.0) in getrennten Prozessen laufen zu lassen und die Kommunikation zwischen beiden mit Hilfe von Named Pipes zu realisieren.

Vielleicht hat schonmal jemand so etwas ähnliches gemacht?

Schöne Grüße,
Christian

Hallo MrSparkle,

nur so eine Idee, aber mit .NET 4.0 hat der Windows Explorer gelernt, ShellExtensions zu verarbeiten, die mit unterschiedlichen Frameworkversionen erstellt wurden. Siehe [endlich möglich] Managed Shell Extensions mit .NET 4.0?!?. Vielleicht kann man das irgendwie nutzen, allerdings kann es sein, dass das nur für Assemblies ≥ 4.0 gilt, siehe [endlich möglich] Managed Shell Extensions mit .NET 4.0?!?.

herbivore

vielen Dank für den Hinweis. Das heißt ja im Prinzip nichts anderes als: Es geht nicht 😃 Wir können nämlich die Anwendung nicht verändern, die ist nicht von uns, sondern von AutoDesk.

Sagt der Hinweis nicht, dass du die Hostanwendung eben nicht ändern, sondern nur einen Eintrag in die app.config einfügen musst?

Hallo herbivore,
vielen Dank für den Hinweis. Das wäre die Lösung für die andere Richtung 😃

Hallo dN!3L,
Eine solche Config-Datei gibt es leider nicht, abgesehen davon wäre es auch nicht erlaubt, eine solche Datei von einem Plugin ändern zu lassen.

Mal noch ein paar allgemeine Erklärungen, wo das Problem eigentlich herkommt:

Das Programm, für das wir das Plugin schreiben, war bisher immer eine "unmanaged" Anwendung, also völlig unabhängig von .NET. Wir haben das Plugin in C++/CLI geschrieben und konnten damit dann auch Assemblies mit .NET 4.0 laden.

In der neuen Version ist das Programm aber selbst eine Mixed-Mode-Anwendung (C++/CLI), das die CLR 2.0 voraussetzt. D.h. unser Plugin benötigt auch CLR 2.0, und somit können wir nun unsere 4.0-Assemblies nicht mehr nutzen.

Und jetzt wissen wir erstmal nicht weiter und versuchen, eine alternative Lösung zu finden.