Breaking Changes in .NET-Bibliotheken für .NET Core 1.0 bis 3.0

  • Artikel

Die .NET-Kernbibliotheken stellen die von .NET Core verwendeten primitiven Typen sowie andere allgemeine Typen bereit.

Auf dieser Seite sind die folgenden Breaking Changes dokumentiert:

Unterbrechende Änderung Eingeführt in Version
Das Übergeben von GroupCollection an Erweiterungsmethoden, die IEnumerable<T> akzeptieren, erfordert Vermeidung von Mehrdeutigkeit .NET Core 3.0
APIs, die Versionsinformationen melden, melden nun die Produktversion und nicht die Dateiversion .NET Core 3.0
Benutzerdefinierte EncoderFallbackBuffer-Instanzen können kein rekursives Fallback ausführen .NET Core 3.0
Neues Verhalten bei Formatierung und Analyse von Gleitkommawerten .NET Core 3.0
Gleitkommaanalysevorgänge lösen keinen Fehler und keine OverflowException mehr aus .NET Core 3.0
InvalidAsynchronousStateException wurde in andere Assembly verschoben .NET Core 3.0
Ersetzen von falsch formatierten UTF-8-Bytesequenzen richtet sich nach Unicode-Vorgaben .NET Core 3.0
TypeDescriptionProviderAttribute wurde in andere Assembly verschoben .NET Core 3.0
ZipArchiveEntry verarbeitet keine Archive mit inkonsistenten Eintragsgrößen mehr .NET Core 3.0
FieldInfo.SetValue löst eine Ausnahme für statische reine Initialisierungsfelder aus .NET Core 3.0
Pfad-APIs lösen keine Ausnahme für ungültige Zeichen aus .NET Core 2.1
Private Felder, die integrierten Strukturtypen hinzugefügt werden .NET Core 2.1
Änderung des Standardwerts von UseShellExecute .NET Core 2.1
OpenSSL-Versionen unter macOS .NET Core 2.1
UnauthorizedAccessException, ausgelöst von FileSystemInfo.Attributes .NET Core 1.0
Verarbeiten von Corrupted Process-State Exceptions wird nicht unterstützt .NET Core 1.0
UriBuilder-Eigenschaften werden führenden Zeichen nicht mehr vorangestellt .NET Core 1.0
Process.StartInfo löst InvalidOperationException für Prozesse aus, die Sie nicht gestartet haben .NET Core 1.0

.NET Core 3.0

Das Übergeben von GroupCollection an Erweiterungsmethoden, die IEnumerable<T> akzeptieren, erfordert Vermeidung von Mehrdeutigkeit

Wenn Sie eine Erweiterungsmethode aufrufen, die IEnumerable<T> für GroupCollection akzeptiert, müssen Sie den Typ mithilfe einer Umwandlung verdeutlichen.

Änderungsbeschreibung

Ab .NET Core 3.0 implementiert System.Text.RegularExpressions.GroupCollection neben anderen Typen wie IEnumerable<Group> auch IEnumerable<KeyValuePair<String,Group>>. Dies resultiert in einer Mehrdeutigkeit, wenn eine Erweiterungsmethode aufgerufen wird, die IEnumerable<T> akzeptiert. Wenn Sie eine solche Erweiterungsmethode für eine GroupCollection-Instanz aufrufen, z. B. Enumerable.Count, wird der folgende Compilerfehler angezeigt:

CS1061: „GroupCollection“ enthält keine Definition für „Count“, und es konnte keine Erweiterungsmethode „Count“ gefunden werden, die ein erstes Argument vom Typ „GroupCollection“ akzeptiert (möglicherweise fehlt eine using-Anweisung oder ein Assemblyverweis).

In vorherigen Versionen von .NET gab es keine Mehrdeutigkeit und keinen Compilerfehler.

Eingeführt in Version

3.0

Grund für die Änderung

Hierbei handelt es sich um einen unbeabsichtigten Breaking Change. Da diese Funktionsweise seit einiger Zeit besteht, ist keine Änderung geplant. Außerdem würde eine solche Änderung selbst zu einem Breaking Change führen.

Heben Sie für GroupCollection-Instanzen die Mehrdeutigkeit von Aufrufen der Erweiterungsmethoden auf, die IEnumerable<T> mit einer Umwandlung akzeptieren.

// Without a cast - causes CS1061.
match.Groups.Count(_ => true)

// With a disambiguating cast.
((IEnumerable<Group>)m.Groups).Count(_ => true);

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

