Breaking Changes für die Migration von .NET Framework zu .NET Core

Artikel
01.05.2024

Wenn Sie eine App von .NET Framework zu den .NET Core-Versionen 1.0 bis 3.1 migrieren, könnten sich die in diesem Artikel aufgeführten Breaking Changes auf Ihre App auswirken. Breaking Changes werden nach Kategorie angeordnet. Innerhalb einer Kategorie sind sie wiederum nach der .NET Core-Version sortiert, in der sie eingeführt wurden.

Hinweis

Dieser Artikel enthält keine vollständige Liste mit Breaking Changes zwischen .NET Framework und .NET Core. Die wichtigsten Breaking Changes werden hier hinzugefügt, sobald wir sie kennen.

Core .NET-Bibliotheken

Änderung des Standardwerts von UseShellExecute
Die IDispatchImplAttribute-API wird entfernt
UnauthorizedAccessException, ausgelöst von FileSystemInfo.Attributes
Verarbeiten von Corrupted Process-State Exceptions wird nicht unterstützt
UriBuilder-Eigenschaften werden führenden Zeichen nicht mehr vorangestellt
Process.StartInfo löst InvalidOperationException für Prozesse aus, die Sie nicht gestartet haben

.NET 8

Die IDispatchImplAttribute-API wird entfernt

.NET Core 2.1

Ä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.

Empfohlene Aktion

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

.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

Empfohlene Aktion

Ä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

FileSystemInfo.Attributes

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

Empfohlene Aktion

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

Empfohlene Aktion

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

Empfohlene Aktion

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

System.Diagnostics.Process.StartInfo

Kryptografie

Der boolesche Parameter von SignedCms.ComputeSignature wird beachtet

.NET Core 2.1

Der boolesche Parameter von SignedCms.ComputeSignature wird beachtet

In .NET Core wird der boolesche Parameter silent der Methode SignedCms.ComputeSignature(CmsSigner, Boolean) beachtet. Eine PIN-Eingabeaufforderung wird nicht angezeigt, wenn dieser Parameter auf true festgelegt ist.

Änderungsbeschreibung

Im .NET Framework wird der Parameter silent der Methode SignedCms.ComputeSignature(CmsSigner, Boolean) ignoriert. Es wird stets eine PIN-Eingabeaufforderung angezeigt, wenn der Anbieter dies verlangt. In .NET Core wird der Parameter silent beachtet. Wenn er auf true festgelegt ist, wird keinesfalls eine PIN-Eingabeaufforderung angezeigt, selbst wenn dies vom Anbieter verlangt wird.

Unterstützung für CMS/PKCS #7-Nachrichten wurde in .NET Core 2.1 eingeführt.

Eingeführt in Version

2.1

Empfohlene Aktion

Um sicherzustellen, dass bei Bedarf eine PIN-Eingabeaufforderung angezeigt wird, sollten Desktopanwendungen SignedCms.ComputeSignature(CmsSigner, Boolean) aufrufen und den booleschen Parameter auf false festlegen. Das resultierende Verhalten ist das gleiche wie bei .NET Framework, und zwar unabhängig davon, ob der Kontext „silent“ dort deaktiviert ist.

Kategorie

Kryptografie

Betroffene APIs

SignedCms.ComputeSignature(CmsSigner, Boolean)

MSBuild

Änderung des Manifestdateinamens der Ressource

.NET Core 3.0

Änderung des Manifestdateinamens der Ressource

Ab .NET Core 3.0 generiert MSBuild im Standardfall einen anderen Manifestdateinamen für Ressourcendateien.

Eingeführt in Version

3.0

Änderungsbeschreibung

Vor .NET Core 3.0 hat MSBuild im Muster <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources einen Manifestdateinamen generiert, wenn für ein EmbeddedResource-Element in der Projektdatei nicht LogicalName-, ManifestResourceName- oder DependentUpon-Metadaten angegeben wurden. Wenn RootNamespace nicht in der Projektdatei definiert ist, wird standardmäßig der Projektname verwendet. Beispielsweise lautete der Name des generierten Manifests für eine Ressourcendatei mit dem Namen Form1.resx im Stammverzeichnis des Projekts MyProject.Form1.resources.

