Freigeben über

Neuzuweisungsänderungen für die Migration zu .NET Framework 4.7.x

  • Artikel

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

.NET Framework 4.7

ASP.NET

HttpRuntime.AppDomainAppPath löst NullReferenceException aus

Details

In .NET Framework 4.6.2 löst die Laufzeit T:System.NullReferenceException aus, wenn ein P:System.Web.HttpRuntime.AppDomainAppPath-Wert abgerufen wird, der NULL-Zeichen enthält. In .NET Framework 4.6.1 und früheren Versionen löst die Laufzeit eine T:System.ArgumentNullException aus.

Vorschlag

Sie können mit einer der folgenden Möglichkeiten auf diese Änderung reagieren:

  • Behandeln Sie die T:System.NullReferenceException, wenn Ihre Anwendung in .NET Framework 4.6.2 ausgeführt wird.
  • Führen Sie ein Upgrade auf .NET Framework 4.7 durch, sodass das vorherige Verhalten wiederhergestellt und eine T:System.ArgumentNullException ausgelöst wird.
name Wert
Bereich Microsoft Edge
Version 4.6.2
Typ Neuzuweisung

Betroffene APIs

Einschränken von gleichzeitigen Anforderungen pro Sitzung

Details

In .NET Framework 4.6.2 und früheren Versionen führt ASP.NET Anforderungen mit der gleichen SessionID sequentiell durch, und ASP.NET stellt die SessionID standardmäßig über Cookies aus. Wenn eine Seite zum Reagieren viel Zeit in Anspruch nimmt, wird die Serverleistung allein durch Drücken von F5 im Browser erheblich eingeschränkt. Mit der Fehlerbehebung verfolgt ein Zähler die in die Warteschlange eingestellten Anforderungen nach und beendet die Anforderungen, wenn sie einen angegebenen Grenzwert überschreiten. Der Standardwert ist 50. Wenn der Grenzwert erreicht wird, wird eine Warnung in das Ereignisprotokoll geschrieben, und möglicherweise wird eine HTTP 500-Antwort im IIS-Protokoll aufgezeichnet.

Vorschlag

Um das alte Verhalten wiederherzustellen, können Sie Ihrer web.config-Datei die folgende Einstellung hinzufügen, um sich gegen das neue Verhalten zu entscheiden.

<appSettings>
    <add key="aspnet:RequestQueueLimitPerSession" value="2147483647"/>
</appSettings>
name Wert
Bereich Microsoft Edge
Version 4.7
Typ Neuzuweisung

Netzwerk

Der Standardwert von ServicePointManager.SecurityProtocol ist SecurityProtocolType.System.Default

Details

Bei Apps mit der Zielplattform .NET Framework 4.7 und höher ist der Standardwert der ServicePointManager.SecurityProtocol-Eigenschaft SecurityProtocolType.SystemDefault. Diese Änderungen ermöglicht den Netzwerk-APIs von .NET Framework, die auf SslStream (z.B. FTP, HTTPS und SMTP) basieren, die Standardsicherheitsprotokolle des Betriebssystems zu erben, anstatt hartcodierte Werte zu verwenden, die von .NET Framework definiert werden. Der Standard variiert je nach Betriebssystem und sämtlichen benutzerdefinierten Konfigurationen, die vom Systemadministrator vorgenommen werden. Informationen zum standardmäßigen SChannel-Protokoll in der jeweiligen Version des Windows-Betriebssystems finden Sie unter Protokolle in TLS/SSL (SChannel SSP).

Bei Anwendungen, die auf eine frühere Version des .NET-Frameworks ausgelegt sind, hängt der Standardwert der ServicePointManager.SecurityProtocol-Eigenschaft von der .NET Framework-Zielversion ab. Weitere Informationen finden Sie im Abschnitt „Netzwerk“ des Artikels „Neuzuweisung von Änderungen für die Migration von .NET Framework 4.5.2 zu 4.6“.

Vorschlag

Diese Änderung betrifft nur Anwendungen, die auf .NET Framework 4.7 oder höher ausgelegt sind. Wenn Sie lieber ein definiertes Protokoll anstelle des Systemstandards verwenden möchten, können Sie den Wert der ServicePointManager.SecurityProtocol-Eigenschaft explizit festlegen. Wenn diese Änderung nicht erwünscht ist, können Sie sich dagegen entscheiden, indem Sie dem Abschnitt <runtime> Ihrer Anwendungskonfigurationsdatei eine Konfigurationseinstellung hinzufügen. Im folgenden Beispiel sind sowohl der Abschnitt <runtime> als auch die Ablehnungsoption Switch.System.Net.DontEnableSystemDefaultTlsVersions dargestellt:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=true" />
</runtime>
name Wert
Bereich Gering
Version 4.7
Typ Neuzuweisung

Betroffene APIs

SslStream unterstützt TLS-Warnungen

Details

Nach einem fehlgeschlagenen TLS-Handshake wird eine System.IO.IOException mit einer inneren System.ComponentModel.Win32Exception von dem ersten E/A-Lese-/Schreibvorgang ausgelöst. Der System.ComponentModel.Win32Exception.NativeErrorCode-Code für die System.ComponentModel.Win32Exception kann der TLS-Warnung von der Remotepartei mit den Schannel-Fehlercodes für TLS- und SSL-Warnungen zugeordnet werden. Weitere Informationen finden Sie unter RFC 2246: Abschnitt 7.2.2, Fehlerwarnungen.
Das Verhalten in .NET Framework 4.6.2 und früheren Versionen besteht darin, dass für den Transportkanal (in der Regel eine TCP-Verbindung) ein Timeout während des Schreib- oder Lesevorgangs auftritt, wenn beim Handshake bei der anderen Partei ein Fehler aufgetreten ist und die Verbindung unmittelbar danach zurückgewiesen wurde.

Vorschlag

Anwendungen, die Netzwerk-E/A-APIs aufrufen (z.B. Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32)) sollten IOException oder System.TimeoutException verarbeiten.
Die TLS-Warnfunktion ist ab .NET Framework 4.7 standardmäßig aktiviert. Für Anwendungen für Versionen von .NET Framework von 4.0 bis 4.6.2, die auf einem System mit .NET Framework 4.7 oder höher ausgeführt werden, ist diese Funktion deaktiviert, um die Kompatibilität zu erhalten.
Die folgende Konfigurations-API ist zum Aktivieren oder Deaktivieren des Features für .NET Framework 4.6- oder höhere Anwendungen, die unter .NET Framework 4.7 oder höher ausgeführt werden, verfügbar.

  • Programmgesteuert: Die Verarbeitung muss direkt nach dem Anwendungsstart erfolgen, da ServicePointManager nur einmal initialisiert wird:

    AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true);

// Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2.
AppContext.SetSwitch("Switch.System.Net.DontEnableTlsAlerts", true);

  • AppConfig:

    <runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableTlsAlerts=true"/>
  <!-- Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. -->
</runtime>

  • Registrierungsschlüssel (globaler Wert für einen Computer): Legen Sie den Wert auf false fest, um das Feature in .NET Framework 4.6 bis 4.6.2 zu aktivieren.

    Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts
- Type: String
- Value: "true"
Name Wert
Bereich Microsoft Edge
Version 4.7
Typ Neuzuweisung

Betroffene APIs

Sicherheit

CspParameters.ParentWindowHandle erwartet nun einen HWND-Wert

Details

Der ParentWindowHandle-Wert, der in .NET Framework 2.0 eingeführt wurde, ermöglicht einer Anwendung die Registrierung eines Handlewerts für das übergeordnete Fenster, sodass jedes Benutzeroberflächenelement, das auf den Schlüssel zugreifen muss (wie etwa eine PIN-Eingabeaufforderung oder ein Zustimmungsdialogfeld), als untergeordnetes modales Fenster des angegebenen Fensters geöffnet wird. Für eine Windows Forms-App, deren Zielplattform .NET Framework 4.7 oder höher ist, kann die Eigenschaft ParentWindowHandle beispielsweise mit dem folgenden Code festgelegt werden:

cspParameters.ParentWindowHandle = form.Handle;

In früheren Versionen von .NET Framework wurde erwartet, dass der Wert ein System.IntPtr-Objekt ist, das einen Speicherort im Arbeitsspeicher darstellt, an dem sich der HWND-Wert befindet. Das Festlegen der Eigenschaft auf „form.Handle“ hatte unter Windows 7 und früheren Versionen keine Auswirkungen, unter Windows 8 und höheren Versionen resultiert dies jedoch in der Fehlermeldung „System.Security.Cryptography.CryptographicException: Der Parameter ist falsch.“

Vorschlag

Für Apps mit der Zielplattform .NET Framework 4.7 oder höher, die eine übergeordnete Fensterbeziehung registrieren sollen, wird die Verwendung eines vereinfachten Formulars wie dem folgenden empfohlen:

cspParameters.ParentWindowHandle = form.Handle;

Einige Benutzer haben erkannt, dass der richtige zu übergebende Wert die Adresse eines Speicherorts im Arbeitsspeicher war, der den Wert form.Handle enthielt. Benutzer können sich gegen dieses geänderte Verhalten entscheiden, indem sie die AppContext-Option Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle auf true festlegen. Dies kann

  • durch programmgesteuertes Festlegen von Kompatibilitätsoptionen für AppContext, wie hier beschrieben wird,
  • Durch Hinzufügen der folgenden Zeile zum Abschnitt <runtime> der app.config-Datei:
<runtime>
 <AppContextSwitchOverrides value="Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle=true"/>
</runtime>

Benutzer, die sich umgekehrt für das neue Verhalten der Laufzeit von .NET Framework 4.7 entscheiden, können die AppContext-Option auf false festlegen, wenn die Anwendung in älteren Versionen von .NET Framework geladen wird.

name Wert
Bereich Gering
Version 4.7
Typ Neuzuweisung

Betroffene APIs

SslStream unterstützt TLS-Warnungen

Details

Nach einem fehlgeschlagenen TLS-Handshake wird eine System.IO.IOException mit einer inneren System.ComponentModel.Win32Exception von dem ersten E/A-Lese-/Schreibvorgang ausgelöst. Der System.ComponentModel.Win32Exception.NativeErrorCode-Code für die System.ComponentModel.Win32Exception kann der TLS-Warnung von der Remotepartei mit den Schannel-Fehlercodes für TLS- und SSL-Warnungen zugeordnet werden. Weitere Informationen finden Sie unter RFC 2246: Abschnitt 7.2.2, Fehlerwarnungen.
Das Verhalten in .NET Framework 4.6.2 und früheren Versionen besteht darin, dass für den Transportkanal (in der Regel eine TCP-Verbindung) ein Timeout während des Schreib- oder Lesevorgangs auftritt, wenn beim Handshake bei der anderen Partei ein Fehler aufgetreten ist und die Verbindung unmittelbar danach zurückgewiesen wurde.

Vorschlag

Anwendungen, die Netzwerk-E/A-APIs aufrufen (z.B. Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32)) sollten IOException oder System.TimeoutException verarbeiten.
Die TLS-Warnfunktion ist ab .NET Framework 4.7 standardmäßig aktiviert. Für Anwendungen für Versionen von .NET Framework von 4.0 bis 4.6.2, die auf einem System mit .NET Framework 4.7 oder höher ausgeführt werden, ist diese Funktion deaktiviert, um die Kompatibilität zu erhalten.
Die folgende Konfigurations-API ist zum Aktivieren oder Deaktivieren des Features für .NET Framework 4.6- oder höhere Anwendungen, die unter .NET Framework 4.7 oder höher ausgeführt werden, verfügbar.

  • Programmgesteuert: Die Verarbeitung muss direkt nach dem Anwendungsstart erfolgen, da ServicePointManager nur einmal initialisiert wird:

    AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true);

// Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2.
AppContext.SetSwitch("Switch.System.Net.DontEnableTlsAlerts", true);

  • AppConfig:

    <runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableTlsAlerts=true"/>
  <!-- Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. -->
</runtime>

  • Registrierungsschlüssel (globaler Wert für einen Computer): Legen Sie den Wert auf false fest, um das Feature in .NET Framework 4.6 bis 4.6.2 zu aktivieren.

    Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts
- Type: String
- Value: "true"
Name Wert
Bereich Microsoft Edge
Version 4.7
Typ Neuzuweisung

Betroffene APIs

Windows Communication Foundation (WCF)

Die Serialisierung von Steuerzeichen in DataContractJsonSerializer ist jetzt konform mit ECMAScript V6 und V8

Details

In .NET Framework 4.6.2 und früheren Versionen serialisierte System.Runtime.Serialization.Json.DataContractJsonSerializer einige besondere Steuerzeichen, wie etwa \b, \f und \t nicht in einer Weise, die mit den Standards ECMAScript V6 und V8 kompatibel ist. Ab .NET Framework 4.7 ist die Serialisierung dieser Steuerzeichen mit ECMAScript V6 und V8 kompatibel.

Vorschlag

Standardmäßig wird dieses neue Feature nur für Apps aktiviert, die für .NET Framework 4.7 konzipiert sind. Wenn dieses Verhalten unerwünscht ist, können Sie sich gegen diese Funktion entscheiden, indem Sie dem Abschnitt <runtime> der app.config- oder web.config-Datei die folgende Zeile hinzufügen:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseECMAScriptV6EscapeControlCharacter=false" />
</runtime>
name Wert
Bereich Microsoft Edge
Version 4.7
Typ Neuzuweisung

Betroffene APIs

WCF-Nachrichtensicherheit kann jetzt TLS1.1 und TLS1.2 verwenden

Details

Ab .NET Framework 4.7 können Kunden über die Anwendungskonfigurationseinstellungen neben SSL3.0 und TLS1.0 entweder TLS1.1 oder TLS1.2 in WCF-Nachrichtensicherheit konfigurieren.

Vorschlag

In .NET Framework 4.7 werden TLS1.1 und TLS1.2 in WCF-Nachrichtensicherheit standardmäßig nicht unterstützt. Sie können die Unterstützung aktivieren, indem Sie die folgende Zeile zum Abschnitt <runtime> der app.config- oder der web.config-Datei hinzufügen:

<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>
name Wert
Bereich Microsoft Edge
Version 4.7
Typ Neuzuweisung

Windows Presentation Foundation (WPF)

Aufrufe von System.Windows.Input.PenContext.Disable auf touchfähigen Systemen können eine ArgumentException auslösen

Details

Unter bestimmten Umständen können Aufrufe der internen Methode System.Windows.Intput.PenContext.Disable auf touchfähigen Systemen eine nicht behandelte T:System.ArgumentException aufgrund von Eintrittsinvarianz auslösen.

Vorschlag

Dieses Problem wurde in .NET Framework 4.7 behoben. Führen Sie ein Upgrade auf .NET Framework 4.7 oder höher aus, um diese Ausnahme zu vermeiden.

name Wert
Bereich Microsoft Edge
Version 4.6.1
Typ Neuzuweisung

NullReferenceException im Ausnahmebehandlungscode von ImageSourceConverter.ConvertFrom

Details

Ein Fehler im Ausnahmebehandlungscode für ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) löste einen inkorrekten System.NullReferenceException anstelle der beabsichtigten Ausnahme (System.IO.DirectoryNotFoundException oder System.IO.FileNotFoundException) aus. Diese Änderung korrigiert diesen Fehler, damit die Methode nun die richtige Ausnahme auslöst.

In der Standardeinstellung lösen Anwendungen mit dem Ziel .NET Framework 4.6.2 und früher der Kompatibilität wegen weiterhin System.NullReferenceException aus. Entwickler, die .NET Framework 4.7 und höher anzielen, sollten die richtigen Ausnahmen angezeigt bekommen.

Vorschlag

Entwickler, die wieder System.NullReferenceException erhalten möchten, wenn Sie .NET Framework 4.7 oder höher als Zielplattform verwenden, können der Datei „app.config“ ihrer Anwendung Folgendes hinzufügen oder die entsprechenden Angaben zusammenführen:

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Media.ImageSourceConverter.OverrideExceptionWithNullReferenceException=true"/>
</runtime>
</configuration>
name Wert
Bereich Microsoft Edge
Version 4.7
Typ Neuzuweisung

Betroffene APIs

Platzvergabe im Raster für -Spalten

Details

Ab .NET Framework 4.7 ersetzt WPF den Algorithmus, den Grid verwendet, um Platz für *-Spalten zuzuweisen. Dadurch wird die den *-Spalten zugewiesene tatsächliche Breite geändert,

  • Wenn eine oder mehrere *-Spalten außerdem eine Minimal- oder Maximalbreite aufweisen, die die proportionale Zuweisung für die betreffende Spalte außer Kraft setzt. (Die minimale Breite kann aus einer expliziten MinWidth-Deklaration oder von einem impliziten Mindestwert abgeleitet werden, der aus dem Inhalt der Spalte abgerufen wird. Die maximale Breite kann nur explizit aus einer MaxWidth-Deklaration definiert werden.)
  • wenn mindestens eine *-Spalte eine extrem große *-Gewichtung deklarieren, die größer als 10^298 ist.
  • wenn die *-Gewichtungen ausreichend verschieden sind, um zu Gleitkommainstabilität zu führen (Überlauf, Unterlauf, Genauigkeitsverlust).
  • Wenn Layoutglättung aktiviert ist und der effektive DPI-Wert der Anzeige ausreichend hoch ist. In den beiden ersten Fällen können sich die vom neuen Algorithmus erzeugten Breiten erheblich von den durch den alten Algorithmus erzeugten unterscheiden; im letzten Fall beträgt der Unterschied höchstens ein oder zwei Pixel.

Der neue Algorithmus behebt mehrere Probleme, die beim alten Algorithmus auftreten:

  • Die Gesamtzuweisung an Spalten kann die Breite des Rasters überschreiten. Dies kann beim Zuweisen von Platz an eine Spalte geschehen, deren proportionaler Anteil geringer als ihre Mindestgröße ist. Der Algorithmus weist die Mindestgröße zu, wodurch der für andere Spalten verfügbare Platz verringert wird. Wenn keine zuzuweisenden *-Spalten mehr vorhanden sind, ist die Gesamtzuweisung zu groß.

  • Die Gesamtzuweisung kann die Breite des Rasters unterschreiten. Dieses Problem steht im Gegensatz zu Nr. 1 und entsteht, wenn eine Spalte zugewiesen wird, deren proportionaler Anteil größer als ihre Maximalgröße ist, wenn keine *-Spalten zum Ausgleich des Über- oder Untermaßes vorhanden sind.

  • Zwei *-Spalten können Zuweisungen erhalten, die nicht proportional zu ihren *-Gewichtungen sind. Dies ist eine mildere Version von Nr. 1/Nr. 2, die beim Zuweisen zu den *-Spalten A, B und C (in dieser Reihenfolge) auftritt, wobei der proportionale Anteil von B gegen deren Min- oder Max-Bedingung verstößt. Wie oben ändert sich dadurch der für Spalte C zur Verfügung stehende Platz, die proportional eine kleinere (oder größeren) Zuweisung als A erhält.

  • Spalten mit extrem hohen Gewichtungen (> 10^298) werden alle behandelt, als würden sie die Gewichtung 10^298 aufweisen. Proportionale Unterschiede zwischen ihnen (und zwischen Spalten mit erheblich kleineren Gewichtungen) werden nicht berücksichtigt.

  • Spalten mit der Gewichtung unendlich werden nicht ordnungsgemäß behandelt. (Tatsächlich lässt sich die Gewichtung nicht auf unendlich festlegen, aber das ist eine künstliche Einschränkung. Der Zuweisungscode hat versucht, das Problem zu bewältigen, dabei aber versagt.)

  • Mehrere kleinere Probleme beim Vermeiden von Überlauf, Unterlauf, Genauigkeitsverlust und ähnlichen Gleitkommaproblemen.

  • Anpassungen für Layoutglättung sind bei ausreichend hohem DPI fehlerhaft. Der neue Algorithmus erzeugt Ergebnisse, die den folgenden Kriterien genügen:

    • Die einer *-Spalte zugewiesene Breite ist niemals kleiner als ihre Mindestbreite oder größer als ihre Maximalbreite.
    • Jede *-Spalte, der nicht ihre Mindest- oder Maximalbreite zugewiesen wird, wird eine Breite zugewiesen, die proportional zu ihrer *-Gewichtung ist. Genauer gesagt: Wenn zwei Spalten die Breite x* bzw. y* zugewiesen wird und keine der beiden Spalten ihre Minimal- oder Maximalbreite erhält, stehen die den Spalten zugewiesenen tatsächlichen Breiten v und w im gleichen Verhältnis: v/w == x/y.
    • Die Gesamtbreite, die den „proportionalen“ *-Spalten zugewiesen wird, entspricht dem verfügbaren Platz nach der Zuweisung an die Spalten, die Bedingungen unterliegen (feste Spalten, Spalten mit automatischer Breite und *-Spalten, denen die minimale oder maximale Breite zugewiesen wird). Diese kann Null sein, beispielsweise, wenn die Summe der Mindestbreiten die zur Verfügung stehende Breite des Rasters überschreitet.
    • Alle diese Anweisungen müssen im Hinblick auf das „ideale“ Layout interpretiert werden. Wenn Layoutglättung aktiviert ist, können die tatsächlichen Breiten um bis zu ein Pixel von den idealen Breiten abweichen.

Hinweis

Alle Aussagen über Spalten und Breiten in diesem Artikel gelten ebenso für Zeilen und Höhen.

Vorschlag

Standardmäßig verwenden Apps mit einer .NET Framework-Zielplattform ab .NET Framework 4.7 den neuen Algorithmus, während Apps mit der Zielplattform .NET Framework 4.6.2 oder früher den alten Algorithmus verwenden.

Um die Standardeinstellung außer Kraft zu setzen, verwenden Sie die folgenden Konfigurationseinstellung:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>

Der Wert true legt den alten Algorithmus fest, false den neuen.

name Wert
Bereich Gering
Version 4.7
Typ Neuzuweisung

Zeigerbasierte Touch-Stapel in WPF

Details

Diese Änderung ermöglicht das Aktivieren eines optionalen WM_POINTER-basierten WPF-Touch-/Stift-Stapels. Entwickler, die diesen Stapel nicht explizit aktivieren, sollten keine Änderung im WPF-Touch/Stift-Verhalten feststellen. Folgende Probleme sind mit dem optionalen WM_POINTER-basierten Touch-/Stift-Stapel bekannt:

  • Keine Unterstützung für Freihand in Echtzeit.
  • Zwar funktionieren Freihand- und Stift-Plug-Ins nach wie vor, jedoch werden sie im Benutzeroberflächenthread verarbeitet, was zu schlechter Leistung führen kann.
  • Verhaltensänderungen aufgrund der Verlagerung von Touch/Stift-Ereignissen zu Mausereignissen.
  • Die Bearbeitung verhält sich möglicherweise anders.
  • Drag/Drop zeigt keine angemessene Rückmeldung bei Toucheingaben.
  • Dies betrifft keine Stifteingaben.
  • Drag/Drop kann für Touch/Stift-Ereignisse nicht mehr ausgelöst werden.
  • Dadurch kann es vorkommen, dass die Anwendung nicht mehr reagiert, bis die Mauseingabe erkannt wird.
  • Stattdessen sollten Entwickler Drag & Drop über Mausereignisse einleiten.