Dies betrifft alle Erweiterungsmethoden, die IEnumerable<T> akzeptieren. Beispiel:

APIs, die Versionsinformationen melden, melden nun die Produktversion und nicht die Dateiversion

Viele APIs, die in .NET Core Versionsinformationen zurückgeben, geben nun anstelle der Dateiversion die Produktversion zurück.

Änderungsbeschreibung

In .NET Core 2.2 und früheren Versionen, wird in Methoden wie Environment.Version, RuntimeInformation.FrameworkDescription und im Dialogfeld mit den Dateieigenschaften für .NET Core-Assemblys die Dateiversion angegeben. Ab .NET Core 3.0 wird die Produktversion angegeben.

In der folgenden Abbildung sind die unterschiedlichen Versionsinformationen für die System.Runtime.dll-Assembly für .NET Core 2.2 (links) und .NET Core 3.0 (rechts) zu sehen, die im Dialogfeld mit Dateieigenschaften im Windows-Explorer angezeigt werden.

Difference in product version information

Eingeführt in Version

3.0

Keine Durch diese Änderung soll die Version einfacher und intuitiver zu erkennen sein.

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

Benutzerdefinierte EncoderFallbackBuffer-Instanzen können kein rekursives Fallback ausführen

Benutzerdefinierte EncoderFallbackBuffer-Instanzen können kein rekursives Fallback ausführen. Die Implementierung von EncoderFallbackBuffer.GetNextChar() muss zu einer Zeichensequenz führen, die in die Zielcodierung konvertiert werden kann. Andernfalls tritt eine Ausnahme auf.

Änderungsbeschreibung

Bei einem Zeichen-zu-Byte-Transcodierungsvorgang erkennt die Runtime falsch formatierte oder nicht konvertierbare UTF-16-Sequenzen und stellt diese Zeichen für die EncoderFallbackBuffer.Fallback-Methode bereit. Die Fallback-Methode bestimmt, welche Zeichen die ursprünglichen nicht konvertierbaren Daten ersetzen, und diese Zeichen werden durch Aufrufen von EncoderFallbackBuffer.GetNextChar in einer Schleife ausgeglichen.

Die Runtime versucht dann, diese Ersetzungszeichen in die Zielcodierung zu transcodieren. Wenn dieser Vorgang erfolgreich ist, setzt die Runtime die Transcodierung an der Stelle fort, an der sie die ursprüngliche Eingabezeichenfolge verlassen hat.

In früheren Versionen können von benutzerdefinierten Implementierungen von EncoderFallbackBuffer.GetNextChar() Zeichensequenzen zurückgegeben werden, die nicht in die Zielcodierung konvertiert werden können. Wenn die ersetzten Zeichen nicht in die Zielcodierung transcodiert werden können, ruft die Runtime die EncoderFallbackBuffer.Fallback-Methode erneut mit den Ersetzungszeichen auf, wobei erwartet wird, dass die EncoderFallbackBuffer.GetNextChar()-Methode eine neue Ersetzungssequenz zurückgibt. Dieser Vorgang wird fortgesetzt, bis die Laufzeit eine wohlgeformte, konvertierbare Ersetzung erkennt oder eine maximale Anzahl von Rekursionen erreicht wird.

Ab .NET Core 3.0 müssen von benutzerdefinierten Implementierungen von EncoderFallbackBuffer.GetNextChar() Zeichensequenzen zurückgegeben werden, die in die Zielcodierung konvertiert werden können. Wenn die ersetzten Zeichen nicht in die Zielcodierung transcodiert werden können, wird eine ArgumentException ausgelöst. Die Laufzeit führt keine rekursiven Aufrufe der EncoderFallbackBuffer-Instanz mehr durch.

Dieses Verhalten gilt nur, wenn alle drei der folgenden Bedingungen erfüllt sind:

  • Die Runtime erkennt eine falsch formatierte UTF-16-Sequenz oder eine UTF-16-Sequenz, die nicht in die Zielcodierung konvertiert werden kann.
  • Ein benutzerdefinierter EncoderFallback wurde angegeben.
  • Der benutzerdefinierte EncoderFallback versucht, eine neue falsch formatierte oder nicht konvertierbare UTF-16-Sequenz zu ersetzen.

Eingeführt in Version

3.0

Die meisten Entwickler müssen keine Maßnahmen ergreifen.

