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

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

.NET Framework 4.7

ASP.NET

HttpRuntime.AppDomainAppPath löst NullReferenceException aus

Einzelheiten

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 eine der folgenden Aktionen ausführen, um auf diese Änderung zu reagieren:

• Behandeln Sie die T:System.NullReferenceException, wenn Ihre Anwendung in .NET Framework 4.6.2 ausgeführt wird.
• Upgrade auf .NET Framework 4.7, wodurch das vorherige Verhalten wiederhergestellt wird und ein T:System.ArgumentNullExceptionausgelöst wird.

Betroffene APIs

• HttpRuntime.AppDomainAppPath

Einschränken von gleichzeitigen Anforderungen pro Sitzung

Einzelheiten

In der .NET Framework 4.6.2 und früheren Versionen führt ASP.NET Anforderungen mit derselben Sessionid sequenziell aus, und ASP.NET gibt 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 ist, wird eine Warnung im Ereignisprotokoll protokolliert, und eine HTTP 500-Antwort kann im IIS-Protokoll aufgezeichnet werden.

Vorschlag

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

<appSettings>
    <add key="aspnet:RequestQueueLimitPerSession" value="2147483647"/>
</appSettings>

Vernetzung

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

Einzelheiten

Beginnend mit Apps, die auf .NET Framework 4.7 abzielen, ist der Standardwert der ServicePointManager.SecurityProtocol-Eigenschaft SecurityProtocolType.SystemDefault. Diese Änderung ermöglicht .NET Framework-Netzwerk-APIs, die auf SslStream (z. B. FTP, HTTPS und SMTP) basieren, die Standardsicherheitsprotokolle vom Betriebssystem zu erben, anstatt hartcodierte Werte zu verwenden, die von .NET Framework definiert werden. Die Standardeinstellung variiert je nach Betriebssystem und jeder vom Systemadministrator durchgeführten benutzerdefinierten Konfiguration. Informationen zum standardmäßigen SChannel-Protokoll in der jeweiligen Version des Windows-Betriebssystems finden Sie unter Protokolle in TLS/SSL (SChannel SSP).

Vorschlag

Diese Änderung wirkt sich auf Anwendungen aus, die auf .NET Framework 4.7 oder höhere Versionen abzielen. Wenn Sie lieber ein definiertes Protokoll verwenden möchten, anstatt sich auf den Systemstandard zu verlassen, können Sie den Wert der ServicePointManager.SecurityProtocol-Eigenschaft explizit festlegen. Wenn diese Änderung nicht erwünscht ist, können Sie dies deaktivieren, indem Sie dem Abschnitt <Laufzeit> Ihrer Anwendungskonfigurationsdatei eine Konfigurationseinstellung hinzufügen. Das folgende Beispiel zeigt sowohl den Abschnitt <runtime> als auch den Switch.System.Net.DontEnableSystemDefaultTlsVersions-Opt-Out-Schalter.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=true" />
</runtime>

Betroffene APIs

• ServicePointManager.SecurityProtocol

SslStream unterstützt TLS-Warnungen

Einzelheiten

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 wie Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) aufrufen, sollten IOException oder System.TimeoutExceptionbehandeln.
Das TLS-Benachrichtigungsfeature ist standardmäßig aktiviert, beginnend mit .NET Framework 4.7. Anwendungen, die auf Versionen des .NET Frameworks von 4.0 bis 4.6.2 abzielen und auf einem System mit .NET Framework 4.7 oder höher ausgeführt werden, werden die Funktion deaktiviert haben, um die Kompatibilität zu gewährleisten.
Die folgende Konfigurations-API ist verfügbar, um das Feature für .NET Framework 4.6 und höhere Anwendungen zu aktivieren oder zu deaktivieren, die auf .NET Framework 4.7 oder höher ausgeführt werden.

• 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 (systemweit): Legen Sie den Wert auf false fest, um die Funktion im .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"
  

Betroffene APIs

• System.Net.Security.SslStream
• System.Net.WebRequest
• System.Net.HttpWebRequest
• System.Net.FtpWebRequest
• System.Net.Mail.SmtpClient
• System.Net.Http

Sicherheit

CspParameters.ParentWindowHandle erwartet nun einen HWND-Wert

Einzelheiten

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 des .NET Framework wurde erwartet, dass der Wert ein System.IntPtr ist, das einen Speicherort darstellt, an dem sich der HWND-Wert befindet. Festlegen der Eigenschaft auf form.Handle hatte unter Windows 7 und früheren Versionen keine Auswirkung, führt jedoch unter Windows 8 und späteren Versionen zu einem "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;

Benutzer, die festgestellt haben, dass der richtige zu übergebene Wert die Adresse eines Speicherorts war, der den Wert form.Handle beinhaltete, können die Verhaltensänderung deaktivieren, indem sie den AppContext-Switch Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle auf truefestlegen.

• Durch das programmgesteuerte Festlegen von Kompatibilitätsschaltern im AppContext, wie bei den .NET-Ankündigungen auf der Build 2015 erläutert.
• Durch Hinzufügen der folgenden Zeile zum Abschnitt <runtime> der app.config-Datei:

<runtime>
 <AppContextSwitchOverrides value="Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle=true"/>
</runtime>

Umgekehrt können Benutzer, die sich für das neue Verhalten auf der .NET Framework 4.7-Laufzeit anmelden möchten, wenn die Anwendung unter älteren .NET Framework-Versionen geladen wird, den AppContext-Switch auf falsefestlegen.

Betroffene APIs

• CspParameters.ParentWindowHandle

SslStream unterstützt TLS-Warnungen

