Runtimeänderungen für die Migration zu .NET Framework 4.8.x

In diesem Artikel werden App-Kompatibilitätsprobleme aufgeführt, die in .NET Framework 4.8 und 4.8.1 auftreten.

.NET Framework 4.8

ASP.NET

Behandlung von Korrekturen in ASP.NET bei InputAttributes und LabelAttributes für WebForms CheckBox-Steuerelemente

Details

Bei Anwendungen, die .NET Framework 4.7.2 und frühere Versionen nutzen, gehen CheckBox.InputAttributes und CheckBox.LabelAttributes, die einem WebForms CheckBox-Steuerelement programmgesteuert hinzugefügt wurden, nach einem Postback verloren. Bei Anwendungen, die .NET Framework 4.8 oder höhere Versionen verwenden, bleiben sie nach einem Postback erhalten.

Vorschlag

Wenn Sie bei der Wiederherstellung nach einem Postback das richtige Verhalten erzielen möchten, legen Sie targetFrameworkVersion auf 4.8 oder höher fest. Zum Beispiel:

<configuration>
<system.web>
<httpRuntime targetFramework="4.8"/>
</system.web>
</configuration>

Wenn Sie eine frühere oder gar keine Version angeben, wird das alte falsche Verhalten beibehalten.

Betroffene APIs

• System.Web.UI.WebControls.CheckBox

Falsche Behandlung von mehrteiligen Elementen in ASP.NET kann zu Datenverlusten bei Formularen führen.

Details

In Anwendungen für .NET Framework 4.7.2 und früher werden mehrteilige Grenzwerte von ASP.NET möglicherweise falsch analysiert, was dazu führt, dass Formulardaten bei der Ausführung einer Anforderung nicht verfügbar sind. Anwendungen, die .NET Framework 4.8 oder höhere Versionen gezielt nutzen, analysieren mehrteilige Daten ordnungsgemäß, sodass Formularwerte bei der Ausführung von Anforderungen verfügbar sind.

Vorschlag

Ab Anwendungen, die unter .NET Framework 4.8 ausgeführt werden, ändert sich das Standardverhalten bei gezielter Nutzung von .NET Framework 4.8 oder höher durch Verwenden des targetFrameworkVersion-Elements, und Trennzeichen werden entfernt. Wenn frühere Framework-Versionen gezielt genutzt oder targetFrameworkVersion nicht verwendet wird, werden weiterhin für einige Werte nachstehende Trennzeichen zurückgegeben.

Dieses Verhalten kann auch explizit mit einer appSetting gesteuert werden:

<configuration>
<appSettings>
...
<add key="aspnet:UseLegacyMultiValueHeaderHandling"  value="true"/>
...
</appSettings>
</configuration>

Betroffene APIs

• HttpRequest.Form
• HttpRequest.Files
• HttpRequest.ContentEncoding

ASP.NET ValidationContext.MemberName ist bei Verwendung des benutzerdefinierten DataAnnotations.ValidationAttribute nicht NULL

Details

Wenn in .NET Framework 4.7.2 und früheren Versionen ein benutzerdefiniertes System.ComponentModel.DataAnnotations.ValidationAttribute verwendet wurde, wurde von der ValidationContext.MemberName-Eigenschaft null zurückgegeben. In der .NET Framework 4.8-Version vor dem Update vom Oktober 2019 wird der Membername zurückgegeben. Ab der Vorschauversion des Qualitätsrollups für .NET Framework vom Oktober 2019 für .NET Framework 4.8 wird standardmäßig null zurückgegeben, aber Sie können sich dafür entscheiden, stattdessen den Membernamen zurückzugeben.

Vorschlag

Fügen Sie die folgende Einstellung zu Ihrer Datei web.config hinzu, damit die Eigenschaft den Membernamen in der Vorschauversion des Qualitätsrollups für .NET Framework vom Oktober 2019 für .NET Framework 4.8 und spätere Versionen zurückgibt:

<configuration>
<appSettings>
...
<add key="aspnet:GetValidationMemberName"  value="true"/>
...
</appSettings>
</configuration>

In der .NET Framework 4.8-Version vor dem Update von Oktober 2019 wird durch das Hinzufügen dieser Einstellung zu Ihrer Datei web.config das vorherige Verhalten wiederhergestellt, und die Eigenschaft gibt null zurück.

Betroffene APIs

• ValidationContext.MemberName

Core

.NET COM hat die ByRef-SafeArray-Parameter für Ereignisse erfolgreich gemarshallt.

Details

In .NET Framework 4.7.2 und früheren Version konnte der ByRef-SafeArray-Parameter für ein COM-Ereignis nicht wieder in nativen Code gemarshallt werden. Durch diese Änderung wird der SafeArray-Parameter wieder erfolgreich gemarshallt.

• [X] Quirking

Vorschlag

Wenn ein ordnungsgemäßes Marshalling des ByRef-SafeArray-Parameters bei COM-Ereignissen die Ausführung unterbricht, können Sie diesen Code deaktivieren, indem Sie die folgende Konfigurationsoption Ihrer Anwendungskonfiguration hinzufügen:

<appSettings>
  <add key="Switch.System.Runtime.InteropServices.DoNotMarshalOutByrefSafeArrayOnInvoke" value="true" />
</appSettings>

Betroffene APIs

Nicht über API-Analyse erkennbar.

.NET Interop verwendet jetzt QueryInterface für IAgileObject (eine WinRT-Oberfläche)

Details

Wenn ein WinRT-Ereignis mit einem .NET-Delegaten verwendet wird, nutzt Windows ab .NET Framework 4.8 QI für IAgileObject. In früheren Versionen von .NET Framework ist bei QI zur Laufzeit ein Fehler aufgetreten, und das Ereignis konnte nicht abonniert werden.

• [X] Quirking

Vorschlag

Wenn die QI für IAgileObject die Ausführung unterbricht, können Sie diesen Code deaktivieren, indem Sie die folgende Konfiguration festlegen.

Methode 1: Umgebungsvariable

Legen Sie die folgende Umgebungsvariable fest: COMPLUS_DisableCCWSupportIAgileObject=1

Diese Methode wirkt sich auf jede Umgebung aus, die diese Umgebungsvariable erbt. Dabei kann es sich um eine einzelne Konsolensitzung handeln oder, wenn Sie die Umgebungsvariable global festlegen, um den gesamten Computer. Beim Namen der Umgebungsvariablen muss die Groß-/Kleinschreibung nicht beachtet werden.

Methode 2: Registrierung

Suchen Sie mithilfe des Registrierungs-Editors („regedit.exe“) einen der folgenden Unterschlüssel:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework
• HKEY_CURRENT_USER\SOFTWARE\Microsoft.NETFramework

Fügen Sie dann den folgenden Eintrag hinzu:

Name: DisableCCWSupportIAgileObject Type: DWORD (32-bit) value (auch als REG_DWORD bezeichnet) Data: 1

Mit dem Windows-Tool „REG.EXE“ können Sie diesen Wert über eine Befehlszeilen- oder Skriptumgebung hinzufügen. Zum Beispiel:

reg add HKLM\SOFTWARE\Microsoft.NETFramework /v DisableCCWSupportIAgileObject /t REG_DWORD /d 1

In diesem Fall wird HKLM anstelle von HKEY_LOCAL_MACHINE verwendet. Verwenden Sie reg add /?, um Hilfe zu dieser Syntax zu erhalten. Beim Namen des Registrierungswerts wird die Groß-/Kleinschreibung nicht beachtet.

Betroffene APIs

Nicht über API-Analyse erkennbar.

Windows Communication Foundation (WCF)

Änderungen bei ComboBox in svcTraceViewer

Details