Ab .NET Core 3.0 verwendet MSBuild Typinformationen aus der Quelldatei, wenn eine Ressourcendatei mit einer Quelldatei desselben Namens (z. B. Form1.resx und Form1.cs) angeordnet wird, um den Manifestdateinamen im Muster <Namespace>.<ClassName>.resources zu generieren. Der Namespace- und Klassenname werden aus dem ersten Typ in der angeordneten Quelldatei extrahiert. Beispielsweise lautet der generierte Manifestname für eine Ressourcendatei mit dem Namen Form1.resx, die mit einer Quelldatei mit dem Namen Form1.cs angeordnet wird, MyNamespace.Form1.resources. Wichtig ist zu beachten, dass der erste Teil des Dateinamens sich von früheren Versionen von .NET Core unterscheidet (MyNamespace anstelle von MyProject).

Hinweis

Wenn LogicalName-, ManifestResourceName- oder DependentUpon-Metadaten für ein EmbeddedResource-Element in der Projektdatei angegeben sind, wirkt sich diese Änderung nicht auf diese Ressourcendatei aus.

Dieser Breaking Change wurde mit dem Hinzufügen der EmbeddedResourceUseDependentUponConvention-Eigenschaft zu .NET Core-Projekten eingeführt. Standardmäßig werden Ressourcendateien nicht explizit in einer .NET Core-Projektdatei aufgelistet, sodass Ihnen keine DependentUpon-Metadaten zur Verfügung stehen, um anzugeben, wie die generierte RESOURCES-Datei benannt werden soll. Wenn EmbeddedResourceUseDependentUponConvention dem Standard entsprechend auf true festgelegt ist, sucht MSBuild nach einer angeordneten Quelldatei und extrahiert einen Namespace- und Klassennamen aus dieser Datei. Wenn Sie EmbeddedResourceUseDependentUponConvention auf false festlegen, generiert MSBuild den Namen des Manifests gemäß dem vorherigen Verhalten, wobei RootNamespace und der relative Dateipfad kombiniert werden.

Empfohlene Aktion

In den meisten Fällen ist keine Aktion seitens des Entwicklers erforderlich, und Ihre App sollte weiterhin funktionieren. Wenn diese Änderung jedoch Ihre App beeinträchtigt, haben Sie folgende Möglichkeiten:

Ändern Sie den Code so, dass er den neuen Manifestnamen erwartet.

Um die neue Namenskonvention zu umgehen, legen Sie in Ihrer Projektdatei EmbeddedResourceUseDependentUponConvention auf false fest.

XML

<PropertyGroup>
  <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>

Kategorie

MSBuild

Betroffene APIs

–

Netzwerk

WebClient.CancelAsync wird nicht immer sofort abgebrochen

.NET Core 2.0

WebClient.CancelAsync wird nicht immer sofort abgebrochen

Ab .NET Core 2.0 wird die Anforderung beim Aufrufen von WebClient.CancelAsync() nicht sofort abgebrochen, wenn die Antwort mit dem Abrufen begonnen hat.

Änderungsbeschreibung

Zuvor wurde durch Aufrufen von WebClient.CancelAsync() die Anforderung sofort abgebrochen. Ab .NET Core 2.0 wird die Anforderung beim Aufrufen von WebClient.CancelAsync() nur dann sofort abgebrochen, wenn die Antwort mit dem Abrufen noch nicht begonnen hat. Wenn die Antwort mit dem Abrufen begonnen hat, wird die Anforderung erst abgebrochen, nachdem eine vollständige Antwort gelesen wurde.

Diese Änderung wurde implementiert, weil die WebClient-API zugunsten von HttpClient eingestellt wurde.

Eingeführt in Version

2.0

Empfohlene Aktion

Verwenden Sie die System.Net.Http.HttpClient-Klasse anstelle von System.Net.WebClient, die veraltet ist.

Kategorie

Netzwerk