Vorschlag

Entwickler, die diesen Stapel aktivieren möchten, können der Datei „app.config“ ihrer Anwendung Folgendes hinzufügen:

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Input.Stylus.EnablePointerSupport=true"/>
</runtime>
</configuration>

Entfernen oder Festlegen des Werts auf FALSE deaktiviert diesen optionalen Stapel. Beachten Sie, dass dieser Stapel nur unter Windows 10 Creators Update und höher verfügbar ist.

name Wert
Bereich Microsoft Edge
Version 4.7
Typ Neuzuweisung

Windows Workflow Foundation (WF)

Änderung der Workflowprüfsummen von MD5 in SHA1

Details

Die Workflowlaufzeit generiert unter Verwendung eines Hashalgorithmus zur Unterstützung des Debuggens mit Visual Studio eine Prüfsumme für eine Workflowinstanz. In .NET Framework 4.6.2 und früheren Versionen wird beim Hashing der Workflowprüfsumme der MD5-Algorithmus verwendet, der auf Systemen, auf den FIPS aktiviert ist, Probleme verursacht hat. Ab .NET Framework 4.7 wird der SHA1-Algorithmus verwendet. Wenn Ihr Code diese Prüfsummen dauerhaft gespeichert hat, sind diese nicht kompatibel.

Vorschlag

Wenn Ihr Code aufgrund eines Prüfsummenfehlers keine Workflowinstanzen laden kann, versuchen Sie, die AppContext-Option „Switch.System.Activities.UseMD5ForWFDebugger“ auf „true“ festzulegen. Im Code sieht das wie folgt aus:

System.AppContext.SetSwitch("Switch.System.Activities.UseMD5ForWFDebugger", true);

Stattdessen können Sie dies auch im Rahmen der Konfiguration vornehmen:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Activities.UseMD5ForWFDebugger=true" />
  </runtime>
</configuration>
name Wert
Bereich Gering
Version 4.7
Typ Neuzuweisung

.NET Framework 4.7.1

ASP.NET

Verbesserungen der Barrierefreiheit von ASP.NET in .NET Framework 4.7.1

Details

Ab .NET Framework 4.7.1 arbeiten .ASP.NET-Websteuerelemente effizienter mit den Funktionen für die Barrierefreiheit in Visual Studio zusammen, wodurch ASP.NET-Kunden besser unterstützt werden. Folgende Änderungen wurden u.a. vorgenommen:

  • Änderungen, durch die fehlende Barrierefreiheitsmuster für Steuerelemente der Benutzeroberfläche implementiert werden. Zu diesen Steuerelementen zählen z.B. das Dialogfeld „Feld hinzufügen“ im Detailansicht-Assistenten oder das Dialogfeld „ListView konfigurieren“ im ListView-Assistenten.
  • Änderungen zur Verbesserung der Anzeige im Modus für hohe Kontraste, z.B. beim DataPager-Feld-Editor.
  • Änderungen zur Verbesserung der Benutzerfreundlichkeit bei der Tastaturnavigation für Steuerelemente, z.B. beim Dialogfeld „Felder“ im Assistenten für das Bearbeiten von Pagerfeldern des DataPager-Steuerelements, beim Dialogfeld „ObjectContext konfigurieren“ oder beim Dialogfeld „Datenauswahl konfigurieren“ des Assistenten zum Konfigurieren der Datenquelle.

Vorschlag

Aktivieren oder Deaktivieren dieser Änderungen: Damit diese Änderungen in Visual Studio Designer eingesetzt werden können, muss das Tool unter .NET Framework 4.7.1 oder höher ausgeführt werden. Die Webanwendung kann diese Änderungen nutzen, wenn Sie folgende Schritte durchführen:

  • Installieren Sie Visual Studio 2017 15.3 oder höher. Ab dieser Version werden die neuen Barrierefreiheitsfeatures mit der unten aufgeführten AppContext-Option standardmäßig unterstützt.
  • Deaktivieren Sie die Legacy-Barrierefreiheitsverhalten, indem Sie in der Konfigurationsdatei „devenv.exe“ dem Abschnitt <runtime> die AppContext-Option Switch.UseLegacyAccessibilityFeatures hinzufügen und sie auf false festlegen, wie im folgenden Beispiel dargestellt wird.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
...
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false'  -->
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
...
</runtime>
</configuration>

Bei Anwendungen, die .NET Framework 4.7.1 oder höher als Zielplattform verwenden und die Legacy-Barrierefreiheitsverhalten beibehalten sollen, können Sie die Verwendung des veralteten Features für die Barrierefreiheit aktivieren, indem Sie die AppContext-Option auf true festlegen.

name Wert
Bereich Gering
Version 4.7.1
Typ Neuzuweisung

Core

Ausnahmen in SerialPort-Hintergrundthreads

Details

Mit SerialPort-Streams erstellte Hintergrundthreads beenden den Prozess nicht mehr, wenn Betriebssystemausnahmen ausgelöst werden.
In Anwendungen, die auf .NET Framework 4.7 und frühere Versionen ausgelegt sind, wird ein Prozess beendet, wenn eine Betriebssystemausnahme in einem Hintergrundthread ausgelöst wird, der mit einem SerialPort-Stream erstellt wurde.
In Anwendungen, die auf .NET Framework 4.7.1 oder eine höhere Version ausgelegt sind, warten Hintergrundthreads auf Betriebssystemereignisse im Zusammenhang mit der aktiven seriellen Schnittstelle und können in einigen Fällen abstürzen, z. B. beim plötzlichen Entfernen der seriellen Schnittstelle.

Vorschlag

Für Apps mit der Zielplattform .NET Framework 4.7.1 können Sie sich gegen die Ausnahmebehandlung entscheiden, wenn sie nicht erwünscht ist, indem Sie Folgendes dem Abschnitt <runtime> Ihrer app.config-Datei hinzufügen:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=true" />
</runtime>

Bei Anwendungen, die für frühere Versionen von .NET Framework vorgesehen sind, aber in .NET Framework 4.7.1 oder höher ausgeführt werden, können Sie die Ausnahmebehandlung verwenden, indem Sie Folgendes dem Abschnitt <runtime> der app.config-Datei hinzufügen:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=false" />
</runtime>
name Wert
Bereich Gering
Version 4.7.1
Typ Neuzuweisung

Betroffene APIs

ServiceBase überträgt OnStart-Ausnahmen nicht

Details

In .NET Framework 4.7 und früheren Versionen werden Ausnahmen, die beim Dienststart ausgelöst werden, nicht an den Aufrufer von ServiceBase.Run weitergegeben.

Beginnend mit Anwendungen, die auf .NET Framework 4.7.1 ausgelegt sind, gibt die Laufzeit Ausnahmen an ServiceBase.Run für Dienste weiter, die nicht gestartet werden können.

Vorschlag

Wenn beim Start des Diensts eine Ausnahme auftritt, wird diese Ausnahme weitergegeben. Dies sollte bei der Diagnose von Fällen helfen, in denen Dienste nicht starten können.

Wenn dieses Verhalten nicht erwünscht ist, können Sie sich dagegen entscheiden, indem Sie das folgende AppContextSwitchOverrides-Element dem Abschnitt runtime Ihrer Anwendungskonfigurationsdatei hinzufügen:

<AppContextSwitchOverrides value="Switch.System.ServiceProcess.DontThrowExceptionsOnStart=true" />

Wenn Ihre Anwendung auf eine frühere Version als 4.7.1 ausgerichtet ist und dieses Verhalten erforderlich ist, können Sie das folgende AppContextSwitchOverrides-Element dem Abschnitt runtime Ihrer Anwendungskonfigurationsdatei hinzufügen:

<AppContextSwitchOverrides value="Switch.System.ServiceProcess.DontThrowExceptionsOnStart=false" />
Name Wert
Bereich Gering
Version 4.7.1
Typ Neuzuweisung

Betroffene APIs

Sicherheit

Die Standardalgorithmen SignedXML und SignedXMS wurden in SHA-256 geändert

Details

In .NET Framework 4.7 und früheren Versionen verwenden SignedXML und SignedCMS für einige Vorgänge standardmäßig SHA-1. Ab .NET Framework 4.7.1 ist SHA-256 für diese Vorgänge standardmäßig aktiviert. Diese Änderung ist erforderlich, da SHA-1 nicht mehr sicher ist.

Vorschlag

Es gibt zwei neue Kontextwechselwerte, mit denen festgelegt wird, ob SHA-1 (unsicher) oder SHA-256 standardmäßig verwendet wird:

  • Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms
  • Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithmsBei Apps mit der Zielplattform .NET Framework 4.7.1 und höheren Versionen kann die Verwendung von SHA-1 als Standardoption wiederhergestellt werden, wenn die Verwendung von SHA-256 nicht erwünscht ist, indem die folgende Konfigurationsoption dem Abschnitt runtime Ihrer Anwendungskonfigurationsdatei hinzugefügt wird:
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=true;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=true" />

Bei Apps mit der Zielplattform .NET Framework 4.7 und früheren Versionen können Sie sich für diese Änderung entscheiden, indem Sie die folgende Konfigurationsoption dem Abschnitt runtime Ihrer Anwendungskonfigurationsdatei hinzufügen:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=false;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=false" />
name Wert
Bereich Gering
Version 4.7.1
Typ Neuzuweisung

Betroffene APIs

SignedXml.GetPublicKey gibt unter .NET Framework 4.6.2 RSACng (oder CngLightup) zurück, ohne Änderungen neu zuzuweisen

Details

Ab .NET Framework 4.6.2 wird für den konkreten Typ des Objekts, das von der SignedXml.GetPublicKey-Methode zurückgegeben wird, nicht mehr die CryptoServiceProvider-Implementierung, sondern eine Cng-Implementierung verwendet. Probleme sind durch diese Änderung nicht aufgetreten. Der Grund für die Änderung ist, dass für die Implementierung anstelle von certificate.PublicKey.Key nun die interne Methode certificate.GetAnyPublicKey verwendet wird, die eine Weiterleitung zu RSACertificateExtensions.GetRSAPublicKey vornimmt.

Vorschlag

Für Apps, die unter .NET Framework 4.7.1 oder einer neueren Version ausgeführt werden, können Sie die standardmäßig von .NET Framework 4.6.1 und früheren Versionen verwendete CryptoServiceProvider-Implementierung verwenden, indem Sie dem Abschnitt runtime Ihrer Anwendungskonfigurationsdatei die folgende Konfigurationsoption hinzufügen:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
name Wert
Bereich Microsoft Edge
Version 4.6.2
Typ Neuzuweisung

Betroffene APIs

Windows Communication Foundation (WCF)

Verbesserte Barrierefreiheit für einige .NET SDK-Tools

Details

