CLR 2 Lib ohne Framework - wieso geht das?

[Ralph Erdt (2)]

Hallo.

Ich bin noch realtiv neu in der .Net Welt, und mir stellt sich gerade eine Frage, die ich nicht ergoogeln kann..

Ich habe hier eine Anwendung die mit .Net 4.5 kompiliert wird, aber eine 3th party DLLs verwendet, die die CLR 2 brauchen (mit ILSpy kontrolliert). Geladen wird diese mit "AppDomain.CurrentDomain.CreateInstanceFromAndUnwr ap(..)"
Auf meiner Test VM (frisches Windows 10, OHNE .Net 3.5) funktioniert die Anwendung.
Wieso? So wie ich das verstehe, braucht die DLL doch die CLR2, die eben nicht installiert ist?

Ich wäre dankbar, wenn mit das einer erläutern könnte.

Grüße
Ralph Erdt

[Bernhard Geyer]

.NET 2.0 ist in W10 immer dabei. Da gibts nichts zu installieren.

[Ralph Erdt (2)]

Danke für die Antwort.

Hmmm. Es gibt da einige Dinge, die da dem entgegen sprechen:

• Laut https://msdn.microsoft.com/en-us/lib...vs.110%29.aspx ist es nicht drin
• Laut Registry (o.g. VM) ist nur die CLR "v4" installiert.
• (Etwas schwaches Argument) Die Bezeichnung des Windows-Feature "Net 3.5": Da steht ".Net Framework 3.5 (enthalt .NET 2.0 und 3.0)".

Aber ich lass mich gerne vom Gegenteil überzeugen: Gibt es irgendwas, wo das beschrieben steht? Etwas, das ich auch den Kollegen / Chef vorlegen kann?

[Ralph Erdt (2)]

Nachtrag:

Eine mit CLR2 (2.0 bis 3.5) compilierte EXE triggert nur eine Windowsmeldung "Soll .Net 3.5 installiert werden?"

[Ralf Jansen]

Die 4er Runtime kann auch Assemblies laden und Ausführen die gegen das 2er Framework kompiliert wurden.

Anders rum ist schwieriger aber auch möglich. Du kannst per app.config erzwingen das eine gegen das 2er Framework gebaute Startup Assembly (eine Executable) trotzdem mit dem 4er Framework läuft und dann natürlich problemlos 4er Assmblies laden kann.
Schau dir dazu die app.config Parameter <supportedRuntime> und <useLegacyV2RuntimeActivationPolicy> an.

[Ralph Erdt (2)]

Danke für die Antwort. Gibt es da aber irgendein MSDN Artikel dazu, dass die CLR 4 mit CLR2 Compilaten umgehen kann? Mich interessiert vor allen das Handling mit den Libs: Microsoft ändert ja doch mal gerne die API, so dass die Abwärtskompatibilität nicht zwingend gegeben ist.

[gfoidl]

Hallo,

Side-by-Side Execution in the .NET Framework kannst du dir dazu durchlesen.

Microsoft ändert ja doch mal gerne die API

Bei .net ist die Kompatibilität sehr gut und es gibt es so gut wie keine breaking changes.

mfG Gü

[Ralph Erdt (2)]

Danke für die Antwort. Ich denke, ich habe jetzt genug Überblick.

Bei .net ist die Kompatibilität sehr gut und es gibt es so gut wie keine breaking changes.

so gut wie..

Da wir 3th party libs verwenden und nicht sicher sein können, was die machen, ist das das KO Kriterium.. Wir werden wohl weiter auf einer .Net 3.5 Installation bestehen.

[gfoidl]

Hallo,

das hat dann aber mit Mircosoft und .net an sich nichts zu tun, sondern mit dem 3th party-Hersteller.

mfG Gü

[Ralph Erdt (2)]

das hat dann aber mit Mircosoft und .net an sich nichts zu tun, sondern mit dem 3th party-Hersteller.

Sorry, aber da muss ich etwas widersprechen:
Es kann keiner etwas dazu, wenn Microsoft die API ändert. Und DASS es passiert, habe ich in der letzten Zeit häufig genug erlebt. Beispiel TFS Build: Eine Exception Klasse wurde in einen anderen Namespace verschoben.
Und auf ein so gut wie kann man eben nicht bauen. (Sorry, blöder Vergleich, aber den MUSS ich loswerden: "Hier gibt es so gut wie kein Hochwasser.")

Und während meiner Suche habe ich auch ein Dokument bzgl. breaking changes gefunden. Die berichteten Änderungen waren zu Klassen / Techniken / Vorgehensweisen die ich nicht als im Normalbetrieb benutztes bezeichnen würde; aber ich kann mir durchaus Gründe vorstellen, dass andere dieses gemacht haben. Ich kann also keinen einen Vorwurf machen, wenn aufgrund dessen das Programm in der CLR4 kracht. Die einzige Lösung ist das Installieren und nutzen von .Net 3.5.

[gfoidl]

Hallo,

hier vermischt du aber ein paar Dinge. .net an sich ist sehr kompatibel. TFS Build verwendet zwar .net und ist von Mircosoft, aber daraus folgern dass in die .net die API geändert wird ist nicht richtig.

Wenn du das Dokument über breaking changes gefunden hast, so solltest du auch die Quelle angeben.
Ich weiß dass es solche Dokumente gibt und das ist auch gut so, denn falls die API geändert wird, so kann man darauf reagieren da es eben bekannt gemacht wurde.

mfG Gü

[Ralph Erdt (2)]

Mal eben gegoogled:

Breaking Changes ("Application Compatibility"):

• CLR 1 -> CLR 22
• zwischen den 4er Versionen
• Weitere Übersicht mit Links zu 3.5 und 2.0

Mir ist klar, das TFS mit .Net (bis auf das es benutzt) nichts zu tun hat. Es ist nur das erste Beispiel, dass mir in den Sinn gekommen ist (weil ich mir da einen Wolf gesucht habe), dass Microsoft es mit der Kompatibilität nicht so genau nimmt.
Und .Net (an sich) mag sehr kompatibel sein, wenn aber die APIs geändert werden, bringt es nur nichts

[mwelling]

Also ich habe mir die genannten Beispiele zu den "Breaking Changes" mal oberflächlich angeschaut.
Was ich da erkennen konnte ist, dass zum großen Teil "fehlhafte" Funktionen (oder wenigstens "irritierendes Verhalten") in der nächsten Version "korrigiert" worden ist. Aber damit hat sich doch an der "ursprünglichen Schnittstelle" bzw. der alten CLR gar nichts geändert. Aus diesem Grund können die .Net-Versionen doch koexistent nebeneinander installiert sein und verwendet werden. Ich kann die Kritik nicht ganz nachvollziehen.

[Ralph Erdt (2)]

Es geht uns darum, ob wir .Net 3.5 installieren müssen / sollten, da die CLR 4 ja CLR 2 Code ausführen kann. Wir würden es gerne vermeiden, aber werden es wohl nicht können, da es breaking changes in den LIBs gegeben hat.

Und bei uns geht es um 3th party Komponenten. Daher können wir nicht mal eben nachsehen, ob da das drin ist, was "breaken" würde. Test sind zwar alle zufriedenstellend verlaufen - aber hier will keiner garantieren, dass es irgendwo, in irgendeiner Situation nicht ein bis dahin brachliegender Code-Pfad genommen wird, der eben genau die problematischen Funktionen aufrufen würde.

Und dass wir .Net 3.5 nun doch installieren werden hatte ich geschrieben..