Betroffene APIs

System.Net.WebClient.CancelAsync()

Windows Forms

Windows Forms-Unterstützung wurde zu .NET Core in Version 3.0 hinzugefügt. Wenn Sie eine Windows Forms-App von .NET Framework zu .NET Core migrieren, könnten sich die in diesem Artikel aufgeführten Breaking Changes auf Ihre App auswirken.

Entfernte Steuerelemente
CellFormatting-Ereignis wird nicht ausgelöst, wenn QuickInfo angezeigt wird
Control.DefaultFont wurde in Segoe UI 9 pt geändert
Modernisierung von FolderBrowserDialog
SerializableAttribute aus einigen Windows Forms-Typen entfernt
Kompatibilitätsoption AllowUpdateChildControlIndexForTabControls wird nicht unterstützt
Kompatibilitätsoption DomainUpDown.UseLegacyScrolling wird nicht unterstützt
Kompatibilitätsoption DoNotLoadLatestRichEditControl wird nicht unterstützt
Kompatibilitätsoption DoNotSupportSelectAllShortcutInMultilineTextBox wird nicht unterstützt
Kompatibilitätsoption DontSupportReentrantFilterMessage wird nicht unterstützt
Kompatibilitätsoption EnableVisualStyleValidation wird nicht unterstützt
Kompatibilitätsoption UseLegacyContextMenuStripSourceControlValue wird nicht unterstützt
Kompatibilitätsoption UseLegacyImages wird nicht unterstützt
Vorlagen „About“ und „SplashScreen“ für Visual Basic sind fehlerhaft
Typen im Microsoft.VisualBasic.ApplicationServices-Namespace nicht verfügbar
Typen im Microsoft.VisualBasic.Devices-Namespace nicht verfügbar
Typen im Microsoft.VisualBasic.MyServices-Namespace nicht verfügbar

.NET Core 3.1

Entfernte Steuerelemente

Ab .NET Core 3.1 sind einige Windows Forms-Steuerelemente nicht mehr verfügbar.

Änderungsbeschreibung

Ab .NET Core 3.1 sind verschiedene Windows Forms-Steuerelemente nicht mehr verfügbar. Ersatzsteuerelemente, die ein besseres Design und eine umfassendere Unterstützung bieten, wurden in .NET Framework 2.0 eingeführt. Die veralteten Steuerelemente wurden zwar bereits aus den Designer-Toolboxen entfernt, konnten aber weiterhin verwendet werden.

Die folgenden Typen stehen nicht mehr länger zur Verfügung:

Eingeführt in Version

3.1

Empfohlene Aktion

Für jedes entfernte Steuerelement gibt es ein empfohlenes Ersatzsteuerelement. Beachten Sie hierzu die folgende Tabelle:

Entferntes Steuerelement (API)	Empfohlener Ersatz	Zugehörige entfernte APIs
ContextMenu	ContextMenuStrip
DataGrid	DataGridView	DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
MainMenu	MenuStrip
Menü	ToolStripDropDown, ToolStripDropDownMenu	MenuItemCollection
MenuItem	ToolStripMenuItem
ToolBar	ToolStrip	ToolBarAppearance
ToolBarButton	ToolStripButton	ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign

Kategorie

Windows Forms

Betroffene APIs

Eine DataGridView zeigt nun Text- und die Fehler-QuickInfos einer Zelle an, wenn mit der Maus darauf gezeigt wird oder wenn sie mit der Tastatur ausgewählt wird. Wenn eine QuickInfo angezeigt wird, wird das DataGridView.CellFormatting-Ereignis nicht ausgelöst.

Änderungsbeschreibung