Einzelheiten

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 wie Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) aufrufen, sollten IOException oder System.TimeoutExceptionbehandeln.
Das TLS-Benachrichtigungsfeature ist standardmäßig aktiviert, beginnend mit .NET Framework 4.7. Anwendungen, die auf Versionen des .NET Frameworks von 4.0 bis 4.6.2 abzielen und auf einem System mit .NET Framework 4.7 oder höher ausgeführt werden, werden die Funktion deaktiviert haben, um die Kompatibilität zu gewährleisten.
Die folgende Konfigurations-API ist verfügbar, um das Feature für .NET Framework 4.6 und höhere Anwendungen zu aktivieren oder zu deaktivieren, die auf .NET Framework 4.7 oder höher ausgeführt werden.

• 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 (systemweit): Legen Sie den Wert auf false fest, um die Funktion im .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"
  

Betroffene APIs

• System.Net.Security.SslStream
• System.Net.WebRequest
• System.Net.HttpWebRequest
• System.Net.FtpWebRequest
• System.Net.Mail.SmtpClient
• System.Net.Http

Windows Communication Foundation (WCF)

Die Serialisierung von Steuerzeichen mit DataContractJsonSerializer ist jetzt mit ECMAScript V6 und V8 kompatibel.

Einzelheiten

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

Für Apps, die auf .NET Framework 4.7 abzielen, ist dieses Feature standardmäßig aktiviert. Wenn dieses Verhalten nicht wünschenswert ist, können Sie dieses Feature deaktivieren, indem Sie die folgende Zeile zum Abschnitt <runtime> der app.config oder web.config Datei hinzufügen:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseECMAScriptV6EscapeControlCharacter=false" />
</runtime>

Betroffene APIs

• DataContractJsonSerializer.WriteObject(Stream, Object)
• DataContractJsonSerializer.WriteObject(XmlDictionaryWriter, Object)
• DataContractJsonSerializer.WriteObject(XmlWriter, Object)

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

Einzelheiten

Ab dem .NET Framework 4.7 können Kunden TLS1.1 oder TLS1.2 in der WCF-Nachrichtensicherheit zusätzlich zu SSL3.0 und TLS1.0 über die Anwendungskonfiguration konfigurieren.

Vorschlag

In .NET Framework 4.7 ist die Unterstützung für TLS1.1 und TLS1.2 in WCF-Nachrichtensicherheit standardmäßig deaktiviert. Sie können sie aktivieren, indem Sie die folgende Zeile zum Abschnitt <runtime> der datei app.config oder web.config hinzufügen:

<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>

Windows Presentation Foundation (WPF)

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

Einzelheiten

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. Um die Ausnahme zu verhindern, führen Sie ein Upgrade auf eine Version von .NET Framework ab Version 4.7 durch.

NullReferenceException im Ausnahmebehandlungscode von ImageSourceConverter.ConvertFrom

Einzelheiten

Ein Fehler im Ausnahmebehandlungscode für ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) führte dazu, dass anstelle der beabsichtigten Ausnahme ( System.NullReferenceException oder System.IO.DirectoryNotFoundException) ein falscher System.IO.FileNotFoundException ausgelöst wurde. Diese Änderung korrigiert diesen Fehler, sodass die Methode jetzt 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>

Betroffene APIs

• ImageSourceConverter.ConvertFrom(ITypeDescriptorContext, CultureInfo, Object)

Platzvergabe im Raster für -Spalten

Einzelheiten

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 von einer expliziten MinWidth-Deklaration oder von einem impliziten Minimum abgeleitet werden, das aus dem Inhalt der Spalte abgerufen wird. Die maximale Breite kann nur explizit definiert werden, aus einer MaxWidth-Deklaration.)
• 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 ersten beiden Fällen können sich die vom neuen Algorithmus erzeugten Breiten deutlich von denen unterscheiden, die vom alten Algorithmus erzeugt werden; im letzten Fall beträgt der Unterschied höchstens ein oder zwei Pixel.

Der neue Algorithmus behebt mehrere Fehler, die im alten Algorithmus vorhanden sind:

• Die Gesamtzuweisung an Spalten kann die Breite des Rasters überschreiten. Dies kann auftreten, wenn Platz einer Spalte zugeordnet wird, deren proportionaler Anteil kleiner als ihre Mindestgröße ist. Der Algorithmus weist die Mindestgröße zu, wodurch der verfügbare Platz für andere Spalten 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 großen Gewichten (> 10^298) werden alle so behandelt, als hätten sie das Gewicht 10^298. Proportionale Unterschiede zwischen ihnen (und zwischen Spalten mit erheblich kleineren Gewichtungen) werden nicht berücksichtigt.

• Spalten mit unendlichen Gewichtungen werden nicht richtig 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 die folgenden Kriterien erfüllen:

  • Die tatsächliche Breite, die einer *-Spalte zugewiesen ist, ist nie kleiner als die Mindestbreite oder größer als die maximale Breite.
  • Jede *-Spalte, der nicht ihre Mindest- oder Maximalbreite zugewiesen wird, wird eine Breite zugewiesen, die proportional zu ihrer *-Gewichtung ist. Um genau zu sein, wenn zwei Spalten mit der Breite x* bzw. y* deklariert werden und keine Spalte die minimale oder maximale Breite erhält, sind die tatsächlichen Breiten v und w, die den Spalten zugewiesen sind, 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). Dies kann null sein, z. B. wenn die Summe der mindestbreiten die verfügbare Breite des Rasters überschreitet.
  • All diese Aussagen sind im Hinblick auf das "ideale" Layout zu interpretieren. Wenn Layoutglättung aktiviert ist, können die tatsächlichen Breiten um bis zu ein Pixel von den idealen Breiten abweichen.