Im .NET Framework SDK 4.7.1 wurden die Tools „SvcConfigEditor.exe“ und „SvcTraceViewer.exe“ verbessert, indem verschiedene Probleme mit der Barrierefreiheit behoben wurden. Bei den meisten handelte es sich um kleinere Probleme, durch die ein Name nicht definiert wurde oder bestimmte Muster für die Benutzeroberflächenautomatisierung nicht richtig implementiert wurden. Obwohl viele Benutzer diese falschen Werte nicht bemerken würden, erhöhen die SDK-Tools die Benutzerfreundlichkeit für Kunden, die Hilfstechnologien wie die Sprachausgabe verwenden. Diese Problembehebungen ändern vorherige Verhalten wie z.B. die Tastaturfokusreihenfolge. Sie können der Datei „app.config“ Folgendes hinzufügen, um alle Problembehebungen für die Barrierefreiheit in diesen Tools nutzen zu können:

<runtime>
  <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false"/>
</runtime>
name Wert
Bereich Microsoft Edge
Version 4.7.1
Typ Neuzuweisung

Windows Forms

Verbesserung der Barrierefreiheit von Windows Forms-Steuerelementen

Details

Die Arbeitsweise von Windows Forms mit Technologien für die Barrierefreiheit wird verbessert, um die Kunden von Windows Forms besser zu unterstützen. Dazu gehören die folgenden Änderungen ab .NET Framework 4.7.1:

  • Änderungen zum Verbessern der Anzeige während des Modus mit hohem Kontrast
  • Änderungen zum Verbessern der Benutzerfreundlichkeit des Eigenschaftenbrowsers Folgende Verbesserungen wurden am Eigenschaftenbrowser vorgenommen:
  • Eine verbesserte Tastaturnavigation durch die verschiedenen Fenster der Dropdownauswahl
  • Unnötige Tabstopps wurden reduziert.
  • Eine verbesserte Berichterstellung der Steuerelementtypen
  • Ein verbessertes Verhalten der Sprachausgabe
  • Änderungen an der Implementierung fehlender Barrierefreiheitsmuster für die Benutzeroberfläche in Steuerelementen

Vorschlag

Aktivieren oder Deaktivieren dieser Änderungen: Damit die Anwendung von diesen Änderungen profitieren kann, muss sie unter .NET Framework 4.7.1 oder höher ausgeführt werden. Die Anwendung kann von diesen Änderungen profitieren, wenn Sie Folgendes durchführen:

  • Kompilieren Sie diese erneut, um .NET Framework 4.7.1 anzuzielen. Diese Änderungen der Barrierefreiheit werden standardmäßig für WPF-Anwendungen aktiviert, die .NET Framework 4.7.1 oder höher anzielen.
  • Veraltete Verhaltensweisen der Barrierefreiheit werden deaktiviert, indem wie im folgenden Beispiel dargestellt folgendes AppContext-Element zum <runtime>-Abschnitt der app.config-Datei 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.UseLegacyAccessibilityFeatures=false" />
  </runtime>
</configuration>

Bei Anwendungen, die .NET Framework 4.7.1 oder höher als Zielplattform verwenden und die Legacy-Barrierefreiheitsverhalten beibehalten sollen, können Sie die Verwendung des veralteten Features für die Barrierefreiheit aktivieren, indem Sie die AppContext-Option auf true festlegen.

Einen Überblick über die Benutzeroberflächenautomatisierung finden Sie unter Benutzeroberflächenautomatisierung: Übersicht.

Hinzugefügte Unterstützung für Benutzeroberflächen-Automatisierungsmuster und -Eigenschaften

Barrierefreiheitsclients können neue WinForms-Barrierefreiheitsfunktionen nutzen, indem allgemeine, öffentlich beschriebene Aufrufmuster verwendet werden. Diese Muster sind nicht für WinForms spezifisch. Clients für die Barrierefreiheit können beispielsweise die QueryInterface-Methode der IAccessible-Schnittstelle (MAAS) aufrufen, um eine IServiceProvider-Schnittstelle abzurufen. Wenn diese Schnittstelle verfügbar ist, können Clients die QueryService-Methode verwenden, um eine IAccessibleEx-Schnittstelle anzufordern. Weitere Informationen finden Sie unter Using IAccessibleEx from a Client (Verwenden von IAccessibleEx über einen Client). Ab .NET Framework 4.7.1 sind IServiceProvider und IAccessibleEx gegebenenfalls für WinForms-Objekte für die Barrierefreiheit verfügbar.

.NET Framework 4.7.1 unterstützt jetzt folgende Muster und Eigenschaften für die Automatisierung der Benutzeroberfläche:

Verwendung von durch das Betriebssystem definierten Farben in Designs mit hohem Kontrast

  • Die Button- und CheckBox-Steuerelementen, deren FlatStyle-Eigenschaft auf FlatStyle.System (Standardformat) festgelegt ist, verwenden nun die vom Betriebssystem definierten Farben im Design mit hohem Kontrast, wenn dieses ausgewählt ist. Zuvor gab es keinen Kontrast zwischen Text und Hintergrundfarbe, wodurch der Text schwer lesbar war.
  • Die Button-, CheckBox-, RadioButton-, Label-, LinkLabel- und GroupBox-Steuerelemente, deren Enabled-Eigenschaft auf FALSE festgelegt ist, verwendeten schattierte Farben zum Rendern von Text in Designs mit hohem Kontrast. Dies führt zu geringem Kontrast vor dem Hintergrund. Diese Steuerelemente verwenden jetzt die vom Betriebssystem definierte Farbe für deaktivierten Text. Diese Fehlerbehebung gilt für Steuerelemente, bei denen die FlatStyle-Eigenschaft auf einen anderen Wert als FlatStyle.System festgelegt ist. Die zuletzt aufgeführten Steuerelemente werden vom Betriebssystem gerendert.
  • DataGridView rendert nun ein sichtbares Rechteck um den Inhalt der Zelle, die derzeit fokussiert wird. Zuvor wurde dieses in bestimmten Designs mit hohem Kontrast nicht angezeigt.
  • ToolStripMenuItem-Steuerelemente, deren Enabled-Eigenschaft auf false festgelegt ist, verwenden jetzt die vom Betriebssystem definierte Farbe für deaktivierten Text.
  • ToolStripMenuItem-Steuerelemente, deren Checked-Eigenschaft auf TRUE festgelegt ist, rendern nun das zugehörige Häkchen in einer kontrastreichen Systemfarbe. Zuvor war die Farbe des Häkchens nicht kontrastreich genug, weshalb es in Designs mit hohem Kontrast nicht sichtbar war. HINWEIS: In Windows 10 wurden die Werte für einige Systemfarben mit hohem Kontrast geändert. Das Windows Forms-Framework basiert auf dem Win32-Framework. Die besten Ergebnisse erhalten Sie, wenn Sie die aktuelle Version von Windows ausführen und die neuesten Änderungen am Betriebssystem aktivieren, indem Sie eine app.manifest-Datei zu einer Testanwendung hinzufügen und den Kommentar aus folgendem Code entfernen:
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

Verbesserte Tastaturnavigation

  • Wenn für ein ComboBox-Steuerelement seine DropDownStyle-Eigenschaft auf ComboBoxStyle.DropDownList festgelegt ist und es das erste Steuerelement in der Aktivierreihenfolge des Formulars ist, zeigt dieses nun ein Fokusrechteck an, wenn das übergeordnete Formular mithilfe der Tastatur geöffnet wird. Vor dieser Änderung lag der Tastaturfokus auf diesem Steuerelement, es wurde jedoch kein Fokusindikator gerendert.

Verbesserte Unterstützung für die Sprachausgabe

  • Dem MonthCalendar-Steuerelement wurde die Unterstützung für Hilfstechnologien hinzugefügt, damit diese auf das Steuerelement zugreifen können. Dazu zählt auch die Funktion der Microsoft-Sprachausgabe, den Wert des Steuerelements auszugeben. Dies war zuvor nicht möglich.

  • Das CheckedListBox-Steuerelement benachrichtigt die Sprachausgabe nun, wenn eine CheckBox.CheckState-Eigenschaft geändert wurde. Zuvor erhielt die Sprachausgabe keine Benachrichtigung. Deshalb wurden Benutzer nicht darüber informiert, dass die CheckState-Eigenschaft aktualisiert wurde.

  • Die Art, wie das LinkLabel-Steuerelement die Microsoft-Sprachausgabe über den Text des Steuerelements benachrichtigt, wurde geändert. Zuvor hat die Sprachausgabe diesen Text zweimal ausgegeben und die „&“-Symbole als Text gelesen, obwohl diese für Benutzer*innen nicht sichtbar sind. Der doppelten Text sowie die unnötigen „&“-Symbole wurden aus den Ausgaben der Sprachausgabe entfernt.

  • Die DataGridViewCell-Steuerelementtypen melden den schreibgeschützten Status nun ordnungsgemäß an die Microsoft-Sprachausgabe und andere Hilfstechnologien.

  • Die Sprachausgabe kann jetzt das Systemmenü untergeordneter Fenster in [Multiple-Document Interface]~/docs/framework/winforms/advanced/multiple-document-interface-mdi-applications.md)-Anwendungen lesen.

  • Die Microsoft-Sprachausgabe kann nun ToolStripMenuItem-Steuerelemente ausgeben, bei der die ToolStripItem.Enabled-Eigenschaft auf FALSE festgelegt ist. Zuvor konnte die Sprachausgabe den Fokus nicht auf deaktivierte Menüelemente verschieben, um deren Inhalt auszugeben.

name Wert
Bereich Hauptversion
Version 4.8
Typ Neuzuweisung

Betroffene APIs

Windows Presentation Foundation (WPF)

Verbesserungen der Barrierefreiheit in WPF

Details

Verbesserungen beim hohen Kontrast

  • Der Fokus für das Expander-Steuerelement wird nun angezeigt. In früheren Versionen des .NET Framework war dies nicht der Fall.
  • Der Text, der in den CheckBox- und RadioButton-Steuerelementen angezeigt wird, wenn diese ausgewählt sind, ist nun einfacher erkennbar als in den vorherigen Versionen von .NET Framework.
  • Der Rahmen eines deaktivierten ComboBox-Elements hat nun die gleiche Farbe wie der deaktivierte Text. In früheren Versionen des .NET Framework war dies nicht der Fall.
  • Deaktivierte Schaltflächen und Schaltflächen mit Fokus verwenden nun das richtige Farbdesign. In früheren Versionen des .NET Framework war dies nicht der Fall.
  • Die Dropdownschaltfläche ist nun sichtbar, wenn der Stil eines ComboBox-Steuerelements auf ToolBar.ComboBoxStyleKey festgelegt ist. In früheren Versionen des .NET Framework war dies nicht der Fall.
  • Der Pfeil für die Sortieranzeige in einem DataGrid-Steuerelement verwendet nun die Farben des Designs. In früheren Versionen des .NET Framework war dies nicht der Fall.
  • Das Standardformat für Links ändert sich nun in das richtige Farbdesign, wenn mit der Maus darauf gezeigt wird. In früheren Versionen des .NET Framework war dies nicht der Fall.
  • Es wird nun angezeigt, wenn der Tastaturfokus sich auf Optionsfeldern befindet. In früheren Versionen des .NET Framework war dies nicht der Fall.
  • Die Spalte für Kontrollkästchen des DataGrid-Steuerelements verwendet nun die erwarteten Farben für das Feedback des Tastaturfokus. In früheren Versionen des .NET Framework war dies nicht der Fall.
  • Die visuellen Elemente des Tastaturfokus werden nun für ComboBox- und ListBox-Steuerelemente angezeigt. In früheren Versionen des .NET Framework war dies nicht der Fall.