Vor .NET Core 3.1 wurde bei einer DataGridView, für die die ShowCellToolTips-Eigenschaft auf true festgelegt wurde, eine QuickInfo für den Text und Fehler einer Zelle angezeigt, wenn mit der Maus auf die Zelle gezeigt wurde. Es wurden keine QuickInfos angezeigt, wenn die Maus mit der Tastatur ausgewählt wurde (z. B. mit der TAB-TASTE, einer Tastenkombination oder den Pfeiltasten). Wenn der Benutzer eine Zelle bearbeitet hat und die DataGridView sich noch im Bearbeitungsmodus befunden hat und mit der Maus auf eine Zelle gezeigt wurde, für die die ToolTipText-Eigenschaft nicht festgelegt war, wurde ein CellFormatting-Ereignis ausgelöst, um den Text der Zelle für die Anzeige in der Zelle zu formatieren.

Um die Barrierefreiheitsstandards zu erfüllen, werden ab .NET Core 3.1 bei einer DataGridView, für die die ShowCellToolTips-Eigenschaft auf true festgelegt ist, QuickInfos für den Text und Fehler der Zelle nicht nur dann angezeigt, wenn mit der Maus darauf gezeigt wird, sondern auch, wenn sie mit der Tastatur ausgewählt wird. Infolge dieser Änderung wird das CellFormatting-Ereignis nicht ausgelöst, wenn mit der Maus auf Zellen gezeigt wird, für die ToolTipText-Eigenschaft nicht festgelegt ist, und die DataGridView sich im Bearbeitungsmodus befindet. Das Ereignis wird nicht ausgelöst, da der Inhalt der Zelle, auf die gezeigt wird, als QuickInfo und nicht in der Zelle dargestellt wird.

Eingeführt in Version

3.1

Empfohlene Aktion

Schreiben Sie Code um, der das CellFormatting-Ereignis benötigt, während sich die DataGridView im Bearbeitungsmodus befindet.

Kategorie

Windows Forms

Betroffene APIs

Keine

.NET Core 3.0

Standardschriftart für Steuerelemente in Segoe UI 9 pt geändert

Änderungsbeschreibung

Im .NET Framework wurde die Eigenschaft Control.DefaultFont auf Microsoft Sans Serif 8.25 pt festgelegt. Die folgende Abbildung zeigt ein Fenster, in dem die Standardschriftart verwendet wird.

Standardschriftart für Steuerelemente im .NET Framework

Ab .NET Core 3.0 ist die Standardschriftart auf Segoe UI 9 pt festgelegt (dieselbe Schriftart wie SystemFonts.MessageBoxFont). Infolge dieser Änderung werden Formulare und Steuerelemente etwa 27 % größer dimensioniert, um der größeren neuen Standardschriftart gerecht zu werden. Beispiel:

Standardschriftart für Steuerelemente in .NET Core

Diese Änderung wurde entsprechend den Leitfäden für Benutzeroberflächen unter Windows vorgenommen.

Eingeführt in Version

3.0

Empfohlene Aktion

Aufgrund der Änderung der Größe von Formularen und Steuerelementen sollten Sie sicherstellen, dass Ihre Anwendung richtig gerendert wird.

Um die ursprüngliche Schriftart für ein einzelnes Formular beizubehalten, legen Sie die Standardschriftart auf Microsoft Sans Serif 8.25 pt fest. Zum Beispiel:

public MyForm()
{
    InitializeComponent();
    Font = new Font(new FontFamily("Microsoft Sans Serif"), 8.25f);
}

Alternativ können Sie die Standardschriftart für eine gesamte Anwendung auf eine der folgenden Weisen ändern:

Durch Festlegen der ApplicationDefaultFont MSBuild-Eigenschaft auf „Microsoft Sans Serif, 8.25pt“. Dies ist die bevorzugte Technik, da Visual Studio so die neuen Einstellungen im Designer verwenden kann.

XML
```
<PropertyGroup>
  <ApplicationDefaultFont>Microsoft Sans Serif, 8.25pt</ApplicationDefaultFont>
</PropertyGroup>
```

Durch Aufrufen von Application.SetDefaultFont(Font).

class Program
{
    [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.SetHighDpiMode(HighDpiMode.SystemAware);
        Application.SetDefaultFont(new Font(new FontFamily("Microsoft Sans Serif"), 8.25f));
        Application.Run(new Form1());
    }
}

Kategorie

Windows Forms

Betroffene APIs