Vorschlag

Standardmäßig sehen Apps, die auf Versionen von .NET Framework ab .NET Framework 4.7 abzielen, den neuen Algorithmus, während Apps, die auf .NET Framework 4.6.2 oder frühere Versionen abzielen, den alten Algorithmus sehen.

Verwenden Sie die folgende Konfigurationseinstellung, um die Standardeinstellung außer Kraft zu setzen:

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

Der Wert true wählt den alten Algorithmus aus, false den neuen Algorithmus auswählt.

Zeigerbasierte Touch-Stapel in WPF

Einzelheiten

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.
• Dies kann dazu führen, 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 App.config Datei ihrer Anwendung Folgendes hinzufügen/zusammenführen:

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

Wenn Sie diesen Wert entfernen oder den Wert auf "false" festlegen, wird dieser optionale Stapel deaktiviert. Beachten Sie, dass dieser Stapel nur unter Windows 10 Creators Update und höher verfügbar ist.

Windows Workflow Foundation (WF)

Änderung der Workflow-Prüfsummen von MD5 zu SHA1.

Einzelheiten

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 verwendete das Workflow-Checksummen-Hashing den MD5-Algorithmus, der Probleme auf FIPS-fähigen Systemen verursachte. Ab .NET Framework 4.7 ist der Algorithmus SHA1. 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>

.NET Framework 4.7.1

ASP.NET

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

Einzelheiten

Ab .NET Framework 4.7.1 hat ASP.NET verbessert, wie ASP.NET Websteuerelemente mit der Barrierefreiheitstechnologie in Visual Studio arbeiten, um ASP.NET Kunden besser zu unterstützen. Dazu gehören die folgenden Änderungen:

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

So stimmen Sie diesen Änderungen zu oder lehnen sie ab. Damit der Visual Studio Designer von diesen Änderungen profitieren kann, muss er auf dem .NET Framework 4.7.1 oder höher ausgeführt werden. Die Webanwendung kann von diesen Änderungen auf eine der folgenden Arten profitieren:

• Installieren Sie Visual Studio 2017 15.3 oder höher, das die neuen Barrierefreiheitsfunktionen standardmäßig mit dem folgenden AppContext-Schalter unterstützt.
• Deaktivieren Sie die Legacy-Barrierefreiheitsverhalten, indem Sie in der Konfigurationsdatei „devenv.exe“ dem Abschnitt Switch.UseLegacyAccessibilityFeatures die AppContext-Option <runtime> 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 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.

Kern

Ausnahmen in SerialPort-Hintergrundthreads

Einzelheiten

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 abzielen, wird ein Prozess beendet, wenn eine Betriebssystem-Ausnahme 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 abzielen, warten Hintergrundthreads auf Betriebssystemereignisse im Zusammenhang mit dem aktiven seriellen Port und können in einigen Fällen abstürzen, z. B. plötzliches Entfernen des seriellen Ports.

Vorschlag

Für Apps, die auf .NET Framework 4.7.1 abzielen, können Sie die Ausnahmebehandlung deaktivieren, wenn dies nicht wünschenswert ist, indem Sie dem Abschnitt <runtime> Ihrer app.config Datei Folgendes hinzufügen:

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

Für Apps, die auf frühere Versionen von .NET Framework abzielen, aber auf .NET Framework 4.7.1 oder höher ausgeführt werden, können Sie sich für die Ausnahmebehandlung anmelden, indem Sie dem Abschnitt <runtime> Ihrer app.config Datei Folgendes hinzufügen:

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

Betroffene APIs

• System.IO.Ports.SerialPort

ServiceBase verbreitet keine OnStart-Ausnahmen

Einzelheiten

In .NET Framework 4.7 und früheren Versionen werden Ausnahmen, die beim Starten des Diensts ausgelöst werden, nicht an den Aufrufer von ServiceBase.Runweitergegeben.

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 gestartet werden können.

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

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

Wenn Ihre Anwendung auf eine frühere Version als 4.7.1 ausgerichtet ist, sie aber dieses Verhalten haben möchten, fügen Sie dem Abschnitt AppContextSwitchOverrides Ihrer Anwendungskonfigurationsdatei das folgende runtime Element hinzu:

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

Betroffene APIs

• ServiceBase.Run(ServiceBase)
• ServiceBase.Run(ServiceBase[])

Sicherheit

Die Standardalgorithmen "SignedXML" und "SignedXMS" wurden auf SHA256 umgestellt.

Einzelheiten

In .NET Framework 4.7 und früheren Versionen ist "SignedXML" und "SignedCMS" für einige Vorgänge standardmäßig auf SHA1 festgelegt. Ab .NET Framework 4.7.1 ist SHA256 für diese Vorgänge standardmäßig aktiviert. Diese Änderung ist erforderlich, da SHA1 nicht mehr als sicher betrachtet wird.

Vorschlag

Es gibt zwei neue Kontextwechselwerte, um zu steuern, ob SHA1 (unsicher) oder SHA256 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" />

Für Anwendungen, die auf .NET Framework 4.7 und frühere Versionen abzielen, können Sie sich für diese Änderung entscheiden, indem Sie den folgenden Konfigurationswechsel zum abschnitt Laufzeit Ihrer App-Konfigurationsdatei hinzufügen:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=false;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=false" />

Betroffene APIs

• System.Security.Cryptography.Pkcs.CmsSigner
• System.Security.Cryptography.Xml.SignedXml
• System.Security.Cryptography.Xml.Reference

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