Wenn eine Anwendung eine benutzerdefinierte EncoderFallback- und EncoderFallbackBuffer-Klasse verwendet, stellen Sie sicher, dass die Implementierung von EncoderFallbackBuffer.Fallback den Fallbackpuffer mit wohlgeformten UTF-16-Daten auffüllt, die direkt in die Zielcodierung konvertiert werden können, wenn die Fallback-Methode zuerst von der Runtime aufgerufen wird.

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

Neues Verhalten bei Formatierung und Analyse von Gleitkommawerten

Das Verhalten bei der Analyse und Formatierung von Gleitkommawerten (durch die Typen Double und Single) ist jetzt IEEE-konform. Dadurch wird sichergestellt, dass das Verhalten von Gleitkommatypen in .NET dem Verhalten von anderen IEEE-konformen Sprachen entspricht. Beispielsweise muss double.Parse("SomeLiteral") immer mit der Ausgabe von C# für double x = SomeLiteral übereinstimmen.

Änderungsbeschreibung

In .NET Core 2.2 und früheren Versionen war die Formatierung mit Double.ToString und Single.ToString und die Analyse mit Double.Parse, Double.TryParse, Single.Parse und Single.TryParse nicht IEEE-konform. Daher kann nicht sichergestellt werden, dass ein Wert mit einer unterstützten Zeichenfolge in einem Standardformat oder in einem benutzerdefinierten Format einen Roundtrip durchführt. Bei einigen Eingaben kann bei der Analyse eines formatierten Werts ein Fehler auftreten. Bei anderen Eingaben kann es vorkommen, dass der analysierte Wert nicht dem ursprünglichen Wert entspricht.

Ab .NET Core 3.0 entsprechen Analyse- und Formatierungsvorgänge für Gleitkommawerte der Norm IEEE 754.

Die folgende Tabelle zeigt zwei Codeausschnitte und die Unterschiede in der Ausgabe zwischen .NET Core 2.2 und .NET Core 3.1.

Codeausschnitt Ausgabe in .NET Core 2.2 Ausgabe in .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 -0
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

Weitere Informationen finden Sie im Blogbeitrag Verbesserungen bei Analyse und Formatierung von Gleitkommawerten in .NET Core 3.0.

Eingeführt in Version

3.0

Im Abschnitt Potenzielle Auswirkungen auf vorhandenen Code im Blogbeitrag Verbesserungen der Analyse und Formatierung von Gleitkommawerten in .NET Core 3.0 werden einige Änderungen vorgeschlagen, die Sie an Ihrem Code vornehmen können, wenn Sie das vorherige Verhalten beibehalten möchten.

  • Bei einigen Formatierungsunterschieden können Sie ein Verhalten erzielen, das dem vorherigen Verhalten entspricht, indem Sie eine andere Formatzeichenfolge angeben.
  • Für Unterschiede bei der Analyse gibt es keinen Mechanismus zum Wiederherstellen des vorherigen Verhaltens.

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

Gleitkomma-Analysevorgänge lösen keinen Fehler und keine OverflowException mehr aus

Die Gleitkomma-Analysemethoden lösen keine OverflowException mehr aus und geben auch nicht false zurück, wenn sie eine Zeichenfolge analysieren, deren Zahlenwert außerhalb des Bereichs des Gleitkommatyps Single oder Double liegt.

Änderungsbeschreibung

In .NET Core 2.2 und früheren Versionen lösen die Methoden Double.Parse und Single.Parse eine OverflowException für Werte aus, die außerhalb des Bereichs ihres jeweiligen Typs liegen. Die Methoden Double.TryParse und Single.TryParse geben false für die Zeichenfolgendarstellungen von numerischen Werten außerhalb des gültigen Bereichs zurück.

Ab .NET Core 3.0 schlagen die Methoden Double.Parse, Double.TryParse, Single.Parse und Single.TryParse nicht mehr fehl, wenn Sie außerhalb des gültigen Bereichs liegende numerische Zeichenfolgen analysieren. Stattdessen geben die Double-Analysemethoden Double.PositiveInfinity für Werte, die Double.MaxValue überschreiten, und Double.NegativeInfinity für Werte zurück, die kleiner als Double.MinValue sind. Analog dazu geben die Single-Analysemethoden Single.PositiveInfinity für Werte, die Single.MaxValue überschreiten, und Single.NegativeInfinity für Werte zurück, die kleiner als Single.MinValue sind.

Diese Änderung wurde vorgenommen, um die Konformität mit IEEE 754:2008 zu verbessern.

Eingeführt in Version

3.0