Verbesserungen der Interaktion mit der Sprachausgabe

  • Expander-Steuerelemente werden von der Sprachausgabe nun richtig als Gruppen (erweitern/reduzieren) ausgegeben.
  • DataGridCell-Steuerelemente werden von der Sprachausgabe nun richtig als Datenrasterzellen (lokalisiert) ausgegeben.
  • Die Sprachausgabe gibt nun den Namen eines bearbeitbaren ComboBox-Elements aus.
  • PasswordBox-Steuerelemente werden von der Sprachausgabe nicht mehr als „Es befindet sich kein Element in der Ansicht“ ausgegeben.

LiveRegion-Unterstützung

Sprachausgaben wie das Feature „Sprachausgabe“ helfen Benutzern, die Benutzeroberfläche einer Anwendung zu verstehen. In der Regel wird dazu das Benutzeroberflächenelement beschrieben, das gerade im Fokus ist. Wenn ein Element der Benutzeroberfläche sich jedoch an einer beliebigen Stelle des Bildschirms ändert und nicht fokussiert wird, wird der Benutzer möglicherweise nicht informiert und verpasst wichtige Informationen. LiveRegions wurden dafür entwickelt, dieses Problem zu lösen. Entwickler können diese verwenden, um der Sprachausgabe oder einem anderen Benutzeroberflächen-Automatisierungsclient mitzuteilen, dass eine wichtige Änderung an einem Element der Benutzeroberfläche vorgenommen wurde. Die Sprachausgabe kann dann entscheiden, wie und wann der Benutzer über diese Änderung informiert wird. Die LiveSetting-Eigenschaft sorgt ebenfalls dafür, dass die Sprachausgabe den Benutzer über Änderungen an der Benutzeroberfläche informiert.

Vorschlag

Aktivieren bzw. Deaktivieren dieser Änderungen

Damit die Anwendung von diesen Änderungen profitieren kann, muss sie unter .NET Framework 4.7.1 oder höher ausgeführt werden. Die Anwendung kann von diesen Änderungen profitieren, wenn Sie Folgendes durchführen:

  • Richten Sie die Anwendung auf .NET Framework-Version 4.7.1 aus. Dies ist die empfohlene Vorgehensweise. Diese Änderungen für mehr Barrierefreiheit werden automatisch für WPF-Anwendungen aktiviert, die für .NET Framework 4.7.1 oder höher entwickelt wurden.

  • Veraltete Verhaltensweisen der Barrierefreiheit werden deaktiviert, indem wie im folgenden Beispiel dargestellt folgender AppContext-Schalter im Abschnitt <runtime> der Datei „app.config“ 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.UseLegacyAccessibilityFeatures=false" />
  </runtime>
</configuration>

Bei Anwendungen, deren Zielplattform .NET Framework 4.7.1 oder höher ist und für die das Legacyverhalten für die Barrierefreiheit beibehalten sollen, können Sie das Legacyfeature für die Barrierefreiheit aktivieren, indem Sie die AppContext-Option auf true festlegen. Einen Überblick über die Benutzeroberflächenautomatisierung finden Sie unter Übersicht über die Benutzeroberflächenautomatisierung.

Name Wert
Bereich Hauptversion
Version 4.7.1
Typ Neuzuweisung

Betroffene APIs

Selector-Klasse – SelectionChanged-Ereignis und SelectedValue-Eigenschaft

Details

Ab .NET Framework 4.7.1 aktualisiert ein Selector-Objekt immer den Wert der zugehörigen SelectedValue-Eigenschaft, bevor das Ereignis SelectionChanged ausgelöst wird, wenn die Auswahl geändert wird. Dadurch wird die „SelectedValue“-Eigenschaft mit den anderen Auswahleigenschaften (SelectedItem und SelectedIndex) in Einklang gebracht, die vor dem Auslösen des Ereignisses aktualisiert werden.

In .NET Framework 4.7 und früheren Versionen wurde „SelectValue“ in den meisten Fällen vor der Auslösung des Ereignisses aktualisiert. Wenn die Änderung der Auswahl durch Ändern der SelectedValue-Eigenschaft ausgelöst wurde, fand die Aktualisierung jedoch nach dem Auslösen des Ereignisses statt.

Vorschlag

Für Apps mit der Zielplattform .NET Framework 4.7.1 oder höher kann diese Änderung deaktiviert und das Legacyverhalten verwendet werden, indem Sie dem Abschnitt <runtime> der Anwendungskonfigurationsdatei Folgendes hinzufügen:

<runtime>
<AppContextSwitchOverrides
value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=true" />
</runtime>

Für Apps mit der Zielplattform .NET Framework 4.7 oder früheren Versionen, die unter .NET Framework 4.7.1 oder höher ausgeführt werden, kann das neue Verhalten aktiviert werden, indem Sie dem Abschnitt <runtime> der Anwendungskonfigurationsdatei die folgende Zeile hinzufügen:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
name Wert
Bereich Gering
Version 4.7.1
Typ Neuzuweisung

Betroffene APIs

SelectionChanged-Ereignis und SelectedContent-Eigenschaft von „TabControl“

Details

Ab .NET Framework 4.7.1 aktualisiert TabControl den Wert der SelectedContent-Eigenschaft, bevor das SelectionChanged-Ereignis ausgelöst wird, wenn die Auswahl geändert wird. In .NET Framework 4.7 und früher wurde das Update für „SelectedContent“ nach dem Ereignis durchgeführt.

Vorschlag

Für Apps mit der Zielplattform .NET Framework 4.7.1 oder höher kann diese Änderung deaktiviert und das Legacyverhalten verwendet werden, indem Sie dem Abschnitt <runtime> der Anwendungskonfigurationsdatei Folgendes hinzufügen:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=true" />
</runtime>

Für Apps mit der Zielplattform .NET Framework 4.7 oder früheren Versionen, die unter .NET Framework 4.7.1 oder höher ausgeführt werden, kann das neue Verhalten aktiviert werden, indem Sie dem Abschnitt <runtime> der Anwendungskonfigurationsdatei die folgende Zeile hinzufügen:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
name Wert
Bereich Gering
Version 4.7.1
Typ Neuzuweisung

Betroffene APIs

SHA256 ist jetzt der Standardhashalgorithmus für WPF-PackageDigitalSignatureManager

Details

Der System.IO.Packaging.PackageDigitalSignatureManager stellt Funktionen zur digitalen Signatur von WPF-Paketen zur Verfügung. In .NET Framework 4.7 und früheren Versionen, war SHA1 der Standardhashalgorithmus (PackageDigitalSignatureManager.DefaultHashAlgorithm), der zum Signieren von Paketbestandteilen verwendet wurde. Diese Standardeinstellung wurde ab .NET Framework 4.7.1 aufgrund von Sicherheitsbedenken im Zusammenhang mit SHA1 auf SHA256 geändert. Diese Änderung betrifft die Signierung aller Pakete, einschließlich XPS-Dokumenten.

Vorschlag

Ein Entwickler, der diese Änderung nutzen will, aber seine Anwendung auf eine ältere Version von .NET Framework als Version 4.7.1 auslegt, oder ein Entwickler, der die veraltete Funktion verwenden möchte, seine Anwendung jedoch auf .NET Framework 4.7.1 oder höher auslegt, können das „AppContext“-Flag entsprechend festlegen. Wenn ein TRUE-Wert zurückgegeben wird, wird SHA1 als Standardalgorithmus verwendet. Bei FALSE-Werten wird SHA256 zurückgegeben.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.UseSha1AsDefaultHashAlgorithmForDigitalSignatures=true"/>
</runtime>
</configuration>
name Wert
Bereich Microsoft Edge
Version 4.7.1
Typ Neuzuweisung

Betroffene APIs

Windows Workflow Foundation (WF)

Verbesserungen der Bedienungshilfen im Workflow-Designer von Windows Workflow Foundation (WF)

Details

Die Arbeitsweise von Workflow-Designer von Windows Workflow Foundation (WF) mit Technologien für die Barrierefreiheit wurde verbessert. Diese Verbesserungen umfassen folgende Änderungen:

  • Die Aktivierreihenfolge wurde bei manchen Steuerelementen in „ Von links nach rechts“ und in „Von oben nach unten“ geändert:
  • Das Fenster „Korrelation initialisieren“ für das Festlegen von Korrelationsdaten für die InitializeCorrelation-Aktivität
  • Das Fenster „Inhaltsdefinition“ für die Aktivitäten Receive, Send, SendReply und ReceiveReply
  • Weitere Funktionen sind über die Tastatur verfügbar:
  • Beim Bearbeiten der Eigenschaften einer Aktivität können die Eigenschaftengruppen über die Tastatur reduziert werden, wenn diese zum ersten Mal fokussiert werden.
  • Auf Warnsymbole kann nun über die Tastatur zugegriffen werden.
  • Auf die Schaltfläche „Weitere Eigenschaften“ im Fenster „Eigenschaften“ kann nun über die Tastatur zugegriffen werden.
  • Tastaturbenutzer können nun auf die Headerelemente in den Bereichen „Argumente“ und „Variablen“ des Workflow-Designers zugreifen.
  • Verbesserte Sichtbarkeit von Elementen mit Fokus, z.B. in folgenden Fällen:
  • Hinzufügen von Zeilen zu Datenrastern, die vom Workflow-Designer und von Aktivitäts-Designern verwendet werden
  • Wechseln von Feldern mit der TAB-TASTE in den Aktivitäten ReceiveReply und SendReply
  • Festlegen von Standardwerten für Variablen oder Argumente
  • Sprachausgaben können Folgendes nun richtig erkennen:
  • Breakpoints, die im Workflow-Designer festgelegt wurden
  • Die Aktivitäten FlowSwitch<T>, FlowDecision und CorrelationScope
  • Die Inhalte der Receive-Aktivität
  • Den Zieltyp für die InvokeMethod-Aktivität
  • Das Kombinationsfeld „Ausnahme“ und den Abschnitt „Finally“ in der TryCatch-Aktivität
  • Das Kombinationsfeld „Nachrichtentyp“, den Splitter im Fenster „Korrelationsinitialisierer hinzufügen“, das Fenster „Inhaltsdefinition“ und das Definitionsfenster „CorrelatesOn“ in den Messagingaktivitäten (Receive, Send, SendReply und ReceiveReply)
  • Übertragungen von Zustandsautomaten und Übertragungsziele
  • Anmerkungen und Connectors von FlowDecision-Aktivitäten
  • Die per Rechtsklick aufrufbaren Kontextmenüs von Aktivitäten
  • Die Editors für Eigenschaftswerte, die Schaltfläche, „Suche löschen“, die Sortierschaltflächen „Nach Kategorie“ und „Alphabetisch“ sowie das Dialogfeld „Ausdrucks-Editor“ im Eigenschaftenraster
  • Den Zoomprozentwert im Workflow-Designer
  • Das Trennzeichen in den Aktivitäten Parallel und Pick
  • Die InvokeDelegate-Aktivität
  • Das Fenster „Typen auswählen“ für Wörterbuchaktivitäten (Microsoft.Activities.AddToDictionary<TKey,TValue>, Microsoft.Activities.RemoveFromDictionary<TKey,TValue> usw.)
  • Das Fenster „.NET-Typ suchen und auswählen“
  • Breadcrumbs im Workflow-Designer
  • Benutzer, die Designs mit hohem Kontrast verwenden, werden viele Verbesserungen in der Sichtbarkeit des Workflow-Designers und dessen Steuerelementen feststellen. Dazu zählen verbesserte Kontrastverhältnisse zwischen Elementen und besser erkennbare Auswahlfelder für Fokuselemente.

Vorschlag