Einzelheiten

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" />

Betroffene APIs

• SignedXml.CheckSignatureReturningKey(AsymmetricAlgorithm)

Windows Communication Foundation (WCF)

Verbesserte Barrierefreiheit für einige .NET SDK-Tools

Einzelheiten

Im .NET Framework SDK 4.7.1 wurden die tools SvcConfigEditor.exe und SvcTraceViewer.exe verbessert, indem verschiedene Barrierefreiheitsprobleme behoben wurden. Die meisten dieser Probleme waren kleine Probleme, z. B. ein Name, der nicht definiert wird oder bestimmte Benutzeroberflächenautomatisierungsmuster nicht ordnungsgemäß implementiert werden. 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>

Windows Forms

Verbesserung der Barrierefreiheit von Windows Forms-Steuerelementen

Einzelheiten

Windows Forms verbessert die Funktionsweise mit Barrierefreiheitstechnologien, um Windows Forms-Kunden besser zu unterstützen. Dazu gehören die folgenden Änderungen ab .NET Framework 4.7.1:

• Änderungen zur Verbesserung der Anzeige im Modus "Hoher 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

So aktivieren oder deaktivieren Sie diese Änderungen Damit die Anwendung von diesen Änderungen profitieren kann, muss sie auf dem .NET Framework 4.7.1 oder höher ausgeführt werden. Die Anwendung kann von diesen Änderungen auf eine der folgenden Arten profitieren:

• Es wird neu kompiliert, um auf .NET Framework 4.7.1 auszurichten. Diese Barrierefreiheitsänderungen sind in Windows Forms-Anwendungen, die auf .NET Framework 4.7.1 oder höher abzielen, standardmäßig aktiviert.
• 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 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.

Eine Übersicht über die Benutzeroberflächenautomatisierung finden Sie in der Übersicht über die Benutzeroberflächenautomatisierung.

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 winForms-spezifisch. Beispielsweise können Barrierefreiheitsbenutzer die QueryInterface-Methode in 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- (sofern zutreffend) für WinForms-Barrierefreiheitsobjekte verfügbar.

.NET Framework 4.7.1 bietet Unterstützung für die folgenden Benutzeroberflächenautomatisierungsmuster und -eigenschaften:

• Die Steuerelemente ToolStripSplitButton und ComboBox unterstützen das Muster Erweitern/Reduzieren.

• Das ToolStripMenuItem-Steuerelement weist einen ControlType-Eigenschaftswert von ControlType.MenuItem auf.

• Das ToolStripItem-Steuerelement unterstützt die NameProperty-Eigenschaft und das Muster für das Erweitern/Reduzieren.

• Das ToolStripDropDownItem-Steuerelement unterstützt das AccessibleEvents-Element, das StateChange und NameChange angibt, wenn das Dropdownmenü erweitert oder reduziert ist.

• Das ToolStripDropDownButton-Steuerelement weist einen ControlType-Eigenschaftswert von ControlType.MenuItem auf.

• Das DataGridViewCheckBoxCell-Steuerelement unterstützt das TogglePattern.

• Die NumericUpDown- und DomainUpDown-Steuerelemente unterstützen die NameProperty-Eigenschaft und weisen einen ControlType von ControlType.Spinner auf.

  Verbesserungen am PropertyGrid-Steuerelement: Mit .NET Framework 4.7.1 werden folgende Verbesserungen zum PropertyBrowser-Steuerelement hinzugefügt:

• Die Schaltfläche Details im Dialogfeld „Fehler“, das angezeigt wird, wenn der Benutzer einen falschen Wert in das PropertyGrid-Steuerelement eingibt, unterstützt das Muster Erweitern/Reduzieren, Benachrichtigungen für Status- und Namensänderungen und eine ControlType-Eigenschaft mit einem Wert von ControlType.MenuItem.

• Auf den Bereich „Meldung“, der angezeigt wird, wenn die Schaltfläche Details des Dialogfelds „Fehler“ erweitert ist, kann nun über die Tastatur zugegriffen werden. Außerdem kann die Microsoft-Sprachausgabe den Inhalt der Fehlermeldung ausgeben.

• Das AccessibleRole-Element für Zeilen im PropertyGrid-Steuerelement wurde von „Zeile“ in „Zelle“ geändert. Die Zelle ist dem UIA-ControlType-Element „DataItem“ zugeordnet, sodass entsprechende Tastenkombinationen und Sprachausgaben unterstützt werden.

• Die Zeilen des PropertyGrid-Steuerelements, die Headerelemente darstellen, wenn die PropertyGrid-Eigenschaft des PropertySort-Steuerelements auf PropertySort.Categorized festgelegt ist, weisen einen ControlType-Eigenschaftswert von ControlType.Button auf.

• Die Zeilen des PropertyGrid-Steuerelements, die Headerelemente darstellen, wenn die PropertyGrid-Eigenschaft des PropertySort-Steuerelements auf PropertySort.Categorized festgelegt ist, unterstützen das Muster Erweitern/Reduzieren.

• Verbesserte Tastaturnavigation zwischen dem Raster und der darüber liegenden Symbolleiste. Durch Drücken von UMSCHALT+TAB wird jetzt die erste Symbolleistenschaltfläche anstelle der gesamten Symbolleiste ausgewählt.

• Bei den PropertyGrid-Steuerelementen, die im Modus „Hoher Kontrast“ angezeigt werden, wird nun ein Fokusrechteck um die Symbolleistenschaltfläche angezeigt, die dem aktuellen Wert der PropertySort-Eigenschaft entspricht.