Keine.

Modernisierung von FolderBrowserDialog

Das FolderBrowserDialog-Steuerelement wurde in Windows Forms-Anwendungen für .NET Core geändert.

Änderungsbeschreibung

In .NET Framework verwendet Windows Forms das folgende Dialogfeld für das FolderBrowserDialog-Steuerelement:

FolderBrowserDialogControl in .NET Framework

In .NET Core 3.0 verwendet Windows Forms ein neueres COM-basiertes Steuerelement, das in Windows Vista eingeführt wurde:

FolderBrowserDialogControl in .NET Core

Eingeführt in Version

3.0

Empfohlene Aktion

Das Dialogfeld wird automatisch aktualisiert.

Wenn Sie das ursprüngliche Dialogfeld beibehalten möchten, legen Sie die FolderBrowserDialog.AutoUpgradeEnabled-Eigenschaft auf false fest, bevor Sie das Dialogfeld anzeigen, wie im folgenden Codefragment veranschaulicht:

var dialog = new FolderBrowserDialog();
dialog.AutoUpgradeEnabled = false;
dialog.ShowDialog();

Kategorie

Windows Forms

Betroffene APIs

FolderBrowserDialog

SerializableAttribute aus einigen Windows Forms-Typen entfernt

SerializableAttribute wurde aus einigen Windows Forms-Klassen ohne bekannte Szenarios für binäre Serialisierung entfernt.

Änderungsbeschreibung

Die folgenden Typen enthalten in .NET Framework das Attribut SerializableAttribute, das in .NET Core entfernt wurde:

System.InvariantComparer
System.ComponentModel.Design.ExceptionCollection
System.ComponentModel.Design.Serialization.CodeDomSerializerException
System.ComponentModel.Design.Serialization.CodeDomComponentSerializationService.CodeDomSerializationStore
System.Drawing.Design.ToolboxItem
System.Resources.ResXNullRef
System.Resources.ResXDataNode
System.Resources.ResXFileRef
System.Windows.Forms.Cursor
System.Windows.Forms.NativeMethods.MSOCRINFOSTRUCT
System.Windows.Forms.NativeMethods.MSG

In der Vergangenheit bereitete dieser Serialisierungsmechanismus schwerwiegende Wartungs- und Sicherheitsprobleme. Die Beibehaltung von SerializableAttribute für Typen bedeutet, dass diese Typen auf Serialisierungsänderungen zwischen Versionen und auf potenzielle Serialisierungsänderungen zwischen Frameworks geprüft werden müssen. Dies erschwert die Weiterentwicklung dieser Typen und verteuert die Beibehaltung. Da es für diese Typen keine bekannten Serialisierungsszenarios gibt, sind die Auswirkungen minimal, wenn das Attribut entfernt wird.

Weitere Informationen finden Sie unter Binäre Serialisierung.

Eingeführt in Version

3.0

Empfohlene Aktion

Aktualisieren Sie jeden Code, der von diesen als serialisierbar markierten Typen abhängig ist.

Kategorie

Windows Forms

Betroffene APIs

Keine

Kompatibilitätsoption AllowUpdateChildControlIndexForTabControls wird nicht unterstützt

Der Kompatibilitätsswitch Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls wird in Windows Forms unter .NET Framework 4.6 und höheren Versionen unterstützt. Er wird jedoch nicht unter .NET Core oder .NET 5.0 oder höher unterstützt.

Änderungsbeschreibung

Wenn in .NET Framework 4.6 und höheren Versionen eine Registerkarte ausgewählt wird, wird die Steuerelementauflistung neu sortiert. Mit dem Kompatibilitätsswitch Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls kann eine Anwendung diese Neusortierung überspringen, sofern dieses Verhalten unerwünscht ist.

In .NET Core und .NET 5.0 oder höher wird der Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls-Switch nicht unterstützt.

Eingeführt in Version

3.0

Empfohlene Aktion

Entfernen Sie den Switch. Der Switch wird nicht unterstützt, und es ist keine alternative Funktionalität verfügbar.

Kategorie