Wenn Sie eine Anwendung mit einem neu gehosteten Workflow-Designer besitzen, kann Ihre Anwendung von diesen Änderungen profitieren, indem Sie eine der folgenden Aktionen durchführen:

  • Rekompilieren Sie Ihre Anwendung, um .NET Framework 4.7.1 anzuzielen. Die Verbesserungen der Barrierefreiheit werden standardmäßig aktiviert.
  • Wenn Ihre Anwendung .NET Framework 4.7 oder früher anzielt, aber auf .NET Framework 4.7.1 ausgeführt wird, können Sie die veralteten Verhaltensweisen für die Barrierefreiheit deaktivieren, indem Sie folgendes AppContext-Element zum <runtime>-Abschnitt der app.config-Datei hinzufügen und dieses wie im folgenden Beispiel dargestellt auf false festlegen.
<?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.UseLegacyAccessibilityFeatures=false" />
  </runtime>
</configuration>

Bei Anwendungen, die .NET Framework 4.7.1 oder höher als Zielplattform verwenden und die Legacy-Barrierefreiheitsverhalten beibehalten sollen, können Sie die Verwendung des veralteten Features für die Barrierefreiheit aktivieren, indem Sie die AppContext-Option auf true festlegen.

name Wert
Bereich Gering
Version 4.7.1
Typ Neuzuweisung

.NET Framework 4.7.2

Kernspeicher

Zulassen bidirektionaler Unicode-Steuerzeichen in URIs

Details

Unicode gibt mehrere spezielle Steuerzeichen an, um die Ausrichtung von Text anzugeben. In früheren Versionen von .NET Framework wurden diese Zeichen selbst dann fälschlicherweise aus allen URIs entfernt, wenn sie in ihrer prozentcodierten Form vorlagen. Damit RFC 3987 besser berücksichtigt wird, sind diese Zeichen in URIs nun zulässig. Wenn sie uncodiert in einem URI gefunden werden, werden sie prozentcodiert. Wenn sie prozentcodiert gefunden werden, bleiben sie unverändert.

Vorschlag

Für Anwendungen mit Zielversionen von .NET Framework ab .NET Framework 4.7.2 ist Unterstützung für bidirektionale Uniccode-Zeichen standardmäßig aktiviert. Wenn diese Änderung nicht erwünscht ist, können Sie sie deaktivieren, indem Sie den Schalter AppContextSwitchOverrides dem Abschnitt <runtime> Ihrer Anwendungskonfigurationsdatei hinzufügen:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontKeepUnicodeBidiFormattingCharacters=true" />
</runtime>

Für Anwendungen mit früheren Zielversionen von .NET Framework, die aber mit Versionen ab .NET Framework 4.7.2 ausgeführt werden, ist Unterstützung für bidirektionale Uniccode-Zeichen standardmäßig deaktiviert. Sie können sie aktivieren, indem Sie den Schalter AppContextSwitchOverrides dem Abschnitt <runtime> Ihrer Anwendungskonfigurationsdatei hinzufügen:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontKeepUnicodeBidiFormattingCharacters=false" />
</runtime>
name Wert
Bereich Gering
Version 4.7.2
Typ Neuzuweisung

Betroffene APIs

DeflateStream verwendet native APIs für die Dekomprimierung

Details

Ab .NET Framework 4.7.2 hat sich die Implementierung der Dekomprimierung in der T:System.IO.Compression.DeflateStream-Klasse so geändert, dass standardmäßig native Windows-APIs verwendet werden. In der Regel führt dies zu einer beträchtlichen Leistungssteigerung. Alle .NET-Anwendungen für .NET Framework Version 4.7.2 oder höher verwenden die native Implementierung. Diese Änderung kann zu einigen Unterschieden im Verhalten führen, beispielsweise:

  • Die Ausnahmemeldungen können sich unterscheiden. Der Typ der ausgelösten Ausnahme bleibt jedoch gleich.
  • Einige besondere Situationen (z.B. nicht ausreichender Speicher zum Abschließen eines Vorgangs) werden möglicherweise anders behandelt.
  • Es gibt bekannte Unterschiede für die Analyse von GZip-Headern (Hinweis: nur GZipStream für die Dekomprimierung ist davon betroffen):
  • Ausnahmen beim Analysieren ungültiger Header werden möglicherweise zu anderen Zeiten ausgelöst.
  • Die native Implementierung führt dazu, dass Werte für einige reservierte Flags im GZip-Header (d.h. FLG) gemäß der Spezifikation festgelegt werden. Dies kann dazu führen, dass in Fällen möglicherweise eine Ausnahme ausgelöst wird, in denen zuvor ungültige Werte ignoriert wurden.

Vorschlag

Wenn sich die Dekomprimierung mit nativen APIs negativ auf das Verhalten Ihrer App ausgewirkt hat, können Sie diese Funktion durch Hinzufügen des Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression-Schalters zum Abschnitt runtime der Datei „app.config“ und Festlegen des Werts auf true deaktivieren:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=true" />
  </runtime>
</configuration>
name Wert
Bereich Gering
Version 4.7.2
Typ Neuzuweisung

Betroffene APIs

Sicherstellen, dass System.Uri einen konsistenten reservierten Zeichensatz verwendet

Details

In System.Uri sind bestimmte prozentcodierte Zeichen, die manchmal decodiert wurden, jetzt konsistent linkscodiert. Dies tritt für die Eigenschaften und Methoden auf, die auf die Pfad-, Abfrage-, Fragment- oder Benutzerinformationenkomponenten des URIs zugreifen. Das Verhalten ändert sich nur, wenn die beiden folgenden Bedingungen erfüllt sind:

  • Der URI enthält die codierte Form eines der folgenden reservierten Zeichen: :, ', (, ), ! oder *.
  • Der URI enthält ein Unicode- oder nicht codiertes reserviertes Zeichen. Wenn beide oben genannten Kriterien erfüllt sind, werden die codierten reservierten Zeichen linkscodiert. In früheren Versionen von .NET Framework wurden sie decodiert.

Vorschlag

Für Anwendungen mit Zielversionen von .NET Framework ab .NET Framework 4.7.2 ist dieses neue Decodierungsverhalten standardmäßig aktiviert. Wenn diese Änderung nicht erwünscht ist, können Sie sie deaktivieren, indem Sie den Schalter AppContextSwitchOverrides dem Abschnitt <runtime> Ihrer Anwendungskonfigurationsdatei hinzufügen:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Uri.DontEnableStrictRFC3986ReservedCharacterSets=true" />
</runtime>

Für Anwendungen mit früheren Zielversionen von .NET Framework, die aber mit Versionen ab .NET Framework 4.7.2 ausgeführt werden, ist das neue Decodierungsverhalten standardmäßig deaktiviert. Sie können sie aktivieren, indem Sie den Schalter AppContextSwitchOverrides dem Abschnitt <runtime> Ihrer Anwendungskonfigurationsdatei hinzufügen:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Uri.DontEnableStrictRFC3986ReservedCharacterSets=false" />
</runtime>
name Wert
Bereich Gering
Version 4.7.2
Typ Neuzuweisung

Betroffene APIs

Resgen lehnt das Laden von Inhalten aus dem Web ab

Details

RESX-Dateien können binär formatierte Eingaben enthalten. Wenn Sie versuchen, mit Resgen eine Datei zu laden, die aus einem nicht vertrauenswürdigen Speicherort heruntergeladen wurde, schlägt das Laden der Eingabe standardmäßig fehl.

Vorschlag

Benutzer*innen von Resgen, die binär formatierte Eingaben aus nicht vertrauenswürdigen Speicherorten laden müssen, können entweder die Markierung des Webs aus der Eingabedatei entfernen oder die Deaktivierungsmethode anwenden. Fügen Sie die folgende Registrierungseinstellung hinzu, um die computerweite Deaktivierungsmethode anzuwenden: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\SDK] "AllowProcessOfUntrustedResourceFiles"="true".

Name Wert
Bereich Microsoft Edge
Version 4.7.2
Typ Neuzuweisung

Stapelüberwachungen, die bei der Verwendung portabler PDBs abgerufen werden, enthalten nun Quelldatei- und Zeileninformationen, wenn diese angefordert werden

Details

Ab .NET Framework 4.7.2 enthalten Stapelüberwachungen, die bei der Verwendung portabler PDBs abgerufen werden, nun Quelldatei- und Zeileninformationen, wenn diese angefordert werden. In Versionen vor .NET Framework 4.7.2 waren Quelldatei- und Zeileninformationen bei Verwendung portabler PDBs selbst dann nicht verfügbar, wenn diese explizit angefordert wurden.

Vorschlag

Für Anwendungen mit der Zielplattform .NET Framework 4.7.2 können Sie sich gegen Quelldatei- und Zeileninformationen entscheiden, wenn Sie portable PDBs verwenden, wenn diese nicht erwünscht sind, indem Sie Folgendes dem Abschnitt <runtime> Ihrer Datei „app.config“ hinzufügen:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Diagnostics.IgnorePortablePDBsInStackTraces=true" />
</runtime>

Bei Anwendungen, die für frühere Versionen von .NET Framework vorgesehen sind, aber in .NET Framework 4.7.2 oder höher ausgeführt werden, können Sie Quelldatei- und Zeileninformationen bei der Verwendung portabler PDBs aktivieren, indem Sie Folgendes dem Abschnitt <runtime> der Datei „app.config“ hinzufügen:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Diagnostics.IgnorePortablePDBsInStackTraces=false" />
</runtime>
name Wert
Bereich Microsoft Edge
Version 4.7.2
Typ Neuzuweisung

Betroffene APIs

Windows Forms

Verbesserung der Barrierefreiheit von Windows Forms-Steuerelementen für .NET 4.7.2

Details

Die Arbeitsweise des Windows Forms-Frameworks mit Technologien für die Barrierefreiheit wird verbessert, um Kunden von Windows Forms besser zu unterstützen. Folgende Änderungen wurden u.a. vorgenommen:

  • Änderungen zum Verbessern der Anzeige während des Modus mit hohem Kontrast
  • Änderungen zum Verbessern der Tastaturnavigation in den DataGridView- und MenuStrip-Steuerelementen.
  • Änderungen an der Interaktion mit der Sprachausgabe.

Vorschlag

Aktivieren oder Deaktivieren dieser Änderungen: Damit die Anwendung von diesen Änderungen profitieren kann, muss sie unter .NET Framework 4.7.2 oder höher ausgeführt werden. Die Anwendung kann von diesen Änderungen profitieren, wenn Sie Folgendes durchführen:

  • Kompilieren Sie diese erneut, um .NET Framework 4.7.2 als Ziel zu verwenden. Diese Änderungen der Barrierefreiheit werden standardmäßig für Windows Forms-Anwendungen aktiviert, die .NET Framework 4.7.2 oder höher als Ziel verwenden.
  • Die Anwendung verwendet .NET Framework 4.7.1 oder eine frühere Version als Ziel und deaktiviert veraltete Verhaltensweisen der Barrierefreiheit, indem wie im folgenden Beispiel dargestellt folgender AppContext-Schalter zum Abschnitt <runtime> der Datei „app.config“ 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.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" />
  </runtime>
</configuration>

Beachten Sie Folgendes: Um die Barrierefreiheitsfunktionen zu aktivieren, die in .NET Framework 4.7.2 hinzugefügt wurden, müssen Sie auch die Barrierefreiheitsfunktion von .NET Framework 4.7.1 aktivieren. Bei Anwendungen, die .NET Framework 4.7.2 oder höher als Zielplattform verwenden und das Legacyverhalten für die Barrierefreiheit beibehalten sollen, können Sie die Verwendung des Legacyfeatures für die Barrierefreiheit aktivieren, indem Sie die AppContext-Option auf true festlegen.

