Laden...

Rückstufung von .Net Standard 2.0 auf 1.3 weil FW 4.6.1 auf einer Maschine nicht verfügbar ist

Erstellt von oehrle vor 3 Jahren Letzter Beitrag vor 3 Jahren 657 Views
O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 3 Jahren
Rückstufung von .Net Standard 2.0 auf 1.3 weil FW 4.6.1 auf einer Maschine nicht verfügbar ist

Hallo, hatte mich bei der Weiterentwicklung an einem Projekt an die Zukunftssicherheit gewagt, und ein weiterer Teil des Projektes als .Net Standard entwickelt. Es war soweit kein Problem, da mir alle bekannt gewesenen Rechner schon FW 4.6.1 oder höher hatten. Somit hatte ich mein Hauptprojekt auf FW 4.6.1 angehoben, damit ich .Net Standard 2.0 verwenden kann.
Heute morgen die Ernüchterung: Es gibt einen PC, der hat erst FW 4.5.1, diesen darf ich auch nicht aktualisieren, da sonst irgendwelche Programme nicht mehr korrekt arbeiten.

Nun dachte ich, ich setze mein Hauptprojekt auch auf FW 4.5.1 zurück, verwende da dann das passende .Net Standard 1.2 dazu.

Zu meinem Kraus muss ich dann festestellen, das da dann die Klasse "FileInfo" oder "ConfigurationManager" fehlen. Was habe ich da für Alternativen?
Über FileInfo erstelle ich Dateien, werte Infos der Attribute aus (Datum ...), mit dern anderen Klasse habe ich Funktionalität erstellt, um die Konfigurationsdatei auszuwerten.

Giibt es da nur den weg zurück diese zusätzliche Projekterweiterung in einem normalen Framework zu erstellen (FW4.0 ...) ?

D
161 Beiträge seit 2017
vor 3 Jahren

Der ConfigurationManager wird erst ab FW Version 4.6.1 Supported, soweit ich das richtig sehe.

Siehe auch das NuGet Package, was man laden könnte.

Zum anderen, weiß ich gerade nicht.

4.931 Beiträge seit 2008
vor 3 Jahren

Heute morgen die Ernüchterung: Es gibt einen PC, der hat erst FW 4.5.1, diesen darf ich auch nicht aktualisieren, da sonst irgendwelche Programme nicht mehr korrekt arbeiten.

Die Installation von .NET 4.6 (und höher) überschreibt nicht die bestehende .NET 4.5 Version, sondern diese wird side-by-side zusätzlich dazu installiert (und sollte daher auf .NET 4.5 bestehende Programme nicht beeinflussen). Schau dir dazu einfach (in der alten "Systemsteuerung") unter "Programme und Features" die installierten .NET Versionen an.

Edit: Falschinformation von mir, s.u.

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 3 Jahren

Hallo Th69, side by side heißt dann, es wird gar nichts überschrieben, die Applikationen holen sich nach wie vor was sie brauchen?
Somit kann kein Problem mit installierten Applikationen entstehen?

Alles was 4.6.1 benötigt, verwendet diese zusätzlichen FW-Tools / Klassen?

16.807 Beiträge seit 2008
vor 3 Jahren

Siehe Side-by-Side Execution in the .NET Framework und Version compatibility und .NET Framework versions and dependencies

Die Installation von .NET 4.6 (und höher) überschreibt nicht die bestehende .NET 4.5 Version, sondern diese wird side-by-side zusätzlich dazu installiert

The Microsoft .NET Framework 4.6.1 is a highly compatible, in-place update to the Microsoft .NET Framework 4, Microsoft .NET Framework 4.5, Microsoft .NET Framework 4.5.1, Microsoft .NET Framework 4.5.2 and Microsoft .NET Framework 4.6.

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 3 Jahren

Danke für die Info. Der SQ-Hersteller soll nun erst mal prüfen, ob 4.6.1 installiert werden kann (sollte ja eigentlich dann so sein wenn das side by side ist. Habe noch an zwei anderen Maschinen nachgesehen, dort ist 4.7.1 und 4.6.1 installiert wobei ein System W7 und das andere W10 ist.
Danke nochmals.

4.931 Beiträge seit 2008
vor 3 Jahren

Sorry für meinen falschen Beitrag, Abt hat Recht.
Die unter "Programme und Features" aufgelisteten .NET Versionen sind die Multitarget Packs und SDKs (welche u.a. für Visual Studio benötigt werden), aber nicht die Runtime Versionen. Alle 4.x .NET-Versionen verwenden die gleiche Runtime-Version v4.0.30319.

Trotzdem sollte es bei einer nachträglichen Installation von 4.6 nur Probleme geben, wenn ein Programm Features verwendet, welche als "Breaking Changes" gelten, s.a. Anwendungskompatibilität in .NET Framework. In deinem Fall also Runtime-Änderungen für die Migration von .NET Framework 4.5.1 zu 4.6.1 (wobei einige der Fehler dann wiederum in höheren Versionen, also 4.6.2 oder 4.7, beseitigt wurden).