• Bei PropertyGrid-Steuerelementen, die im Modus „Hoher Kontrast“ angezeigt werden, und bei denen eine PropertySort-Eigenschaft auf PropertySort.Categorized festgelegt ist, wird nun der Hintergrund von Kategorieheadern in kontrastreicher Farbe angezeigt.

• Bei PropertyGrid-Steuerelementen gibt es eine bessere Unterscheidung zwischen den Symbolleistenelementen mit Fokus und den Symbolleistenelementen, die den aktuellen Wert der PropertySort-Eigenschaft angeben. Dieser Fehlerbehebung besteht aus einer Änderung für Szenarios mit und ohne hohen Kontrast.

• Symbolleistenelemente des PropertyGrid-Steuerelements, die den aktuellen Wert der PropertySort-Eigenschaft angeben, unterstützen das TogglePattern.

• Verbesserte Unterstützung der Unterscheidung der ausgewählten Ausrichtung in der Ausrichtungsauswahl durch die Microsoft-Sprachausgabe.

• Wenn ein leeres PropertyGrid-Steuerelement in einem Formular angezeigt wird, wird dieses nun fokussiert. Dies war zuvor nicht der Fall.

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 waren Text- und Hintergrundfarben nicht kontrastiert und waren schwer zu lesen.
• 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. Jetzt verwenden diese Steuerelemente die vom Betriebssystem definierte Farbe "Deaktivierter Text". Diese Korrektur gilt für Steuerelemente, für die die FlatStyle-Eigenschaft auf einen anderen Wert als FlatStyle.Systemfestgelegt ist. Letztere Steuerelemente werden vom Betriebssystem gerendert.
• DataGridView rendert nun ein sichtbares Rechteck um den Inhalt der Zelle mit dem aktuellen Fokus. 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: Windows 10 hat Werte für einige Systemfarben mit hohem Kontrast geändert. 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 gab die Sprachausgabe diesen Text zweimal aus und las die &-Symbole als Text, obwohl diese für die Benutzer*innen nicht sichtbar sind. Der doppelte 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 sich der Narrator nicht auf deaktivierte Menüelemente fokussieren, um den Inhalt zu lesen.

Betroffene APIs

• ToolStripDropDownButton.CreateAccessibilityInstance()
• DomainUpDown.DomainUpDownAccessibleObject.Name
• MonthCalendar.AccessibilityObject

Windows Presentation Foundation (WPF)

Verbesserungen der Barrierefreiheit in WPF

Einzelheiten

Verbesserungen beim hohen Kontrast

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

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

Screenreader wie der Narrator helfen Personen, die Benutzeroberfläche einer Anwendung zu verstehen, in der Regel, indem sie das UI-Element beschreiben, das gerade den Fokus hat. Wenn sich jedoch ein UI-Element an einer beliebigen Stelle auf dem Bildschirm ändert und nicht im Fokus steht, wird der Benutzer möglicherweise nicht informiert und verpasst wichtige Informationen. LiveRegions sollen dieses Problem 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. Das Bildschirmleseprogramm kann dann entscheiden, wie und wann der Benutzer über diese Änderung informiert werden soll. Die LiveSetting-Eigenschaft sorgt ebenfalls dafür, dass die Sprachausgabe den Benutzer über Änderungen an der Benutzeroberfläche informiert.

Vorschlag

Wie Sie diesen Änderungen zustimmen oder ablehnen

Damit die Anwendung von diesen Änderungen profitieren kann, muss sie auf .NET Framework 4.7.1 oder höher ausgeführt werden. Die Anwendung kann von diesen Änderungen auf eine der folgenden Arten profitieren:

• Auf .NET Framework 4.7.1 abzielen. Dies ist der empfohlene Ansatz. Diese Barrierefreiheitsänderungen sind standardmäßig für WPF-Anwendungen aktiviert, die auf .NET Framework 4.7.1 oder höher abzielen.

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

Anwendungen, die auf das .NET Framework 4.7.1 oder höher abzielen und das Legacy-Barrierefreiheitsverhalten beibehalten möchten, können sich für die Verwendung von Legacy-Barrierefreiheitsfunktionen entscheiden, indem Sie diesen AppContext-Switch explizit auf truesetzen. Eine Übersicht zur Benutzeroberflächenautomatisierung finden Sie unter UI-Automatisierungsübersicht.

Betroffene APIs

• AutomationElementIdentifiers.LiveSettingProperty
• AutomationElementIdentifiers.LiveRegionChangedEvent
• System.Windows.Automation.AutomationLiveSetting
• AutomationProperties.LiveSettingProperty
• AutomationProperties.SetLiveSetting(DependencyObject, AutomationLiveSetting)
• AutomationProperties.GetLiveSetting(DependencyObject)
• AutomationPeer.GetLiveSettingCore()

Selector-Klasse – SelectionChanged-Ereignis und SelectedValue-Eigenschaft

Einzelheiten

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

Apps, die auf .NET Framework 4.7.1 oder höher abzielen, können diese Änderung deaktivieren und das Legacyverhalten verwenden, indem Sie dem Abschnitt <runtime> der Anwendungskonfigurationsdatei Folgendes hinzufügen:

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

Apps, die auf .NET Framework 4.7 oder früher abzielen, aber auf .NET Framework 4.7.1 oder höher ausgeführt werden, können das neue Verhalten aktivieren, indem sie dem Abschnitt <runtime> der Anwendungskonfigurationsdatei die folgende Zeile hinzufügen.

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

Betroffene APIs

• TabControl.SelectedContent
• Selector.SelectionChanged