Verwendung von durch das Betriebssystem definierten Farben in Designs mit hohem Kontrast

  • Der Dropdownpfeil von ToolStripDropDownButton verwendet jetzt vom Betriebssystem definierte Farben im Design mit hohem Kontrast.
  • Button-, RadioButton- und CheckBox-Steuerelemente, bei denen FlatStyle auf FlatStyle.Flat oder FlatStyle.Popup festgelegt ist, verwenden nun die vom Betriebssystem definierten Farben im Design mit hohem Kontrast, wenn dieses ausgewählt ist. Zuvor gab es keinen Kontrast zwischen Text und Hintergrundfarbe, wodurch der Text schwer lesbar war.
  • In einem GroupBox-Element enthaltene Steuerelemente, derenEnabled-Eigenschaft auf false festgelegt ist, verwenden nun die vom Betriebssystem definierten Farben im Design mit hohem Kontrast.
  • Die ToolStripButton-, ToolStripComboBox- und ToolStripDropDownButton-Steuerelemente weisen ein höheres Helligkeitskontrastverhältnis im Modus „Hoher Kontrast“ auf.
  • DataGridViewLinkCell verwendet standardmäßig die vom Betriebssystem definierten Farben im Modus „Hoher Kontrast“ für die DataGridViewLinkCell.LinkColor-Eigenschaft. HINWEIS: In Windows 10 wurden die Werte für einige Systemfarben mit hohem Kontrast geändert. Das Windows Forms-Framework basiert auf dem Win32-Framework. Die besten Ergebnisse erhalten Sie, wenn Sie die aktuelle Version von Windows ausführen und die neuesten Änderungen am Betriebssystem aktivieren, indem Sie eine app.manifest-Datei zu einer Testanwendung hinzufügen und den Kommentar aus folgendem Code entfernen:
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

Verbesserte Unterstützung für die Sprachausgabe

  • Die Sprachausgabe kündigt jetzt den Wert der ToolStripMenuItem.ShortcutKeys-Eigenschaft an, wenn Sie den Text eines ToolStripMenuItem ankündigt.
  • Die Sprachausgabe gibt jetzt an, wenn die Enabled-Eigenschaftensatz eines ToolStripMenuItem auf false festgelegt ist.
  • Die Sprachausgabe stellt jetzt Feedback zum Zustand eines Kontrollkästchens bereit, wenn die ListView.CheckBoxes-Eigenschaft auf true festgelegt ist.
  • Die Fokusreihenfolge des Scanmodus der Sprachausgabe ist jetzt mit der visuellen Reihenfolge der Steuerelemente für das ClickOnce-Downloaddialogfenster konsistent.

Verbesserte Unterstützung der DataGridView-Barrierefreiheit

Verbesserte visuelle Hinweise

  • Die RadioButton- und CheckBox-Steuerelemente mit einer leeren Text-Eigenschaft zeigen nun einen Fokusindikator an, wenn sie den Fokus erhalten.

Verbesserte Unterstützung für das Eigenschaftenraster

name Wert
Bereich Hauptversion
Version 4.7.2
Typ Neuzuweisung

„ContextMenuStrip.SourceControl“-Eigenschaft enthält im Fall geschachtelter „ToolStripMenuItems“ ein gültiges Steuerelement

Details

In .NET Framework 4.7.1 und früheren Versionen gibt die ContextMenuStrip.SourceControl-Eigenschaft fälschlicherweise NULL zurück, wenn der Benutzer das Menü in geschachtelten ToolStripMenuItem-Steuerelementen öffnet. In .NET Framework 4.7.2 und höher ist die SourceControl-Eigenschaft immer auf das tatsächliche Quellsteuerelement festgelegt.

Vorschlag

Aktivieren oder Deaktivieren dieser Änderungen: Damit eine Anwendung von diesen Änderungen profitieren kann, muss sie unter .NET Framework 4.7.2 oder höher ausgeführt werden. Die Anwendung kann von diesen Änderungen profitieren, wenn Sie Folgendes durchführen:

  • Die Anwendung ist auf .NET Framework 4.7.2 ausgelegt. Diese Änderung wird standardmäßig für Windows Forms-Anwendungen aktiviert, die auf .NET Framework 4.7.2 oder höher ausgelegt sind.
  • Die Anwendung ist auf .NET Framework 4.7.1 oder eine frühere Version ausgelegt und deaktiviert veraltete Verhaltensweisen der Barrierefreiheit, indem wie im folgenden Beispiel dargestellt folgender AppContext-Schalter zum Abschnitt <runtime> der Datei „app.config“ hinzugefügt und auf false festgelegt wird.
<runtime>
  <AppContextSwitchOverrides value="Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue=false"/>
</runtime>

Bei Anwendungen, die auf .NET Framework 4.7.2 oder höher ausgelegt sind und das veraltete Barrierefreiheitsverhalten beibehalten sollen, können Sie die Verwendung des veralteten Quellcodeverwaltungswerts aktivieren, indem Sie den „AppContext“-Schalter auf true festlegen.

name Wert
Bereich Microsoft Edge
Version 4.7.2
Typ Neuzuweisung

Betroffene APIs

PrivateFontCollection.AddFontFile-Methode gibt Schriftartenressourcen frei

Details

In .NET Framework 4.7.1 und früheren Versionen gibt die System.Drawing.Text.PrivateFontCollection-Klasse keine GDI+-Schriftartenressourcen frei, nachdem PrivateFontCollection für Font-Objekte verworfen wird, die dieser Sammlung mit der AddFontFile(String)-Methode hinzugefügt werden. In .NET Framework 4.7.2 oder höher gibt Dispose die GDI+-Schriftarten frei, die der Sammlung als Dateien hinzugefügt wurden.

Vorschlag

Aktivieren oder Deaktivieren dieser Änderungen: Damit eine Anwendung von diesen Änderungen profitieren kann, muss sie unter .NET Framework 4.7.2 oder höher ausgeführt werden. Die Anwendung kann von diesen Änderungen profitieren, wenn Sie Folgendes durchführen:

  • Kompilieren Sie diese erneut, um .NET Framework 4.7.2 als Ziel zu verwenden. Diese Änderung wird standardmäßig für Windows Forms-Anwendungen aktiviert, die für .NET Framework 4.7.2 oder höher ausgelegt sind.
  • Die Anwendung ist für .NET Framework 4.7.1 oder eine frühere Version ausgelegt und deaktiviert veraltete Verhaltensweisen der Barrierefreiheit, indem wie im folgenden Beispiel dargestellt folgender AppContext-Schalter zum Abschnitt <runtime> der Datei „app.config“ hinzugefügt und auf false festgelegt wird.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Drawing.Text.DoNotRemoveGdiFontsResourcesFromFontCollection=false"/>
</runtime>

Bei Anwendungen, die für .NET Framework 4.7.2 oder höher ausgelegt sind und das Legacyverhalten beibehalten sollen, können Sie die Nichtfreigabe von Schriftartenressourcen aktivieren, indem dieser AppContext-Schalter ausdrücklich auf true festgelegt wird.

name Wert
Bereich Microsoft Edge
Version 4.7.2
Typ Neuzuweisung

Betroffene APIs

Die UpButton- und DownButton-Aktionen der Domäne von WinForm sind jetzt synchronisiert

Details

In .NET Framework 4.7.1 und früheren Versionen wird die DomainUpDown.UpButton()-Aktion des DomainUpDown-Steuerelements ignoriert, wenn Steuerelementtext vorhanden ist, und der Entwickler muss die DomainUpDown.DownButton()-Aktion für das Steuerelement vor der DomainUpDown.UpButton()-Aktion verwenden. Ab .NET Framework 4.7.2 funktionieren die DomainUpDown.UpButton()- und DomainUpDown.DownButton()-Aktionen unabhängig voneinander in diesem Szenario und bleiben synchron.

Vorschlag

Damit eine Anwendung von diesen Änderungen profitieren kann, muss sie unter .NET Framework 4.7.2 oder höher ausgeführt werden. Die Anwendung kann von diesen Änderungen profitieren, wenn Sie Folgendes durchführen:

  • Kompilieren Sie diese erneut, um .NET Framework 4.7.2 als Ziel zu verwenden. Diese Änderung wird standardmäßig für Windows Forms-Anwendungen aktiviert, die für .NET Framework 4.7.2 oder höher ausgelegt sind.
  • Veraltetes Scrollingverhalten wird deaktiviert, indem wie im folgenden Beispiel dargestellt folgender AppContext-Schalter dem Abschnitt <runtime> der Datei „app.config“ hinzugefügt und auf false festgelegt wird.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling=false"/>
</runtime>
name Wert
Bereich Microsoft Edge
Version 4.7.2
Typ Neuzuweisung

Betroffene APIs

Windows Presentation Foundation (WPF)

Der Tastaturfokus bewegt sich jetzt ordnungsgemäß über mehrere Ebenen von WinForms-/WPF-Hosting

Details

Nehmen Sie als Beispiel eine WPF-Anwendung, die ein WinForms-Steuerelement hostet, das wiederum WPF-Steuerelemente hostet. Benutzer können die WinForms-Ebene möglicherweise nicht mit der TABULATORTASTE verlassen, wenn das erste oder letzte Steuerelement in diese Ebene System.Windows.Forms.Integration.ElementHost von WPF ist. Diese Änderung behebt dieses Problem, und Benutzer können die WinForms-Ebene jetzt mit der TABULATORTASTE verlassen. Automatisierte Anwendungen, die erfordern, dass der Fokus die WinForms-Ebene nie verlässt, funktionieren möglicherweise nicht mehr wie erwartet.

Vorschlag

Ein Entwickler, der diese Änderung für eine niedrigere Frameworkversion als .NET 4.7.2 nutzen möchte, kann die folgende Gruppe von AppContext-Flags auf FALSE festlegen, damit die Änderung aktiviert wird.

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

WPF-Anwendungen müssen alle frühen Barrierefreiheitsverbesserungen aktivieren, um die späteren Verbesserungen abrufen zu können. Das heißt, die Switch.UseLegacyAccessibilityFeatures- und Switch.UseLegacyAccessibilityFeatures.2-Schalter müssen festgelegt werden. Ein-Entwickler, der die vorherige Funktionalität für .NET 4.7.2 oder höher benötigt, kann das folgende AppContext-Flag auf TRUE festlegen, damit die Änderung deaktiviert wird.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures.2=true"/>
</runtime>
</configuration>
name Wert
Bereich Microsoft Edge
Version 4.7.2
Typ Neuzuweisung

Der Standardhashalgorithmus für den Markupcompiler von WPF ist jetzt SHA256

Details

Die WPF-MarkupCompiler stellt Kompilierungsdienste für XAML-Markupdateien bereit. In .NET Framework 4.7.1 und früheren Versionen war SHA1 der Standardhashalgorithmus, der für Prüfsummen verwendet wurde. Diese Standardeinstellung wurde ab .NET Framework 4.7.2 aufgrund von Sicherheitsbedenken im Zusammenhang mit SHA1 in SHA256 geändert. Diese Änderung wirkt sich auf die gesamte Prüfsummengenerierung für Markupdateien während der Kompilierung aus.

Vorschlag

Ein Entwickler, der als Zielplattform .NET Framework 4.7.2 oder höher verwendet und das SHA1-Hashverhalten wiederherstellen möchte, muss das folgende AppContext-Flag festlegen.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Markup.DoNotUseSha256ForMarkupCompilerChecksumAlgorithm=true"/>
</runtime>
</configuration>