Diese Änderung kann sich auf zwei Arten auf den Code auswirken:

  • Der Code hängt vom Handler für die OverflowException ab, der ausgeführt wird, wenn ein Überlauf auftritt. In diesem Fall sollten Sie die catch-Anweisung entfernen und erforderlichen Code in einer If-Anweisung platzieren, die testet, ob Double.IsInfinity oder Single.IsInfinitytrue ist.

  • Ihr Code geht davon aus, dass Gleitkommawerte nicht Infinity sind. In diesem Fall sollten Sie den erforderlichen Code hinzufügen, um auf Gleitkommawerte des Typs PositiveInfinity und NegativeInfinity zu prüfen.

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

InvalidAsynchronousStateException in andere Assembly verschoben

Die InvalidAsynchronousStateException-Klasse wurde verschoben.

Änderungsbeschreibung

In .NET Core 2.2 und früheren Versionen befand sich die InvalidAsynchronousStateException-Klasse in der System.ComponentModel.TypeConverter-Assembly.

Seit .NET Core 3.0 befindet sie sich in der System.ComponentModel.Primitives-Assembly.

Eingeführt in Version

3.0

Diese Änderung betrifft nur Anwendungen, welche die Reflektion zum Laden von InvalidAsynchronousStateException durch Aufrufen einer Methode wie Assembly.GetType oder eine Überladung von Activator.CreateInstance nutzen, bei der vorausgesetzt wird, dass sich der Typ in einer bestimmten Assembly befindet. Ist dies der Fall, aktualisieren Sie die im Methodenaufruf referenzierte Assembly entsprechend dem neuen Assemblyspeicherort des Typs.

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

Keine.

Ersetzen von falsch formatierten UTF-8-Bytesequenzen von Unicode-Vorgaben abhängig

Wenn die Klasse UTF8Encoding während einer Byte-zu-Zeichen-Transcodierung auf eine falsch formatierte UTF-8-Bytesequenz trifft, ersetzt sie diese in der Ausgabezeichenfolge durch ein „�“-Zeichen (U+FFFD, ERSETZUNGSZEICHEN). .NET Core 3.0 unterscheidet sich von früheren Versionen von .NET Core und .NET Framework durch die Einhaltung der bewährten Unicode-Methoden für die Durchführung dieser Ersetzung während des Transcodierungsvorgangs.

Dies ist Teil einer größeren Maßnahme zur Verbesserung der UTF-8-Verarbeitung in .NET, auch bei den neuen Typen System.Text.Unicode.Utf8 und System.Text.Rune. Der Typ UTF8Encoding wurde mit einem verbesserten Verfahren für die Fehlerbehandlung versehen, sodass die Ausgabe konsistent mit den neu eingeführten Typen generiert wird.

Änderungsbeschreibung

Ab .NET Core 3.0 führt die UTF8Encoding-Klasse bei der Transcodierung von Bytes in Zeichen Zeichenersetzung basierend auf bewährten Unicode-Methoden aus. Der verwendete Ersetzungsmechanismus wird durch The Unicode Standard, Version 12.0, Abschnitt 3.9 (PDF) unter der Überschrift U+FFFD Substitution of Maximum Subparts beschrieben.

Dieses Verhalten gilt nur, wenn die Eingabebytesequenz falsch formatierte UTF-8-Daten enthält. Außerdem gilt: Wenn die UTF8Encoding-Instanz mit throwOnInvalidBytes: true erstellt wurde, löst die UTF8Encoding-Instanz bei ungültiger Eingabe weiterhin eine Ausnahme aus, anstatt eine Ersetzung mit U+FFFD auszuführen. Weitere Informationen über den Konstruktor UTF8Encoding finden Sie unter UTF8Encoding(Boolean, Boolean).

In der folgenden Tabelle wird die Auswirkung dieser Änderung mit einer ungültigen 3-Byte-Eingabe veranschaulicht:

Falsch formatierte 3-Byte-Eingabe Ausgabe vor .NET Core 3.0 Ausgabe ab .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (2-Zeichen-Ausgabe) [ FFFD FFFD FFFD ] (3-Zeichen-Ausgabe)

Die 3-Zeichen-Ausgabe ist die bevorzugte Ausgabe gemäß Tabelle 3–9 der oben genannten PDF-Datei zum Unicode-Standard.

Eingeführt in Version

3.0

Auf der Seite des Entwicklers ist keine Aktion erforderlich.

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

TypeDescriptionProviderAttribute in andere Assembly verschoben