Windows Forms

Betroffene APIs

Keine

Kompatibilitätsoption DomainUpDown.UseLegacyScrolling wird nicht unterstützt

Der mit .NET Framework 4.7.1 eingeführte Kompatibilitätsswitch Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling wird in Windows Forms unter .NET Core oder .NET 5.0 oder höher nicht unterstützt.

Änderungsbeschreibung

Ab .NET Framework 4.7.1 können Entwickler mit dem Kompatibilitätsswitch Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling die unabhängigen Aktionen DomainUpDown.DownButton() und DomainUpDown.UpButton() abstellen. Mit dem Switch wird das Legacyverhalten wiederhergestellt, bei dem DomainUpDown.UpButton() ignoriert wird, wenn Kontexttext vorhanden ist, und der Entwickler wird gezwungen, die Aktion DomainUpDown.DownButton() vor der Aktion DomainUpDown.UpButton() auf das Steuerelement anwenden. Weitere Informationen finden Sie unter <AppContextSwitchOverrides>-Element.

In .NET Core und .NET 5.0 oder höher wird der Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling-Switch nicht unterstützt.

Eingeführt in Version

3.0

Empfohlene Aktion

Entfernen Sie den Switch. Der Switch wird nicht unterstützt, und es ist keine alternative Funktionalität verfügbar.

Kategorie

Windows Forms

Keine

Vorlagen „About“ und „SplashScreen“ sind fehlerhaft

Die von Visual Studio generierten Dateien About.vb und SplashScreen.vb enthalten Verweise auf Typen im My-Namespace, die in .NET Core 3.0 und 3.1 nicht verfügbar sind.

Eingeführt in Version

3.0

Änderungsbeschreibung

.NET Core 3.0 und 3.1 bieten keine vollständige Unterstützung für My in Visual Basic. Die Formularvorlagen About und SplashScreen in Visual Studio für Visual Basic Windows Forms-Apps verweisen auf Eigenschaften im Typ My.Application.Info, die nicht verfügbar sind.

Empfohlene Maßnahme

Die Unterstützung für My in Visual Basic wurde in .NET 5 verbessert. Führen Sie ein Upgrade Ihres Projekts auf .NET 5 oder höher durch.

Oder

Beheben Sie die Compilerfehler in den Typen About und SplashScreen in Ihrer App. Verwenden Sie die Klasse System.Reflection.Assembly, um die vom Typ My.Application.Info bereitgestellten Informationen zu erhalten. Eine direkte Portierung beider Formulare ist hier verfügbar.

Tipp

Dies ist Beispielcode und nicht optimiert. Die Liste der Attribute sollte zwischengespeichert werden, um die Ladezeit von Formularen zu verkürzen.

Info

Imports System.Reflection

Public NotInheritable Class About

    Private Sub about_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        ' Set the title of the form.
        Dim applicationTitle As String = Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyTitleAttribute)()?.Title

        If String.IsNullOrEmpty(applicationTitle) Then
            applicationTitle = System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().GetName().Name)
        End If

        Me.Text = String.Format("About {0}", applicationTitle)
        ' Initialize all of the text displayed on the About Box.
        ' TODO: Customize the application's assembly information in the "Application" pane of the project
        '    properties dialog (under the "Project" menu).
        Me.LabelProductName.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyProductAttribute)()?.Product, "")
        Me.LabelVersion.Text = String.Format("Version {0}", Assembly.GetExecutingAssembly().GetName().Version)
        Me.LabelCopyright.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCopyrightAttribute)()?.Copyright, "")
        Me.LabelCompanyName.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCompanyAttribute)()?.Company, "")
        Me.TextBoxDescription.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyDescriptionAttribute)()?.Description, "")
    End Sub

    Private Sub OKButton_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles OKButton.Click
        Me.Close()
    End Sub

End Class

SplashScreen

Imports System.Reflection