SelectionChanged-Ereignis und SelectedContent-Eigenschaft von „TabControl“

Einzelheiten

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

Apps, die auf .NET Framework 4.7.1 oder höher abzielen, können diese Änderung deaktivieren und das Legacyverhalten verwenden, indem Sie dem Abschnitt <runtime> der Anwendungskonfigurationsdatei Folgendes hinzufügen:

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

Apps, die auf .NET Framework 4.7 oder früher abzielen, aber auf .NET Framework 4.7.1 oder höher ausgeführt werden, können das neue Verhalten aktivieren, indem sie dem Abschnitt <runtime> der Anwendungskonfigurationsdatei die folgende Zeile hinzufügen.

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

Betroffene APIs

• TabControl.SelectedContent
• Selector.SelectionChanged

Der Standardhashalgorithmus für WPF PackageDigitalSignatureManager ist jetzt SHA256.

Einzelheiten

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 der Standardalgorithmus (PackageDigitalSignatureManager.DefaultHashAlgorithm), der zum Signieren von Teilen eines Pakets verwendet wurde, SHA1. Aufgrund neuer Sicherheitsbedenken mit SHA1 wurde dieser Standardwert ab .NET Framework 4.7.1 in SHA256 geändert. Diese Änderung wirkt sich auf alle Paketsignaturen aus, einschließlich XPS-Dokumente.

Vorschlag

Ein Entwickler, der diese Änderung nutzen möchte, und auf eine Framework-Version unter .NET Framework 4.7.1 abzielt, oder ein Entwickler, der die vorherige Funktionalität benötigt und auf .NET Framework 4.7.1 oder höher abzielt, kann das folgende AppContext-Flag entsprechend festlegen. Der Wert "true" führt dazu, dass SHA1 als Standardalgorithmus verwendet wird; der Wert "false" führt zu SHA256.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.UseSha1AsDefaultHashAlgorithmForDigitalSignatures=true"/>
</runtime>
</configuration>

Betroffene APIs

• PackageDigitalSignatureManager.DefaultHashAlgorithm

Windows Workflow Foundation (WF)

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

Einzelheiten

Die Arbeitsweise von Workflow-Designer von Windows Workflow Foundation (WF) mit Technologien für die Barrierefreiheit wurde verbessert. Zu diesen Verbesserungen gehören die folgenden Ä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 stehen über die Tastatur zur Verfügung:
• Beim Bearbeiten der Eigenschaften einer Aktivität können die Eigenschaftengruppen über die Tastatur reduziert werden, wenn diese zum ersten Mal fokussiert werden.
• Auf Warnungssymbole kann jetzt über die Tastatur zugegriffen werden.
• Auf die Schaltfläche "Weitere Eigenschaften" im Eigenschaftenfenster kann jetzt über die Tastatur zugegriffen werden.
• Tastaturbenutzer können jetzt auf die Kopfzeilenelemente im Bereich "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
• Der Zoomprozentsatz 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 über eine Anwendung mit einem neu gehosteten Workflow-Designer verfügen, kann Ihre Anwendung von diesen Änderungen profitieren, indem Sie eine der folgenden Aktionen ausführen:

• Kompilieren Sie Ihre Anwendung neu, um das .NET Framework 4.7.1 zu verwenden. Diese Barrierefreiheitsänderungen sind 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 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.

.NET Framework 4.7.2

Kern

Zulassen bidirektionaler Unicode-Steuerzeichen in URIs

Einzelheiten

Unicode gibt mehrere spezielle Steuerzeichen an, die zur Festlegung der Textausrichtung verwendet werden. In früheren Versionen von .NET Framework wurden diese Zeichen fälschlicherweise von allen URIs entfernt, auch wenn sie in ihrer prozentcodierten Form vorhanden waren. 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, die auf .NET Framework-Versionen ab 4.7.2 abzielen, ist die Unterstützung für unicode bidirektionale 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, die auf frühere Versionen von .NET Framework abzielen, aber beginnend mit .NET Framework Version 4.7.2 und höher ausgeführt werden, ist die Unterstützung für Unicode-bidirektionale 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>

Betroffene APIs

• System.Uri

DeflateStream verwendet systemeigene APIs für die Dekomprimierung

Einzelheiten

Ab .NET Framework 4.7.2 wurde die Implementierung der Dekomprimierung in der T:System.IO.Compression.DeflateStream-Klasse so geändert, dass standardmäßig systemeigene Windows-APIs verwendet werden. In der Regel führt dies zu einer erheblichen Leistungsverbesserung. 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, darunter:

• Ausnahmemeldungen können unterschiedlich sein. 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 die Dekomprimierung mit systemeigenen APIs das Verhalten Ihrer App negativ beeinflusst, können Sie diese Funktion ausschalten, indem Sie den Schalter Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression zum Abschnitt runtime Ihrer app.config-Datei hinzufügen und auf truefestlegen.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=true" />
  </runtime>
</configuration>

Betroffene APIs

• System.IO.Compression.DeflateStream
• System.IO.Compression.GZipStream

Stellen Sie sicher, dass System.Uri einen konsistenten reservierten Zeichensatz verwendet.

Einzelheiten

In System.Uri sind bestimmte prozentcodierte Zeichen, die manchmal decodiert wurden, jetzt konsistent linkscodiert. Dies geschieht über die Eigenschaften und Methoden hinweg, die auf die Pfad-, Abfrage-, Fragment- oder Userinfo-Komponenten des URI zugreifen. Das Verhalten ändert sich nur, wenn beides zutrifft:

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

Vorschlag

