Laden...

erledigt: Speicherbedarf bei mehreren Framework-Versionen in derselben Solution

Erstellt von ErfinderDesRades vor 6 Jahren Letzter Beitrag vor 6 Jahren 1.961 Views
ErfinderDesRades Themenstarter:in
5.299 Beiträge seit 2008
vor 6 Jahren
erledigt: Speicherbedarf bei mehreren Framework-Versionen in derselben Solution

Wir produzieren Anwendungen, die Assemblies zusammenbinden, von denen manche mit FW4.0 kompilieren, andere mit FW4.5.
Die 4.5er - Anwendungen haben Verweise auf die 4.0er Assemblies, also das Konstrukt funktioniert, nur vermute ich einen überhöhten Speicher-Bedarf - wobei mir ein Kollege widerspricht.

Weiß jmd ein schlagendes Argument, oder eine INet-Resource, die das klärt?

thx

Der frühe Apfel fängt den Wurm.

709 Beiträge seit 2008
vor 6 Jahren

Hallo ErfinderDesRades,
ich kann dir zwar leider nicht weiterhelfen, wüsste aber gern, wie du zu deiner Vermutung gekommen bist.
Ist das einfach ein Bauchgefühl?

Gruß
Micha

D
985 Beiträge seit 2014
vor 6 Jahren

So wie ich das verstanden habe ist das ganze 4.x ein Geraffel.

.NET Framework 4.7 beinhaltet alles von 4.0 bis 4.7
.NET Framework 3.5 beinhaltet alles von 2.0 bis 3.5

Zusammengereimt von .NET Framework 4.7 (Offlineinstaller)

Microsoft .NET Framework 4.7 ist eine hochkompatible Direktaktualisierung von Microsoft .NET Framework 4, 4.5, 4.5.1, 4.5.2, 4.6, 4.6.1 und 4.6.2.

...

This version of the .NET Framework runs side-by-side with the .NET Framework 3.5 SP1 and earlier versions, but performs an in-place update for the .NET Framework 4, .NET Framework 4.5, .NET Framework 4.5.1, .NET Framework 4.5.2, .NET Framework 4.6, .NET Framework 4.6.1 and .NET Framework 4.6.2.

W
872 Beiträge seit 2005
vor 6 Jahren

Version Compatibility
"An app can control the version of the .NET Framework on which it runs, but a component cannot. Components and class libraries are loaded in the context of a particular app, and therefore automatically run on the version of the .NET Framework that the app runs on." - ergo solltest Du keinen Mehrverbrauch an Speicher haben.

ErfinderDesRades Themenstarter:in
5.299 Beiträge seit 2008
vor 6 Jahren

Wie gesagt, dass und wie die FWs miteinander kompatibel sind ist nicht die Frage.
Mein Bauchgefühl sagte mir halt, wenn ich eine Assembly in FW4.0 code, dann lädt sie auch zB die WinForms.dll-4.0, und wenn im selben Programm eine annere Assembly mit FW4.5 kompiliert, so lädt letztere die WinForms.dll-4.5, und somit wären 2 Winformse geladen.

Aber nu seh ich, dass sowohl inne FW4- als auch inne FW4.5 - Assembly die eingebundene WinFormsdll die Versionsnummer 4.0 hat.

Also wird bei verschiedenen FWs nur verschiedene msCorlibs geladen, die System.Windows.Forms, System.Data etc. aber für beide dieselbe benützt?

Der frühe Apfel fängt den Wurm.

W
872 Beiträge seit 2005
vor 6 Jahren

Ist Deine .exe 4.5, dann läuft alles unter der 4.5 Runtime.
Ist Deine .exe 4.0, dann läuft alles unter der 4.0 Runtime.
Die Versionsnummer bei den Assemblies dient zum Schutz, daß ein 4.5 Assembly nicht unter einer 4.0 Runtime unterstützt wird. Die Assemblies sind schliesslich auch MSIL/Intermediary Code, der JIT (Just In Time) kompiliert wird.

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo ErfinderDesRades,

während der Ausführung ist alles unter der höchsten 4.x Version die installiert wurde.

Während des Build-Vorgangs werden andere Reference-Assemblies (je nach FW-Version) verwendet, damit z.B. ein Projekt mit .net 4.0 nicht auf Member zugreifen kann, die in späteren Versionen erschienen sind.

Anders würde es sich verhalten, wenn .net 2.0 / 3.5 mit dem 4.x FW verwendet werden, da dort unterschiedliche CLR-Versionen vorhanden sind (side by side execution).

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

ErfinderDesRades Themenstarter:in
5.299 Beiträge seit 2008
vor 6 Jahren

vielen Dank an alle! 👍

Der frühe Apfel fängt den Wurm.