Die TypeDescriptionProviderAttribute-Klasse wurde verschoben.

Änderungsbeschreibung

In .NET Core 2.2 und früheren Versionen befand sich die TypeDescriptionProviderAttribute-Klasse in der System.ComponentModel.TypeConverter-Assembly.

Seit .NET Core 3.0 befindet sie sich in der System.ObjectModel-Assembly.

Eingeführt in Version

3.0

Diese Änderung betrifft nur Anwendungen, welche die Reflektion zum Laden des TypeDescriptionProviderAttribute-Typs durch Aufrufen einer Methode wie Assembly.GetType oder eine Überladung von Activator.CreateInstance nutzen, bei der vorausgesetzt wird, dass sich der Typ in einer bestimmten Assembly befindet. Ist dies der Fall, muss die im Methodenaufruf referenzierte Assembly entsprechend dem neuen Assemblyspeicherort des Typs aktualisiert werden.

Kategorie

Windows Forms

Betroffene APIs

Keine.

ZipArchiveEntry verarbeitet keine Archive mit inkonsistenten Eintragsgrößen mehr

ZIP-Archive listen sowohl die komprimierte als auch die unkomprimierte Größe im zentralen Verzeichnis und im lokalen Header auf. Die Eintragsdaten selbst geben die Größe ebenfalls an. In .NET Core 2.2 und früheren Versionen wurden diese Werte nie auf Konsistenz geprüft. Ab .NET Core 3.0 ist dies jetzt der Fall.

Änderungsbeschreibung

In .NET Core 2.2 und früheren Versionen ist ZipArchiveEntry.Open() selbst dann erfolgreich, wenn der lokale Header nicht mit dem zentralen Header der ZIP-Datei übereinstimmt. Die Daten werden dekomprimiert, bis das Ende des komprimierten Datenstroms erreicht ist, auch wenn seine Länge die im zentralen Verzeichnis/lokalen Header angegebene unkomprimierte Dateigröße überschreitet.

Ab .NET Core 3.0 überprüft die ZipArchiveEntry.Open()-Methode, ob der lokale Header und der zentrale Header hinsichtlich der komprimierten und unkomprimierten Größen eines Eintrags übereinstimmen. Wenn dies nicht der Fall ist, löst die Methode eine InvalidDataException aus, wenn die lokalen Größen der Header- und/oder Datendeskriptorlisten des Archivs nicht mit dem zentralen Verzeichnis der ZIP-Datei übereinstimmen. Beim Lesen eines Eintrags werden dekomprimierte Daten auf die nicht komprimierte Dateigröße abgeschnitten, die im Header aufgeführt ist.

Diese Änderung wurde vorgenommen, um sicherzustellen, dass ein ZipArchiveEntry die Größe seiner Daten richtig darstellt und nur diese Menge an Daten gelesen wird.

Eingeführt in Version

3.0

Packen Sie jedes ZIP-Archiv neu, das diese Probleme aufweist.

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

FieldInfo.SetValue löst eine Ausnahme für statische reine Initialisierungsfelder aus

Ab .NET Core 3.0 wird eine Ausnahme ausgelöst, wenn Sie versuchen, einen Wert in einem statischen InitOnly-Feld durch Aufrufen von System.Reflection.FieldInfo.SetValue festzulegen.

Änderungsbeschreibung