Für Anwendungen, die auf .NET Framework-Versionen ab 4.7.2 abzielen, ist das 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, die auf frühere Versionen von .NET Framework abzielen, aber auf 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>

Betroffene APIs

• System.Uri

Resgen lehnt das Laden von Inhalten aus dem Web ab.

Einzelheiten

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

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

Einzelheiten

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 sind Quelldatei- und Zeileninformationen bei verwendung tragbarer PDBs nicht verfügbar, auch wenn sie explizit angefordert werden.

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>

Betroffene APIs

• StackTrace(Boolean)
• StackTrace(Exception, Boolean)
• StackTrace(Exception, Int32, Boolean)

Windows Forms

Verbesserungen der Barrierefreiheit in den Windows Forms-Steuerelementen für .NET 4.7.2

Einzelheiten

Windows Forms Framework verbessert die Funktionsweise mit Barrierefreiheitstechnologien, um Windows Forms-Kunden besser zu unterstützen. Dazu gehören die folgenden Änderungen:

• Änderungen zur Verbesserung der Anzeige im Modus "Hoher 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 auf eine der folgenden Arten profitieren:

• Es wird für .NET Framework 4.7.2 neu kompiliert. Diese Barrierefreiheitsänderungen sind in Windows Forms-Anwendungen, die auf .NET Framework 4.7.2 oder höher abzielen, standardmäßig aktiviert.
• 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. Anwendungen, die auf das .NET Framework 4.7.2 oder höher abzielen und das alte Barrierefreiheitsverhalten beibehalten möchten, können sich für die Nutzung von Legacy-Barrierefreiheitsfunktionen entscheiden, indem sie diesen AppContext-Switch explizit auf truefestlegen.

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 waren Text- und Hintergrundfarben nicht kontrastiert und waren schwer zu lesen.
• 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 im Modus "Hoher Kontrast" standardmäßig vom Betriebssystem definierte Farben für die Eigenschaft DataGridViewLinkCell.LinkColor. HINWEIS: Windows 10 hat Werte für einige Systemfarben mit hohem Kontrast geändert. 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 ToolStripMenuItem-Eigenschaftensatz eines Enabled 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

• Zeilen in einer DataGridView können jetzt mithilfe der Tastatur sortiert werden. Jetzt kann ein Benutzer die F3-TASTE verwenden, um nach der aktuellen Spalte zu sortieren.
• Wenn der DataGridView.SelectionMode auf DataGridViewSelectionMode.FullRowSelect festgelegt ist, ändert sich die Farbe der Spaltenüberschrift, um die aktuelle Spalte anzugeben, wenn der Benutzer mit der TABULATORTASTE die Zellen in der aktuellen Zeile durchläuft.
• Die DataGridViewCell.DataGridViewCellAccessibleObject.Parent-Eigenschaft gibt jetzt das richtige übergeordnete Steuerelement zurück.

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

• Die untergeordneten Elemente des Steuerelements PropertyGrid geben jetzt nur dann true für die Eigenschaft IsReadOnlyProperty zurück, wenn ein PropertyGrid-Element aktiviert ist.

• Die untergeordneten Elemente des PropertyGrid-Steuerelements geben jetzt nur dann false für die IsEnabledProperty-Eigenschaft zurück, wenn ein PropertyGrid-Element vom Benutzer geändert werden kann. Eine Übersicht über die Benutzeroberflächenautomatisierung finden Sie in der Übersicht über die Benutzeroberflächenautomatisierung.

  Verbesserte Tastaturnavigation

• ToolStripButton lässt nun den Fokus zu, wenn das Element in einem ToolStripPanel enthalten ist, für das die TabStop-Eigenschaft auf true festgelegt ist.

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

Einzelheiten

In .NET Framework 4.7.1 und früheren Versionen gibt die eigenschaft ContextMenuStrip.SourceControl fälschlicherweise NULL zurück, wenn der Benutzer das Menü aus 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

So können Sie sich für diese Änderungen an- oder abmelden Damit eine Anwendung von diesen Änderungen profitieren kann, muss sie auf dem .NET Framework 4.7.2 oder höher ausgeführt werden. Die Anwendung kann von diesen Änderungen auf eine der folgenden Arten profitieren:

• Sie zielt auf .NET Framework 4.7.2 ab. Diese Änderung ist in Windows Forms-Anwendungen, die auf .NET Framework 4.7.2 oder höher abzielen, standardmäßig aktiviert.
• 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.Windows.Forms.UseLegacyContextMenuStripSourceControlValue=false"/>
</runtime>

Anwendungen, die auf .NET Framework 4.7.2 oder höher abzielen und das Legacyverhalten beibehalten möchten, können sich für die Verwendung des Legacy-Quellcodeverwaltungswerts entscheiden, indem sie diesen AppContext-Switch explizit auf truefestlegen.

Betroffene APIs

• ContextMenuStrip.SourceControl

PrivateFontCollection.AddFontFile-Methode veröffentlicht Schriftartressourcen.

Einzelheiten

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

So können Sie sich für diese Änderungen an- oder abmelden Damit eine Anwendung von diesen Änderungen profitieren kann, muss sie auf dem .NET Framework 4.7.2 oder höher ausgeführt werden. Die Anwendung kann von diesen Änderungen auf eine der folgenden Arten profitieren:

• Es wird für .NET Framework 4.7.2 neu kompiliert. Diese Änderung ist in Windows Forms-Anwendungen, die auf .NET Framework 4.7.2 oder höher abzielen, standardmäßig aktiviert.
• 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>