Ein Entwickler, der SHA256-Hashwerte für eine niedrigere Frameworkversion als .NET 4.7.2 nutzen möchte, muss das unten genannte AppContext-Flag festlegen. Beachten Sie, dass die installierte Version von .NET Framework 4.7.2 oder höher sein muss.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Markup.DoNotUseSha256ForMarkupCompilerChecksumAlgorithm=false"/>
</runtime>
</configuration>
name Wert
Bereich Transparent
Version 4.7.2
Typ Neuzuweisung

Bei der Verarbeitung von WPF AppDomain-Herunterfahrvorgängen kann nun „Dispatcher.Invoke“ zur Bereinigung von schwachen Ereignissen aufgerufen werden

Details

In .NET Framework 4.7.1 und früheren Versionen erstellt WPF möglicherweise während des Herunterfahrens von AppDomain einen System.Windows.Threading.Dispatcher im .NET-Finalizerthread. Dies wurde in .NET Framework 4.7.2 und höheren Versionen korrigiert, indem nun bei der Bereinigung von schwachen Ereignissen Threads berücksichtigt werden. Aus diesem Grund kann WPF Dispatcher.Invoke aufrufen, um den Bereinigungsprozess abzuschließen. In manchen Anwendungen kann diese Änderung des Finalizerzeitpunkts zu Ausnahmen beim Herunterfahren von AppDomain oder des Prozesses führen. Dies tritt in der Regel bei Anwendungen auf, die die Verteiler, die auf Arbeitsthreads ausgeführt werden, nicht ordnungsgemäß herunterfahren, bevor der Prozess oder AppDomain heruntergefahren wird. Bei solchen Anwendungen muss darauf geachtet werden, dass die Lebensdauer von Verteilern angemessen verwaltet wird.

Vorschlag

In .NET Framework 4.7.2 und höheren Versionen können Entwickler diesen Fix deaktivieren, um Probleme bei der Zeitsteuerung zu verringern (aber nicht zu verhindern), die aufgrund der Bereinigungsänderung auftreten können. Verwenden Sie zum Deaktivieren der Bereinigungsänderung das folgende AppContext-Flag.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotInvokeInWeakEventTableShutdownListener=true"/>
</runtime>
</configuration>
name Wert
Bereich Microsoft Edge
Version 4.7.2
Typ Neuzuweisung

Ändern eines Primärschlüssels durch WPF beim Anzeigen von ADO-Daten in einem Master/Detail-Szenario

Details

Nehmen Sie an, Sie haben eine ADO-Auflistung von Elementen des Typs Order mit einer Beziehung namens „OrderDetails“, durch die diese Auflistung über den Primärschlüssel „OrderID“ mit einer Auflistung von Elementen des Typs Detail verknüpft wird. In Ihrer WPF-App können Sie ein Listensteuerelement an die Details für einen bestimmten Auftrag binden:

<ListBox ItemsSource="{Binding Path=OrderDetails}" >

Beim DataContext handelt es sich um ein Order-Element. WPF ruft den Wert der Eigenschaft OrderDetails ab. Es handelt sich hierbei um eine D-Sammlung aller Detail-Elemente, deren OrderID der OrderID des Masterelements entspricht. Der Behavior Change wird angezeigt, wenn Sie den Primärschlüssel OrderID des Masterelements ändern. ADO ändert automatisch die OrderID jedes der betroffenen Datensätze in der Sammlung „Details“ (also diejenigen, die in Sammlung D kopiert wurden). Was passiert mit D?

  • Altes Verhalten: Sammlung D wird gelöscht. Das Masterelement löst keine Änderungsbenachrichtigung für die Eigenschaft OrderDetails aus. Das ListBox-Element verwendet weiterhin Sammlung D, die jetzt leer ist.
  • Neues Verhalten: Auflistung D wird nicht geändert. Jedes enthaltene Element löst Änderungsbenachrichtigung für die Eigenschaft OrderID aus. ListBox verwendet weiterhin Sammlung D, und zeigt die Details mit der neuen OrderID an. WPF implementiert das neue Verhalten, indem Sammlung D auf andere Weise erstellt wird: durch Aufrufen der ADO-Methode DataRowView.CreateChildView(DataRelation, Boolean) mit dem auf true festgelegten Argument followParent.

Vorschlag

Eine App ruft das neue Verhalten durch Verwendung der folgenden AppContext-Option auf.

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Windows.Data.DoNotUseFollowParentWhenBindingToADODataRelation=false"/>
  </runtime>
</configuration>

Die Option ist für Apps, die auf .NET 4.7.1 oder niedriger ausgelegt sind, standardmäßig auf true festgelegt (altes Verhalten). Für Apps, die auf .NET 4.7.2 oder höher ausgelegt sind, ist sie standardmäßig auf false festgelegt.

name Wert
Bereich Gering
Version 4.7.2
Typ Neuzuweisung

WPF FocusVisual für RadioButton und CheckBox wird jetzt ordnungsgemäß angezeigt, wenn die Steuerelemente keinen Inhalt enthalten

Details

In .NET Framework 4.7.1 und früheren Versionen weisen System.Windows.Controls.CheckBox und System.Windows.Controls.RadioButton von WPF inkonsistente und im klassischen Design und im Design mit hohem Kontrast falsche visuelle Fokuselemente auf. Diese Probleme treten in Fällen auf, in denen für die Steuerelemente keine Inhalte festgelegt sind. Dadurch kann der Übergang zwischen Designs verwirrend wirken und das visuelle Fokuselement schwer zu erkennen sein. In .NET Framework, 4.7.2 sind diese visuellen Elemente jetzt designübergreifend konsistenter und im klassischen Design sowie im Design mit hohem Kontrast leichter zu erkennen.

Vorschlag

Ein Entwickler, die Code für .NET Framework 4.7.2 erstellt und das Verhalten von .NET 4.7.1 wiederherstellen möchte, muss das folgende AppContext-Flag festlegen.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures.2=true;"/>
</runtime>
</configuration>

Ein Entwickler, der diese Änderung für eine niedrigere Frameworkversion als .NET 4.7.2 nutzen möchte, muss die folgenden AppContext-Flags festlegen. Beachten Sie, dass alle Flags ordnungsgemäß festgelegt werden müssen, und die installierte Version von .NET Framework muss 4.7.2 oder höher sein. WPF-Anwendungen müssen alle früheren Barrierefreiheitsverbesserungen aktivieren, um die neuesten Verbesserungen abrufen zu können. Stellen Sie zu diesem Zweck sicher, dass die AppContext-Schalter „Switch.UseLegacyAccessibilityFeatures“ und „Switch.UseLegacyAccessibilityFeatures.2“ auf FALSE festgelegt sind.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false;"/>
</runtime>
</configuration>
name Wert
Bereich Microsoft Edge
Version 4.7.2
Typ Neuzuweisung

TextBox-/PasswordBox-Textauswahl von WPF folgt nicht den Systemfarben

Details

In .NET Framework 4.7.1 und früheren Versionen konnten System.Windows.Controls.TextBox und System.Windows.Controls.PasswordBox von WPF nur eine Textauswahl aus der Adorner-Ebene rendern. In einigen Systemdesigns verdeckte dies Text, wodurch die Lesbarkeit erschwert wurde. In .NET Framework 4.7.2 und höher besteht für Entwickler eine Option, ein nicht auf Adorner basierendes Auswahlrenderingschema zu aktivieren, das dieses Problem behebt.

Vorschlag

Ein Entwickler, die diese Änderung nutzen möchte, muss das folgende AppContext-Flag entsprechend festlegen. Um dieses Feature nutzen zu können, muss die installierte Version von .NET Framework 4.7.2 oder höher sein. Um die nicht auf Adorner basierende Auswahl zu aktivieren, verwenden Sie das folgenden AppContext-Flag.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Text.UseAdornerForTextboxSelectionRendering=false"/>
</runtime>
</configuration>
name Wert
Bereich Microsoft Edge
Version 4.7.2
Typ Neuzuweisung

Windows Workflow Foundation (WF)

Vermeiden von Endlosrekursion für IWorkflowInstanceManagement.TransactedCancel und IWorkflowInstanceManagement.TransactedTerminate

Details

Wenn Sie IWorkflowInstanceManagement.TransactedCancel- oder IWorkflowInstanceManagement.TransactedTerminate-APIs verwenden, um eine Worklowdienstinstanz abzubrechen oder zu beenden, kann für die Workflowinstanz unter bestimmten Umständen aufgrund von Endlosrekursion ein Stapelüberlauf auftreten, wenn die Workflow-Laufzeit versucht, die Dienstinstanz als Teil der Verarbeitung der Anforderung persistent zu speichern. Das Problem tritt auf, wenn sich die Workflowinstanz in einem Zustand befindet, in dem sie auf den Abschluss einer anderen ausstehenden WCF-Anforderung an einen anderen Dienst wartet. Die Vorgänge TransactedCancel und TransactedTerminate erstellen Arbeitselemente, die für die Workflowdienstinstanz in die Warteschlange eingereiht werden. Diese Arbeitselemente werden nicht im Rahmen der Verarbeitung der TransactedCancel/TransactedTerminate-Anforderung ausgeführt. Da die Workflowdienstinstanz damit ausgelastet ist, auf den Abschluss der anderen ausstehenden WCF-Anforderung zu warten, verbleibt das erstellte Arbeitselement in der Warteschlange. Der TransactedCancel/TransactedTerminate-Vorgang wird abgeschlossen, und die Steuerung wird zurück an den Client übergeben. Wenn die dem TransactedCancel/TransactedTerminate-Vorgang zugeordnete Transaktion den Commit versucht, muss sie den Zustand der Workflowdienstinstanz persistent speichern. Da aber für die Instanz eine ausstehende WCF-Anforderung vorliegt, kann die Workflowruntime die Workflowdienstinstanz nicht persistent speichern, und eine Endlosrekursionsschleife führt zum Stapelüberlauf. Da TransactedCancel und TransactedTerminate nur ein Arbeitselement im Speicher erstellen, besitzt die Tatsache, dass eine Transaktion vorhanden ist, keinerlei Auswirkung. Durch ein Rollback der Transaktion wird das Arbeitselement nicht verworfen. Zur Lösung dieses Problems wurde ab .NET Framework 4.7.2 eine AppSetting eingeführt, die web.config/app.config des Workflowdiensts hinzugefügt werden kann und angibt, dass Transaktionen für TransactedCancel und TransactedTerminate ignoriert werden sollen. Auf diese Weise kann die Transaktion einen Commit ausführen, ohne warten zu müssen, bis die Workflowinstanz dauerhaft gespeichert wurde. Das AppSetting-Element für dieses Feature hat den Namen microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate. Der Wert true gibt an, dass die Transaktion ignoriert werden soll, um so den Stapelüberlauf zu vermeiden. Der Standardwert dieser AppSetting ist false. Vorhandene Workflowdienstinstanzen sind daher nicht betroffen.

Vorschlag

Wenn Sie AppFabric oder einen anderen IWorkflowInstanceManagement-Client verwenden und beim Versuch, eine Workflowinstanz abzubrechen oder zu beenden, ein Stapelüberlauf in der Workflowdienstinstanz auftritt, können Sie Folgendes zum Abschnitt <appSettings> der Datei „web.config/app.config“ für den Workflowdienst hinzufügen:

<add key="microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate" value="true"/>

Wenn dieses Problem nicht auftritt, müssen Sie diese Aktion nicht ausführen.

name Wert
Bereich Microsoft Edge
Version 4.7.2
Typ Neuzuweisung