In .NET Framework und Versionen von .NET Core vor 3.0 konnten Sie den Wert eines statischen Felds, das nach der Initialisierung konstant ist (schreibgeschützt in C#), durch Aufrufen von System.Reflection.FieldInfo.SetValue festlegen. Allerdings führte das Festlegen eines solchen Felds auf diese Weise je nach Zielframework und Optimierungseinstellungen zu einem unvorhersehbaren Verhalten.

Ab . NET Core 3.0 wird beim Aufrufen von SetValue für ein statisches InitOnly-Feld eine System.FieldAccessException-Ausnahme ausgelöst.

Tipp

Ein InitOnly-Feld ist ein Feld, das nur zum Zeitpunkt seiner Deklaration oder im Konstruktor für die enthaltende Klasse festgelegt werden kann. Das heißt, dass es nach der Initialisierung konstant ist.

Eingeführt in Version

3.0

Initialisieren Sie statische InitOnly-Felder in einem statischen Konstruktor. Dies gilt sowohl für dynamische als auch für nicht dynamische Typen.

Alternativ können Sie das FieldAttributes.InitOnly-Attribut aus dem Feld entfernen und dann FieldInfo.SetValueaufrufen.

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

.NET Core 2.1

Pfad-APIs lösen keine Ausnahme für ungültige Zeichen aus

APIs, die Dateipfade enthalten, überprüfen Pfadzeichen nicht mehr und lösen auch keine ArgumentException mehr aus, wenn ein ungültiges Zeichen gefunden wird.

Beschreibung der Änderung

In .NET Framework und .NET Core 1.0 bis 2.0 lösen die im Abschnitt Betroffene APIs aufgeführten Methoden eine ArgumentException-Instanz aus, wenn das Pfadargument ein ungültiges Pfadzeichen enthält. Ab .NET Core 2.1 überprüfen diese Methoden nicht mehr auf ungültige Pfadzeichen und sie lösen keine Ausnahme mehr aus, wenn ein ungültiges Zeichen gefunden wird.

Grund für die Änderung

Die aggressive Validierung von Pfadzeichen blockiert einige plattformübergreifende Szenarios. Diese Änderung wurde eingeführt, damit .NET nicht versucht, das Ergebnis von Betriebssystem-API-Aufrufen zu replizieren oder vorherzusagen. Weitere Informationen finden Sie im Blogbeitrag Vorschau für System.IO in .NET Core 2.1.

Eingeführt in Version

.NET Core 2.1

Wenn Ihr Code sich auf diese APIs verlassen hat, um nach ungültigen Zeichen zu suchen, können Sie einen Aufruf von Path.GetInvalidPathChars hinzufügen.

Betroffene APIs

Siehe auch

Private Felder, die integrierten Strukturtypen hinzugefügt werden

Private Felder wurden zu bestimmten Strukturtypen in Referenzassemblys hinzugefügt. Folglich müssen diese Strukturtypen in C# immer unter Verwendung des neuen Operators oder Standardliterals instanziiert werden.

Änderungsbeschreibung

In .NET Core 2.0 und früheren Versionen konnten einige bereitgestellte Strukturtypen (z. B. ConsoleKeyInfo) instanziiert werden, ohne den new-Operator oder das Standardliteral in C# zu verwenden. Dies war darauf zurückzuführen, dass die vom C#-Compiler verwendeten Verweisassemblys nicht die privaten Felder für die Strukturen enthielten. Alle privaten Felder für .NET-Strukturtypen werden den Verweisassemblys ab .NET Core 2.1 hinzugefügt.

Der folgende C# Code wird z. B. in .NET Core 2.0 kompiliert, nicht jedoch in .NET Core 2.1:

ConsoleKeyInfo key;    // Struct type

if (key.ToString() == "y")
{
    Console.WriteLine("Yes!");
}

In .NET Core 2.1 führt der Code oben zu folgendem Compilerfehler: CS0165: Verwendung der nicht zugewiesenen lokalen Variablen „key“

Eingeführt in Version

2.1

Instanziieren Sie Strukturtypen mit dem new-Operator oder Standardliteral.

Zum Beispiel:

ConsoleKeyInfo key = new ConsoleKeyInfo();    // Struct type.

if (key.ToString() == "y")
    Console.WriteLine("Yes!");

ConsoleKeyInfo key = default;    // Struct type.

if (key.ToString() == "y")
    Console.WriteLine("Yes!");

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

Änderung des Standardwerts von UseShellExecute

ProcessStartInfo.UseShellExecute besitzt den Standardwert false für .NET Core. Für .NET Framework lautet der Standardwert true.

Änderungsbeschreibung

Process.Start ermöglicht es Ihnen, eine Anwendung direkt zu starten, z. B. mit Code wie Process.Start("mspaint.exe"), der Paint startet. Außerdem können Sie eine zugehörige Anwendung indirekt starten, wenn ProcessStartInfo.UseShellExecute auf true festgelegt ist. Für .NET Framework lautet der Standardwert für ProcessStartInfo.UseShellExecutetrue. Dies bedeutet, dass Code wie Process.Start("mytextfile.txt") den Editor starten würde, wenn Sie TXT-Dateien diesem Editor zugeordnet haben. Um zu verhindern, dass eine App indirekt unter .NET Framework gestartet wird, müssen Sie ProcessStartInfo.UseShellExecute explizit auf false festlegen. Für .NET Core ist der Standardwert für ProcessStartInfo.UseShellExecutefalse. Dies bedeutet, dass zugehörige Anwendungen standardmäßig nicht gestartet werden, wenn Sie Process.Start aufrufen.

Die folgenden Eigenschaften in System.Diagnostics.ProcessStartInfo funktionieren nur, wenn ProcessStartInfo.UseShellExecute auf true festgelegt ist:

Diese Änderung wurde aus Leistungsgründen in .NET Core eingeführt. In der Regel wird Process.Start verwendet, um eine Anwendung direkt zu starten. Wenn Sie eine App direkt starten, muss die Windows-Shell nicht einbezogen werden, und die damit verbundenen Leistungskosten entfallen. Damit dieser Standardfall schneller wird, ändert .NET Core den Standardwert aus ProcessStartInfo.UseShellExecute in false. Wenn Sie ihn benötigen, können Sie wahlweise den langsameren Pfad verwenden.

Eingeführt in Version

2.1

Hinweis

In früheren Versionen von .NET Core wurde UseShellExecute nicht für Windows implementiert.

Wenn Ihre App das alte Verhalten benötigt, rufen Sie Process.Start(ProcessStartInfo) auf und legen dabei UseShellExecute auf true für das ProcessStartInfo-Objekt fest.

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

OpenSSL-Versionen unter macOS

Die Runtimes von .NET Core 3.0 und höher unter macOS bevorzugen jetzt OpenSSL 1.1.x-Versionen gegenüber OpenSSL 1.0.x-Versionen für die Typen AesCcm, AesGcm, DSAOpenSsl, ECDiffieHellmanOpenSsl, ECDsaOpenSsl, RSAOpenSsl und SafeEvpPKeyHandle.

Die .NET Core 2.1-Runtime unterstützt jetzt OpenSSL 1.1.x-Versionen, bevorzugt aber immer noch OpenSSL 1.0.x-Versionen.

Änderungsbeschreibung

Zuvor verwendete die .NET Core-Runtime OpenSSL 1.0.x-Versionen unter macOS für Typen, die mit OpenSSL interagieren. Die neueste Version von OpenSSL 1.0.x, OpenSSL 1.0.2, wird jetzt nicht mehr unterstützt. Um Typen, die OpenSSL auf unterstützten Versionen von OpenSSL verwenden, beizubehalten, verwenden die .NET Core 3.0 und spätere Runtimes jetzt neuere Versionen von OpenSSL unter macOS.

Mit dieser Änderung sieht das Verhalten für die .NET Core-Runtimes unter macOS wie folgt aus:

  • Die Runtimes von .NET Core 3.0 und höheren Versionen verwenden OpenSSL 1.1.x, falls verfügbar, und greifen nur dann auf OpenSSL 1.0.x zurück, wenn keine 1.1.x-Version verfügbar ist.

    Für Aufrufer, die die OpenSSL-Interop-Typen mit benutzerdefinierten P/Invokes verwenden, befolgen Sie die Anleitung in den SafeEvpPKeyHandle.OpenSslVersion-Anweisungen. Ihre App stürzt möglicherweise ab, wenn Sie den OpenSslVersion-Wert nicht überprüfen.

  • Die Runtime von .NET Core 2.1 verwendet OpenSSL 1.0.x, falls verfügbar, und greift auf OpenSSL 1.1.x zurück, wenn keine 1.0.x-Version verfügbar ist.

    Die 2.1-Runtime bevorzugt die frühere Version von OpenSSL, da die SafeEvpPKeyHandle.OpenSslVersion-Eigenschaft in .NET Core 2.1 nicht existiert, sodass die OpenSSL-Version zur Laufzeit nicht zuverlässig ermittelt werden kann.

Eingeführt in Version

  • .NET Core 2.1.16
  • .NET Core 3.0.3
  • .NET Core 3.1.2

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

.NET Core 1.0

UnauthorizedAccessException, ausgelöst von FileSystemInfo.Attributes

In .NET Core wird eine UnauthorizedAccessException ausgelöst, wenn der Aufrufer versucht, den Wert eines Dateiattributs festzulegen, aber nicht über die Schreibberechtigung verfügt.

Änderungsbeschreibung

In .NET Framework wird eine ArgumentException ausgelöst, wenn der Aufrufer versucht, in FileSystemInfo.Attributes den Wert eines Dateiattributs festzulegen, aber nicht über die Schreibberechtigung verfügt. In .NET Core wird stattdessen eine UnauthorizedAccessException ausgelöst. (In .NET Core wird eine ArgumentException weiterhin ausgelöst, wenn der Aufrufer versucht, ein ungültiges Dateiattribut festzulegen.)

Eingeführt in Version

1.0

Ändern Sie beliebige catch-Anweisungen so, dass sie nach Bedarf UnauthorizedAccessException anstelle von oder zusätzlich zu ArgumentException abfangen.

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

Verarbeiten von Corrupted State Exceptions wird nicht unterstützt

Das Verarbeiten von Corrupted State Exceptions wird in .NET Core nicht unterstützt.

Änderungsbeschreibung

Zuvor konnten Corrupted State Exceptions durch Ausnahmehandler mit verwaltetem Code abgefangen und verarbeitet werden, indem z. B. eine try-catch-Anweisung in C# verwendet wurde.

Ab .NET Core 1.0 können Corrupted State Exceptions nicht mehr von verwaltetem Code verarbeitet werden. Die Common Language Runtime liefert keine Corrupted State Exceptions an verwalteten Code.

Eingeführt in Version

1.0

Vermeiden Sie die Notwendigkeit einer Verarbeitung von Corrupted State Exceptions, indem Sie sich mit den Situationen befassen, die zu diesen geführt haben. Wenn es absolut notwendig ist, Corrupted State Exceptions zu verarbeiten, schreiben Sie den Ausnahmehandler in C- oder C++-Code.

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

UriBuilder-Eigenschaften werden führenden Zeichen nicht mehr vorangestellt

UriBuilder.Fragment wird führenden #-Zeichen mehr vorangestellt, und UriBuilder.Query wird führenden ?-Zeichen nicht mehr vorangestellt, wenn ein solches Element bereits vorhanden ist.

Änderungsbeschreibung

In .NET Framework stellen die UriBuilder.Fragment- und UriBuilder.Query-Eigenschaften immer ein #- oder ?-Zeichen voran, das sich nach dem gespeicherten Wert richtet. Dieses Verhalten kann zu mehreren #- oder ?-Zeichen im gespeicherten Wert führen, wenn die Zeichenfolge bereits eines dieser führenden Zeichen enthält. Beispielsweise kann der Wert von UriBuilder.Fragment zu ##main werden.

Ab .NET Core 1.0 stellen diese Eigenschaften die #- und ?-Zeichen nicht mehr dem gespeicherten Wert voran, wenn diese bereits am Anfang der Zeichenfolge vorhanden sind.

Eingeführt in Version

1.0

Beim Festlegen der Eigenschaftswerte müssen Sie keines dieser führenden Zeichen mehr explizit entfernen. Dies ist besonders nützlich, wenn Sie Werte anfügen, da Sie die führenden #- oder ?-Zeichen nicht mehr jedes Mal entfernen müssen.

Der folgende Codeausschnitt zeigt z. B. den Verhaltensunterschied zwischen .NET Framework und .NET Core.

var builder = new UriBuilder();
builder.Query = "one=1";
builder.Query += "&two=2";
builder.Query += "&three=3";
builder.Query += "&four=4";

Console.WriteLine(builder.Query);
  • In .NET Framework lautet die Ausgabe ????one=1&two=2&three=3&four=4.
  • In .NET Core lautet die Ausgabe ?one=1&two=2&three=3&four=4.

Kategorie

Core .NET-Bibliotheken

Betroffene APIs

Process.StartInfo löst InvalidOperationException für Prozesse aus, die Sie nicht gestartet haben

Das Lesen der Process.StartInfo-Eigenschaft für Prozesse, die Ihr Code nicht gestartet hat, löst eine InvalidOperationException aus.

Änderungsbeschreibung

In .NET Framework wird beim Zugriff auf die Process.StartInfo-Eigenschaft für Prozesse, die Ihr Code nicht gestartet hat, ein Dummy-ProcessStartInfo-Objekt zurückgegeben. Das Dummyobjekt enthält Standardwerte für alle seine Eigenschaften außer EnvironmentVariables.

Ab .NET Core 1.0 wird eine InvalidOperationException ausgelöst, wenn Sie die Process.StartInfo-Eigenschaft für einen Prozess lesen, den Sie nicht gestartet haben (d. h. durch Aufrufen von Process.Start).

Eingeführt in Version

1.0

Greifen Sie nicht für Prozesse, die Ihr Code nicht gestartet hat, auf die Process.StartInfo-Eigenschaft zu. Lesen Sie diese Eigenschaft z. B. nicht für Prozesse, die von Process.GetProcesses zurückgegeben werden.

Kategorie

Core .NET-Bibliotheken

Betroffene APIs