Public NotInheritable Class SplashScreen

    Private Sub SplashScreen1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        'Set up the dialog text at runtime according to the application's assembly information.  

        'TODO: Customize the application's assembly information in the "Application" pane of the project
        '  properties dialog (under the "Project" menu).

        'Application title
        Dim appTitle As String = Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyTitleAttribute)()?.Title

        If String.IsNullOrEmpty(appTitle) Then
            appTitle = System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().GetName().Name)
        End If

        ApplicationTitle.Text = appTitle

        Dim versionValue = Assembly.GetExecutingAssembly().GetName().Version

        'Format the version information using the text set into the Version control at design time as the
        '  formatting string.  This allows for effective localization if desired.
        '  Build and revision information could be included by using the following code and changing the
        '  Version control's designtime text to "Version {0}.{1:00}.{2}.{3}" or something similar.  See
        '  String.Format() in Help for more information.
        '
        '    Version.Text = System.String.Format(Version.Text, versionValue.Major, versionValue.Minor, versionValue.Build, versionValue.Revision)

        Version.Text = System.String.Format(Version.Text, versionValue.Major, versionValue.Minor)

        'Copyright info
        Copyright.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCopyrightAttribute)()?.Copyright, "")
    End Sub

End Class

Kategorie

Visual Basic Windows Forms

Betroffene APIs

Keine

Typen im Microsoft.VisualBasic.ApplicationServices-Namespace nicht verfügbar

Die Typen im Microsoft.VisualBasic.ApplicationServices-Namespace sind nicht verfügbar.

Eingeführt in Version

.NET Core 3.0

Beschreibung der Änderung

Die Typen im Microsoft.VisualBasic.ApplicationServices-Namespace waren in .NET Framework verfügbar. In .NET Core 3.0 bis 3.1 sind sie nicht verfügbar.

Die Typen wurden entfernt, um unnötige Assemblyabhängigkeiten oder Breaking Changes in nachfolgenden Releases zu vermeiden.

Empfohlene Maßnahme

Dieser Namespace wurde in .NET 5 hinzugefügt. Führen Sie ein Upgrade Ihres Projekts auf .NET 5 oder höher durch.

Oder

Wenn Sie für Ihren Code Microsoft.VisualBasic.ApplicationServices-Typen und deren Member benötigen, können Sie möglicherweise einen entsprechenden Typ oder Member in der .NET-Klassenbibliothek verwenden. So stellen beispielsweise einige System.Environment- und System.Security.Principal.WindowsIdentity-Member entsprechende Funktionen für die Eigenschaften der Microsoft.VisualBasic.ApplicationServices.User-Klasse bereit.

Kategorie

Visual Basic

Betroffene APIs

Microsoft.VisualBasic.ApplicationServices

Typen im Microsoft.VisualBasic.Devices-Namespace nicht verfügbar

Die Typen im Microsoft.VisualBasic.Devices-Namespace sind nicht verfügbar.

Eingeführt in Version

.NET Core 3.0

Beschreibung der Änderung

Die Typen im Microsoft.VisualBasic.Devices-Namespace waren in .NET Framework verfügbar. In .NET Core 3.0 bis 3.1 sind sie nicht verfügbar.

Die Typen wurden entfernt, um unnötige Assemblyabhängigkeiten oder Breaking Changes in nachfolgenden Releases zu vermeiden.

Empfohlene Maßnahme

Dieser Namespace wurde in .NET 5 hinzugefügt. Führen Sie ein Upgrade Ihres Projekts auf .NET 5 oder höher durch.

Oder

Wenn Sie für Ihren Code Microsoft.VisualBasic.Devices-Typen und deren Member benötigen, können Sie möglicherweise einen entsprechenden Typ oder Member in der .NET-Klassenbibliothek verwenden. Beispielsweise werden die entsprechenden Funktionen für die Microsoft.VisualBasic.Devices.Clock-Klasse von den Typen System.DateTime und System.Environment bereitgestellt, und die entsprechenden Funktionen für die Microsoft.VisualBasic.Devices.Ports-Klasse wird von Typen im System.IO.Ports-Namespace bereitgestellt.

Kategorie

Visual Basic

Betroffene APIs

Microsoft.VisualBasic.Devices