Bei bestimmten Designs mit hohem Kontrast wurden ComboBox-Steuerelemente im Tool Microsoft Service Trace Viewer nicht in der richtigen Farbe angezeigt. Dieses Problem wurde in .NET Framework 4.7.2 behoben. Aufgrund der für .NET Framework SDK geltenden Abwärtskompatibilitätsanforderungen war die Korrektur für Kunden nicht standardmäßig sichtbar. In .NET 4.8 zeigt sich diese Änderung nun, da der Datei „svcTraceViewer.exe.config“ die folgenden AppContext-Konfigurationsswitches hinzugefügt wurden:

<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" />

Vorschlag

Wenn Sie die Änderung im Verhalten bei hohem Kontrast nicht wünschen, können Sie diese deaktivieren, indem Sie den folgenden Abschnitt in der Konfigurationsdatei „svcTraceViewer.exe.config“ entfernen:

<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" />

Betroffene APIs

Nicht über API-Analyse erkennbar.

Windows Presentation Foundation (WPF)

Verbesserung der Datenbindung für KeyedCollection

Details

Korrektur von Binding: Falsche Verwendung von IList-Indexer, wenn das Quellobjekt einen benutzerdefinierten Indexer mit derselben Signatur (z. B. KeyedCollection<int,TItem>) deklariert.

Vorschlag

Damit eine Anwendung für eine ältere Version von dieser Änderung profitiert, muss sie unter .NET Framework 4.8 oder höher ausgeführt werden. Zudem muss die Änderung aktiviert werden, indem der folgende AppContext-Switch zum <runtime>-Abschnitt der Konfigurationsdatei der Anwendung hinzugefügt und auf false festgelegt wird:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
</startup>
<runtime>
<!-- AppContextSwitchOverrides value attribute is in the form of key1=true/false;key2=true/false  -->
<AppContextSwitchOverrides value="Switch.System.Windows.Data.Binding.IListIndexerHidesCustomIndexer=false" />
</runtime>
</configuration>

Betroffene APIs

Nicht über API-Analyse erkennbar.

Ein Problem wurde behoben, bei dem ListBox nicht mehr reagiert, wenn sie doppelte Werttypen enthält.

Details

Es wurde ein Problem behoben, das dazu führen kann, dass ein virtualisierendes ItemsControl beim Scrollen nicht mehr reagiert, wenn die zugehörige Items-Sammlung Objekte mit doppelter Werttypisierung enthält.

Betroffene APIs

Nicht über API-Analyse erkennbar.

Verbesserungen für den Algorithmus zur Speicherplatzreservierung bei Grid-Sternzeilen

Details

Es wurde ein Fehler im Algorithmus zur Größenzuordnung behoben, der in einem Grid in .NET Framework 4.7 eingeführt wurde. Wenn ein Grid dieser Art mit Height="Auto" leere Zeilen enthielt, wurden Zeilen gelegentlich an der falschen Position, möglicherweise sogar außerhalb des Grids angeordnet.

Vorschlag

Damit die Anwendung von diesen Änderungen profitieren kann, muss sie unter .NET Framework 4.8 oder höher ausgeführt werden.

Betroffene APIs

Nicht über API-Analyse erkennbar.

Verbesserte Tastaturnavigation in ListBox mit Links

Details

Das Problem eines falschen Ergebnisses beim Drücken einer Pfeiltaste, wenn der Fokus auf einem Link in einem Element liegt, bei dem es sich nicht um das ausgewählte Element des übergeordneten Elements ItemsControl handelt, wurde behoben.

Betroffene APIs

Nicht über API-Analyse erkennbar.

Verbesserte Leistung in der Automatisierungsstruktur für die Gruppierung von ItemsControls

Details

Die Leistung beim Neuerstellen der Automatisierungsstruktur einer ItemsControl, wie ListBox oder DataGrid, bei aktivierter Gruppierung wurde verbessert.

Betroffene APIs

Nicht über API-Analyse erkennbar.

.NET Framework 4.8.1

In .NET Framework 4.8.1 wurden keine App-Kompatibilitätsprobleme eingeführt.