Anwendungen, die auf .NET Framework 4.7.2 oder höher abzielen und das Legacyverhalten beibehalten möchten, können sich entscheiden, keine Schriftartressourcen freizugeben, indem Sie diesen AppContext-Switch explizit auf truefestlegen.

Betroffene APIs

• PrivateFontCollection.AddFontFile(String)
• FontCollection.Dispose()

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

Einzelheiten

In .NET Framework 4.7.1 und früheren Versionen wird die DomainUpDown-Aktion des DomainUpDown.UpButton()-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 Aktionen DomainUpDown.UpButton() und DomainUpDown.DownButton() in diesem Szenario unabhängig voneinander und bleiben synchron.

Vorschlag

Damit eine Anwendung von diesen Änderungen profitieren kann, muss sie auf .NET Framework 4.7.2 oder höher ausgeführt werden. Die Anwendung kann von diesen Änderungen auf eine der folgenden Arten profitieren:

• Es wird für .NET Framework 4.7.2 neu kompiliert. Diese Änderung ist in Windows Forms-Anwendungen, die auf .NET Framework 4.7.2 oder höher abzielen, standardmäßig aktiviert.
• 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>

Betroffene APIs

• DomainUpDown.UpButton()
• DomainUpDown.DownButton()

Windows Presentation Foundation (WPF)

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

Einzelheiten

Erwägen Sie 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 sich für alle frühzeitigen Verbesserungen der Barrierefreiheit entscheiden, um die späteren Verbesserungen zu erhalten. Ein Entwickler, der die frühere Funktionalität benötigt und auf .NET 4.7.2 oder höher abzielt, kann das folgende AppContext-Flag auf "true" setzen, um die Änderung zu deaktivieren. Mit anderen Worten, sowohl der Schalter Switch.UseLegacyAccessibilityFeatures als auch der Schalter Switch.UseLegacyAccessibilityFeatures.2 müssen eingestellt werden.

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

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

Einzelheiten

Die WPF-MarkupCompiler stellt Kompilierungsdienste für XAML-Markupdateien bereit. In .NET Framework 4.7.1 und früheren Versionen war der für Prüfsummen verwendete Standardhashalgorithmus SHA1. Aufgrund neuer Sicherheitsbedenken mit SHA1 wurde dieser Standardwert ab .NET Framework 4.7.2 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 auf .NET Framework 4.7.2 oder höher ausgerichtet ist und das SHA1-Hashingverhalten 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>

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

Einzelheiten

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. Solche Anwendungen sollten darauf achten, die Lebensdauer der Dispatcher ordnungsgemäß zu verwalten.

Vorschlag

In .NET Framework 4.7.2 und höheren Versionen können Entwickler diesen Fix deaktivieren, um Timing-Probleme zu lindern (aber nicht zu beseitigen), die aufgrund der Bereinigungsänderung auftreten können. Um die Änderung in der Bereinigung zu deaktivieren, verwenden Sie das folgende AppContext-Flag.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotInvokeInWeakEventTableShutdownListener=true"/>
</runtime>
</configuration>

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

Einzelheiten

Angenommen, Sie verfügen über eine ADO-Sammlung von Elementen vom Typ Ordermit einer Beziehung namens "OrderDetails", die sie mit einer Sammlung von Elementen vom Typ Detail über den Primärschlüssel "OrderID" verbindet. 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. Die Verhaltensänderung tritt auf, 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). Aber was geschieht 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 die Sammlung D auf eine andere Weise erstellt wird: durch Aufrufen der ADO-Methode DataRowView.CreateChildView(DataRelation, Boolean), wobei das Argument followParent auf truefestgelegt wird.

Vorschlag

Eine App erhält das neue Verhalten mithilfe des folgenden AppContext-Schalters.

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

Der Switch ist standardmäßig auf true (altes Verhalten) für Apps festgelegt, die auf .NET 4.7.1 oder darunter abzielen, und auf false (neues Verhalten) für Apps, die auf .NET 4.7.2 oder höher abzielen.

WPF-FocusVisual für RadioButton und CheckBox wird jetzt korrekt angezeigt, wenn die Steuerelemente keinen Inhalt haben.

Einzelheiten

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 die Steuerelemente keinen Inhalt haben. 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 für .NET Framework 4.7.2, der das Verhalten in .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 nutzen möchte, muss bei einer Ausrichtung auf eine Frameworkversion unter .NET 4.7.2 die folgenden AppContext-Flags festlegen. Beachten Sie, dass alle Flags entsprechend gesetzt werden müssen und die installierte Version von .NET Framework mindestens 4.7.2 sein muss. WPF-Anwendungen müssen alle früheren Verbesserungen der Barrierefreiheit aktivieren, um die neuesten Verbesserungen zu erhalten. 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>

Die Textauswahl von WPF TextBox/PasswordBox folgt nicht den Systemfarben.

Einzelheiten

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, der 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>

Windows Workflow Foundation (WF)

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

Einzelheiten

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 Arbeitsaufgaben werden nicht als Teil der Verarbeitung der TransactedCancel/TransactedTerminate Anforderung ausgeführt. Da die Workflowdienstinstanz ausgelastet ist, weil sie auf die Erledigung der anderen ausstehenden WCF-Anforderung wartet, bleibt das erstellte Arbeitspaket 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. Ein Wert von true gibt an, dass die Transaktion ignoriert werden soll, wodurch der Stapelüberlauf vermieden wird. Der Standardwert dieses AppSettings ist false, sodass vorhandene Workflowdienstinstanzen nicht betroffen sind.

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 das Problem nicht auftritt, müssen Sie dies nicht tun.