Typen im Microsoft.VisualBasic.MyServices-Namespace nicht verfügbar

Die Typen im Microsoft.VisualBasic.MyServices-Namespace sind nicht verfügbar.

Eingeführt in Version

.NET Core 3.0

Beschreibung der Änderung

Die Typen im Microsoft.VisualBasic.MyServices-Namespace waren in .NET Framework verfügbar. In .NET Core 3.0 bis 3.1 sind sie nicht verfügbar.

Die Typen wurden entfernt, um unnötige Assemblyabhängigkeiten oder Breaking Changes in nachfolgenden Releases zu vermeiden.

Empfohlene Maßnahme

Dieser Namespace wurde in .NET 5 hinzugefügt. Führen Sie ein Upgrade Ihres Projekts auf .NET 5 oder höher durch.

Oder

Wenn Sie für Ihren Code Microsoft.VisualBasic.MyServices-Typen und deren Member benötigen, finden Sie entsprechende Typen und Member in der .NET-Klassenbibliothek. Im Folgenden ist eine Zuordnung von Microsoft.VisualBasic.MyServices-Typen zu den entsprechenden .NET-Klassenbibliothekstypen dargestellt:

Microsoft.VisualBasic.MyServices-Typ	.NET-Klassenbibliothekstyp
ClipboardProxy	System.Windows.Clipboard für WPF-Anwendungen, System.Windows.Forms.Clipboard für Windows Forms-Anwendungen
FileSystemProxy	Typen im System.IO-Namespace
RegistryProxy	Registrierungsbezogene Typen im Microsoft.Win32-Namespace
SpecialDirectoriesProxy	Environment.GetFolderPath

Teilen über

Breaking Changes für die Migration von .NET Framework zu .NET Core

Core .NET-Bibliotheken

.NET 8

.NET Core 2.1

Änderung des Standardwerts von UseShellExecute

Änderungsbeschreibung

Eingeführt in Version

Empfohlene Aktion

Kategorie

Betroffene APIs

.NET Core 1.0

UnauthorizedAccessException, ausgelöst von FileSystemInfo.Attributes

Änderungsbeschreibung

Eingeführt in Version

Empfohlene Aktion

Kategorie

Betroffene APIs

Verarbeiten von Corrupted State Exceptions wird nicht unterstützt

Änderungsbeschreibung

Eingeführt in Version

Empfohlene Aktion

Kategorie

Betroffene APIs

UriBuilder-Eigenschaften werden führenden Zeichen nicht mehr vorangestellt

Änderungsbeschreibung

Eingeführt in Version

Empfohlene Aktion

Kategorie

Betroffene APIs

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

Änderungsbeschreibung

Eingeführt in Version

Empfohlene Aktion

Kategorie

Betroffene APIs

Kryptografie

.NET Core 2.1

Der boolesche Parameter von SignedCms.ComputeSignature wird beachtet

Änderungsbeschreibung

Eingeführt in Version

Empfohlene Aktion

Kategorie

Betroffene APIs

MSBuild

.NET Core 3.0

Änderung des Manifestdateinamens der Ressource

Eingeführt in Version

Änderungsbeschreibung

Empfohlene Aktion

Kategorie

Betroffene APIs

Netzwerk

.NET Core 2.0

WebClient.CancelAsync wird nicht immer sofort abgebrochen

Änderungsbeschreibung

Eingeführt in Version

Empfohlene Aktion

Kategorie

Betroffene APIs

Windows Forms

.NET Core 3.1

Entfernte Steuerelemente

Änderungsbeschreibung

Eingeführt in Version

Empfohlene Aktion

Kategorie

Betroffene APIs

CellFormatting-Ereignis wird nicht ausgelöst, wenn QuickInfo angezeigt wird

Änderungsbeschreibung

Eingeführt in Version

Empfohlene Aktion

Kategorie

Betroffene APIs

.NET Core 3.0

Standardschriftart für Steuerelemente in Segoe UI 9 pt geändert

Änderungsbeschreibung

Eingeführt in Version

Empfohlene Aktion

Kategorie