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

  • Artikel

Wenn Sie eine App von .NET Framework zu den .NET Core-Versionen 1.0 bis 3.1 migrieren, können 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

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

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

Ä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

Kryptografie

.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

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

MSBuild

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

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.

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

Kategorie

MSBuild

Betroffene APIs

–

Netzwerk

.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

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

Kategorie

Netzwerk

Betroffene APIs

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önnen sich die in diesem Artikel aufgeführten Breaking Changes auf Ihre App auswirken.

.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

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

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

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

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 pt festgelegt. Die folgende Abbildung zeigt ein Fenster, in dem die Standardschriftart verwendet wird.

Default control font in .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:

Default control font in .NET Core

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

Eingeführt in Version

3.0

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

Wenn Sie die ursprüngliche Schriftart beibehalten möchten, legen Sie die Standardschriftart des Formulars auf Microsoft Sans Serif 8 pt fest. Zum Beispiel:

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

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:

The FolderBrowserDialogControl in the .NET Framework

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

The FolderBrowserDialogControl in the .NET Core

Eingeführt in Version

3.0

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

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:

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

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

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

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

Kategorie

Windows Forms

Betroffene APIs

Kompatibilitätsoption DoNotLoadLatestRichEditControl wird nicht unterstützt

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

Änderungsbeschreibung

In .NET Framework 4.6.2 und früheren Versionen instanziiert das RichTextBox-Steuerelement das Win32 RichEdit-Steuerelement v3.0, und bei Anwendungen für .NET Framework 4.7.1 instanziiert das Steuerelement RichTextBox RichEdit v4.1 (in msftedit.dll). Der Kompatibilitätsswitch Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl wurde eingeführt, damit Anwendungen für .NET Framework 4.7.1 und höhere Versionen das neue RichEdit v4.1-Steuerelement ignorieren und stattdessen das alte RichEdit v3-Steuerelement verwenden können.

In .NET Core und .NET 5.0 oder höheren Versionen wird der Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl-Switch nicht unterstützt. Es werden nur neue Versionen des RichTextBox-Steuerelements unterstützt.

Eingeführt in Version

3.0

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

Kategorie

Windows Forms

Betroffene APIs

Kompatibilitätsoption DoNotSupportSelectAllShortcutInMultilineTextBox wird nicht unterstützt

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

Änderungsbeschreibung

Ab .NET Framework 4.6.1 wird mit der Tastenkombination STRG + A in einem TextBox-Steuerelement der gesamte Text ausgewählt. In .NET Framework 4.6 und früheren Versionen konnte mit der Tastenkombination STRG + A nicht der gesamte Text ausgewählt werden, wenn die beiden Eigenschaften Textbox.ShortcutsEnabled und TextBox.Multiline auf true festgelegt waren. Der Kompatibilitätsswitch Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox wurde in .NET Framework 4.6.1 eingeführt, um das ursprüngliche Verhalten beizubehalten. Weitere Informationen finden Sie unter TextBox.ProcessCmdKey.

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

Eingeführt in Version

3.0

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 DontSupportReentrantFilterMessage wird nicht unterstützt

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

Änderungsbeschreibung

Ab .NET Framework 4.6.1 werden mit dem Kompatibilitätsswitch Switch.System.Windows.Forms.DontSupportReentrantFilterMessage mögliche IndexOutOfRangeException-Ausnahmen behandelt, wenn die Application.FilterMessage-Nachricht mit einer benutzerdefinierten IMessageFilter.PreFilterMessage-Implementierung aufgerufen wird. Weitere Informationen finden Sie unter Entschärfung: Benutzerdefinierte IMessageFilter.PreFilterMessage-Implementierungen.

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

Eingeführt in Version

3.0

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

Kategorie

Windows Forms

Betroffene APIs

Kompatibilitätsoption EnableVisualStyleValidation wird nicht unterstützt

Der Kompatibilitätsswitch Switch.System.Windows.Forms.EnableVisualStyleValidation wird in Windows Forms unter .NET Core oder .NET 5.0 oder höher nicht unterstützt.

Änderungsbeschreibung

In .NET Framework ist es mit dem Kompatibilitätsswitch Switch.System.Windows.Forms.EnableVisualStyleValidation möglich, dass eine Anwendung die Prüfung von visuellen Elementen abstellt, die in einer numerischen Form bereitgestellt werden.

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

Eingeführt in Version

3.0

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 UseLegacyContextMenuStripSourceControlValue wird nicht unterstützt

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

Änderungsbeschreibung

Ab .NET Framework 4.7.2 kann der Entwickler mit dem Kompatibilitätsswitch Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue das neue Verhalten der ContextMenuStrip.SourceControl-Eigenschaft abstellen, mit dem nun ein Verweis an die Quellcodeverwaltung zurückgegeben wird. Mit dem früheren Verhalten der Eigenschaft wurde null zurückgegeben. Weitere Informationen finden Sie unter <AppContextSwitchOverrides>-Element.

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

Eingeführt in Version

3.0

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

Kategorie

Windows Forms

Betroffene APIs

Kompatibilitätsoption UseLegacyImages wird nicht unterstützt

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

Änderungsbeschreibung

Ab .NET Framework 4.8 werden mit dem Kompatibilitätsswitch Switch.System.Windows.Forms.UseLegacyImages mögliche Bildskalierungsprobleme in ClickOnce-Szenarios in Umgebungen mit hohem DPI-Wert behoben. Wenn der Switch auf true festgelegt wird, kann der Benutzer die Legacybildskalierung in Anzeigen mit hohem DPI-Wert wiederherstellen, deren Skalierung auf mehr als 100 % festgelegt ist. Weitere Informationen finden Sie unter Versionshinweise zu .NET Framework 4.8 auf GitHub.

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

Eingeführt in Version

3.0

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

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.

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.

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

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.

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

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.

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

Kategorie

Visual Basic

Betroffene APIs

Siehe auch