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

  • Artikel

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

.NET Framework 4.6

ASP.NET

HtmlTextWriter rendert das Element <br/> nicht ordnungsgemäß

Details

Ab .NET Framework 4.6 fügt der Aufruf von RenderBeginTag(String) und RenderEndTag() mit einem <BR />-Element ordnungsgemäß nur ein (anstatt zwei) <BR /> ein.

Vorschlag

Wenn eine App vom zusätzlichen <BR />-Tag abhängig ist, sollte RenderBeginTag(String) ein zweites Mal aufgerufen werden. Beachten Sie, das sich diese Verhaltensänderung nur auf Apps mit der Zielplattform .NET Framework 4.6 oder höher auswirkt. Eine weitere Möglichkeit ist daher die Ausrichtung auf eine vorherige Version von .NET Framework, mit der das alte Verhalten genutzt werden kann.

name Wert
Bereich Microsoft Edge
Version 4.6
Typ Neuzuweisung

Betroffene APIs

ClickOnce

Mit ClickOnce veröffentlichte Apps, die ein SHA-256-Codesignaturzertifikat verwenden, verursachen unter Windows 2003 möglicherweise einen Fehler

Details

Die ausführbare Datei ist mit SHA256 signiert. Früher wurde sie mit SHA1 signiert, unabhängig davon, ob das Codesignaturzertifikat SHA-1 oder SHA-256 war. Dies gilt für:

  • Alle Anwendungen, die mit Visual Studio 2012 oder höher erstellt wurden.
  • Anwendungen, die mit Visual Studio 2010 oder früher auf Systemen mit vorhandenem .NET Framework 4.5 erstellt wurden. Darüber hinaus wird das ClickOnce-Manifest, wenn .NET Framework 4.5 oder höher vorhanden ist, auch mit SHA-256 für SHA-256-Zertifikate signiert, unabhängig von der .NET Framework-Version, mit der es kompiliert wurde.

Vorschlag

Die Änderung bei der Signierung der ausführbaren ClickOnce-Datei betrifft nur Windows Server 2003-Systeme. Für diese ist die Installation von KB 938397 erforderlich. Die Änderung bei der Signierung des Manifests mit SHA-256, selbst wenn eine App auf .NET Framework 4.0 oder frühere Versionen abzielt, führt eine Laufzeitabhängigkeit von .NET Framework 4.5 oder einer höheren Version ein.

name Wert
Bereich Microsoft Edge
Version 4.5
Typ Neuzuweisung

ClickOnce unterstützt SHA-256 auf Apps, die auf 4.0 ausgerichtet sind

Details

Bisher war für ClickOnce-Apps mit einem mit SHA-256 signierten Zertifikat auch dann .NET Framework 4.5 oder höher erforderlich, wenn die App auf 4.0 ausgelegt war. Nun können ClickOnce-Apps, die auf .NET Framework 4.0 ausgelegt sind, auch dann in .NET Framework 4.0 ausgeführt werden, wenn sie mit SHA-256 signiert sind.

Vorschlag

Diese Änderung beseitigt diese Abhängigkeit und ermöglicht die Verwendung von SHA-256-Zertifikaten zum Signieren von ClickOnce-Apps, die auf .NET Framework 4 und frühere Versionen ausgerichtet sind.

name Wert
Bereich Gering
Version 4.6
Typ Neuzuweisung

Core

CurrentCulture und CurrentUICulture werden über mehrere Aufgaben übertragen

Details

Ab .NET Framework 4.6 werden System.Globalization.CultureInfo.CurrentCulture und System.Globalization.CultureInfo.CurrentUICulture im System.Threading.ExecutionContext-Objekt des Threads gespeichert, das über mehrere asynchrone Vorgänge übertragen wird. Das heißt, dass Änderungen an System.Globalization.CultureInfo.CurrentCulture oder System.Globalization.CultureInfo.CurrentUICulture sich auf Aufgaben auswirken, die später asynchron ausgeführt werden. Dieses Verhalten weicht von demjenigen früherer .NET Framework-Versionen ab (die System.Globalization.CultureInfo.CurrentCulture und System.Globalization.CultureInfo.CurrentUICulture in allen asynchronen Aufgaben zurückgesetzt haben).

Vorschlag

Apps die von dieser Änderung betroffen sind, können diese möglicherweise umgehen, indem die gewünschte System.Globalization.CultureInfo.CurrentCulture oder System.Globalization.CultureInfo.CurrentUICulture als erster Vorgang in einer asynchronen Aufgabe festgelegt wird. Alternativ können Sie sich für das alte Verhalten (keine Weitergabe von System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) entscheiden, indem Sie die folgende Kompatibilitätsoption festlegen:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Dieses Problem wurde von WPF in .NET Framework 4.6.2 behoben. Es wurde ebenfalls in .NET Framework 4.6 und 4.6.1 durch KB 3139549 behoben. Apps mit der Zielplattform .NET Framework 4.6 oder höher erhalten automatisch das richtige Verhalten in WPF-Anwendungen (System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture), das über Dispatcher-Vorgänge hinweg beibehalten werden würde.

name Wert
Bereich Gering
Version 4.6
Typ Neuzuweisung

Betroffene APIs

ETW-Ereignisnamen können sich nicht nur durch das Suffix „Start“ oder „Stop“ unterscheiden

Details

In .NET Framework 4.6 und 4.6.1 löst die Runtime ArgumentException aus, wenn zwei Ereignisnamen der Ereignisablaufverfolgung für Windows (ETW) sich lediglich durch das Suffix „Start“ oder „Stop“ unterscheiden (z. B. wenn ein Ereignis mit LogUser benannt ist und das andere mit LogUserStart). In diesem Fall kann die Runtime die Ereignisquelle nicht erstellen, die dann keine Protokollierung durchführen kann.

Vorschlag

Stellen Sie sicher, dass zwei Ereignisnamen sich nicht nur durch das Suffix „Start“ oder „Stop“ unterscheiden, um die Ausnahme zu verhindern. Diese Anforderung wird mit .NET Framework 4.6.2 entfernt. Die Runtime kann Ereignisnamen unterscheiden, die sich nur durch das Suffix „Start“ oder „Stop“ unterscheiden.

name Wert
Bereich Microsoft Edge
Version 4.6
Typ Neuzuweisung

Entity Framework

Beim Erstellen einer Entity Framework-EDMX-Datei mit Visual Studio 2013 kann der Fehler MSB4062 auftreten, wenn die Aufgabe „EntityDeploySplit“ oder „EntityClean“ verwendet wird

Details

MSBuild 12.0-Tools (enthalten in Visual Studio 2013) haben die MSBuild-Dateispeicherorte geändert, wodurch ältere Entity Framework-Zieldateien ungültig geworden sind. Das führt dazu, dass EntityDeploySplit- und EntityClean-Aufgaben fehlschlagen, da sie Microsoft.Data.Entity.Build.Tasks.dll nicht finden können. Beachten Sie, dass dieses Problem aufgrund einer Änderung des Toolsets (MSBuild/VS) und nicht aufgrund einer Änderung an .NET Framework auftritt. Es tritt nur beim Upgrade von Entwicklertools und nicht beim Aktualisieren von .NET Framework auf.

Vorschlag

Die Entity Framework-Zieldateien wurden so korrigiert, dass sie mit dem neuen MSBuild-Layout genutzt werden können, das ab .NET Framework 4.6 verwendet wird. Ein Upgrade auf diese Version von .NET Framework wird dieses Problem beheben. Alternativ können Sie diese Problemumgehung verwenden, um die Zieldateien direkt zu patchen.

name Wert
Bereich Hauptversion
Version 4.5.1
Typ Neuzuweisung

JIT

Die IL-ret-Anweisung ist in einem try-Block nicht zulässig

Details

Im Gegensatz zum JIT64-Compiler lässt (in .NET Framework 4.6 verwendets) RyuJIT keine IL-ret-Anweisung in einem „try“-Block zu. Eine Rückgabe innerhalb eines try-Block ist gemäß der ECMA-335-Spezifikation nicht zulässig, und kein bekannter verwalteter Compiler generiert eine solche IL. Allerdings führt der JIT64-Compiler solche IL aus, wenn sie mithilfe von Reflektionsausgabe generiert wurde.

Vorschlag

Wenn eine App eine IL generiert, die einen „ret“-Opcode in einem „try“-Block enthält, kann die App auf .NET Framework 4.5 ausgelegt werden, um den alten JIT-Compiler zu verwenden und dieses Problem zu vermeiden. Alternativ kann die generierte IL aktualisiert und nach dem try-Block zurückgegeben werden.

name Wert
Bereich Microsoft Edge
Version 4.6
Typ Neuzuweisung

Neuer 64-Bit-JIT-Compiler in .NET Framework 4.6

Details

Ab .NET Framework 4.6 wird ein neuer 64-Bit-JIT-Compiler für die Just-in-Time-Kompilierung verwendet. In einigen Fällen wird eine unerwartete Ausnahme ausgelöst oder ein anderes Verhalten beobachtet als bei der Ausführung des 32-Bit-Compilers oder des älteren 64-Bit-JIT-Compilers. Diese Änderung wirkt sich nicht auf den 32-Bit-JIT-Compiler aus. Die bekannten Unterschiede umfassen folgende Punkte:

  • Unter bestimmten Umständen kann ein Unboxingvorgang in Releasebuilds mit aktivierter Optimierung eine NullReferenceException-Ausnahme auslösen.
  • In manchen Fällen kann bei der Ausführung von Produktionscode in einem großen Methodentext eine StackOverflowException-Ausnahme ausgelöst werden.
  • Unter bestimmten Bedingungen werden in Releasebuilds an eine Methode übergebene Strukturen als Verweistypen statt als Werttypen behandelt. Eins der Anzeichen dieses Problems besteht darin, dass die einzelnen Elemente einer Sammlung in unerwarteter Reihenfolge angezeigt werden.
  • Unter bestimmten Bedingungen ist der Vergleich von UInt16-Werten mit festgelegtem hohem Bit fehlerhaft, wenn Optimierung aktiviert ist.
  • Unter bestimmten Umständen, insbesondere beim Initialisieren von Arraywerten, kann die Speicherinitialisierung durch die IL-Anweisung OpCodes.Initblk mit einem falschen Wert erfolgen. Dies kann entweder zu einem Ausnahmefehler oder zu einer falschen Ausgabe führen.
  • Unter bestimmten seltenen Bedingungen kann ein bedingter Bittest den falschen Boolean-Wert zurückgeben oder eine Ausnahme auslösen, wenn Compileroptimierungen aktiviert sind.
  • Wenn unter bestimmten Umständen eine if-Anweisung für die Prüfung auf eine Bedingung vor dem Eintritt in einen try-Block und beim Verlassen eines try-Blocks erfolgt und die gleiche Bedingung im catch- oder finally-Block ausgewertet wird, entfernt der neue 64-Bit-JIT-Compiler beim Optimieren von Code die if-Bedingung aus dem catch- oder finally-Block. Daher wird Code innerhalb der if-Anweisung im catch- oder finally-Block ohne Bedingung ausgeführt.

Vorschlag

Entschärfung bekannter Probleme
Wenn bei Ihnen die oben aufgeführten Probleme auftreten, können Sie darauf mit einer der folgenden Maßnahmen reagieren:

  • Ausführen eines Upgrades auf .NET Framework 4.6.2. Der neue 64-Bit-Compiler, der in .NET Framework 4.6.2 enthalten ist, behebt jedes dieser bekannten Probleme.

  • Stellen Sie sicher, dass ihre Windows-Version auf dem aktuellen Stand ist, indem Sie Windows Update ausführen. Serviceupdates für .NET Framework 4.6 und 4.6.1 beheben jedes dieser Probleme, mit Ausnahme der NullReferenceException-Ausnahme bei Unboxingvorgängen.

  • Kompilieren Sie mit dem älteren 64-Bit-JIT-Compiler. Informationen zum Vorgehen dazu finden Sie unter Entschärfung anderer Probleme. Entschärfung anderer Probleme
    Wenn Sie andere Unterschiede im Verhalten zwischen Code, der mit dem älteren 64-Bit-Compiler kompiliert wurde, gegenüber mit dem neuen 64-Bit-JIT-Compiler kompiliertem Code oder zwischen den Debug- und Releaseversionen Ihrer App feststellen, die beide mit dem neuen 64-Bit-JIT-Compiler kompiliert wurden, können Sie folgendermaßen vorgehen, um Ihre App mit dem älteren 64-Bit-JIT-Compiler zu kompilieren:

  • Sie können der Konfigurationsdatei Ihrer Anwendung auf Anwendungsbasis das <-Element hinzufügen. Die folgende Anweisung deaktiviert die Kompilierung mit dem neuen 64-Bit-JIT-Compiler und verwendet stattdessen den 64-Bit-Legacy-JIT-Compiler.

    <?xml version ="1.0"?>
<configuration>
  <runtime>
   <useLegacyJit enabled="1" />
  </runtime>
</configuration>

  • Auf Benutzerbasis können Sie dem HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework-Wert der Registrierung einen REG_DWORD-Wert mit dem Namen useLegacyJit hinzufügen. Der Wert 1 aktiviert den 64-Bit-Legacy-JIT-Compiler, der Wert 0 deaktiviert ihn und aktiviert stattdessen den neuen 64-Bit-JIT-Compiler.

  • Auf Computerbasis können Sie dem HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework-Schlüssel der Registrierung einen REG_DWORD-Wert mit dem Namen useLegacyJit hinzufügen. Der Wert 1 aktiviert den 64-Bit-Legacy-JIT-Compiler, der Wert 0 deaktiviert ihn und aktiviert stattdessen den neuen 64-Bit-JIT-Compiler. Ferner können Sie uns über das Problem informieren, indem Sie einen Bug auf Microsoft Connect melden.

name Wert
Bereich Microsoft Edge
Version 4.6
Typ Neuzuweisung

Netzwerk

EKU-OID-Zertifikatüberprüfung

Details

Ab .NET Framework 4.6 führt die Klasse SslStream oder ServicePointManager eine Überprüfung mithilfe der erweiterten Schlüsselverwendung (EKU) und unter Berücksichtigung von Objektbezeichnern (OIDs) durch. Eine EKU-Erweiterung ist eine Sammlung von OIDs, die Anwendungen kennzeichnen, die den Schlüssel verwenden. Bei der EKU-OID-Überprüfung werden Remotezertifikatrückrufe verwendet, um sicherzustellen, dass das Remotezertifikat über die richtigen OIDs für den entsprechenden Zweck verfügt.

Vorschlag

Wenn diese Änderung nicht erwünscht ist, können Sie die EKU-OID-Zertifikatüberprüfung deaktivieren, indem Sie die folgende Option zu <AppContextSwitchOverrides> im ` Ihrer Anwendungskonfigurationsdatei hinzufügen:

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

Wichtig

Diese Einstellung wird lediglich aus Gründen der Abwärtskompatibilität bereitgestellt. Abgesehen davon wird die Verwendung nicht empfohlen.

name Wert
Bereich Gering
Version 4.6
Typ Neuzuweisung

Betroffene APIs

Nur die Protokolle TLS 1.0, 1.1 und 1.2 werden in System.Net.ServicePointManager und System.Net.Security.SslStream unterstützt

Details

Ab .NET Framework 4.6 dürfen die Klassen ServicePointManager und SslStream nur eines der folgenden drei Protokolle verwenden: TLS 1.0, TLS 1.1 oder TLS 1.2. Weder das SSL3.0-Protokoll noch das RC4-Verschlüsselungsverfahren werden unterstützt.

Vorschlag

Die empfohlene Risikominderung besteht darin, für die serverseitige App ein Upgrade auf TLS 1.0, TLS 1.1 oder TLS 1.2 vorzunehmen. Wenn dies nicht möglich ist oder die Client-Apps fehlerhaft sind, kann die Klasse System.AppContext verwendet werden, um das Feature auf zwei verschiedene Art und Weisen abzuwählen:

  • durch programmgesteuertes Festlegen von Kompatibilitätsoptionen für System.AppContext, wie hier beschrieben wird.
  • Durch Hinzufügen der folgenden Zeile zum Abschnitt <runtime> der app.config-Datei:
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
name Wert
Bereich Gering
Version 4.6
Typ Neuzuweisung

Betroffene APIs

TLS 1.x übergibt standardmäßig das Flag SCH_SEND_AUX_RECORD an die zugrunde liegende SCHANNEL-API

Details

Bei Nutzung von TLS 1 verwendet .NET Framework die zugrunde liegende Windows-SCHANNEL-API. Ab .NET Framework 4.6 wird das Flag SCH_SEND_AUX_RECORD standardmäßig an SCHANNEL übergeben. Dies führt dazu, dass SCHANNEL die zu verschlüsselnden Daten in zwei getrennte Datensätze aufteilt, den ersten als Einzelbyte und den zweiten als n-1 Bytes. In seltenen Fällen wird dadurch die Kommunikation zwischen Clients und vorhandenen Servern unterbrochen, die davon ausgehen, dass sich die Daten in einem einzigen Datensatz befinden.

Vorschlag

Wenn diese Änderung die Kommunikation mit einem vorhandenen Server unterbricht, können Sie das Senden des Flags SCH_SEND_AUX_RECORD deaktivieren und das vorherige Verhalten wiederherstellen, mit dem Daten nicht in separate Datensätze aufgeteilt werden, indem Sie dem Element <AppContextSwitchOverrides> den folgenden Parameter im Abschnitt <runtime> Ihrer Anwendungskonfigurationsdatei hinzufügen:

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

Wichtig

Diese Einstellung wird lediglich aus Gründen der Abwärtskompatibilität bereitgestellt. Abgesehen davon wird die Verwendung nicht empfohlen.

name Wert
Bereich Microsoft Edge
Version 4.6
Typ Neuzuweisung

Betroffene APIs

Windows Communication Foundation (WCF)

Das Aufrufen von CreateDefaultAuthorizationContext mit einem NULL-Argument wurde geändert

Details

Die Implementierung des System.IdentityModel.Policy.AuthorizationContext-Elements, das von einem Aufruf von System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) mit dem NULL-Wert als Argument „authorizationPolicies“ zurückgegeben wurde, hat seine Implementierung in .NET Framework 4.6 geändert.

Vorschlag

In seltenen Fällen liegen bei WCF-Apps, die die benutzerdefinierte Authentifizierung verwenden, möglicherweise Verhaltensunterschiede vor. In derartigen Fällen gibt es zwei Möglichkeiten, um das vorherige Verhalten wiederherzustellen:

  • Kompilieren Sie Ihre App erneut, damit sie auf eine frühere Version als .NET Framework 4.6 abzielt. Verwenden Sie für mithilfe von IIS gehosteten Diensten das <httpRuntime targetFramework="x.x">-Element, um auf eine frühere Version von .NET Framework abzuzielen.

  • Fügen Sie dem Abschnitt <appSettings> Ihrer Datei „app.config“ die folgende Zeile hinzu:

    <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
name Wert
Bereich Gering
Version 4.6
Typ Neuzuweisung

Betroffene APIs

Windows Forms

Icon.ToBitmap konvertiert Symbole mit PNG-Frames erfolgreich in Bitmap-Objekte

Details

Beginnend mit den Apps für .NET Framework 4.6 konvertiert die Icon.ToBitmap-Methode Symbole mit PNG-Bildern erfolgreich in „Bitmap“-Objekte.

In Apps, die auf .NET Framework 4.5.2 und frühere Versionen ausgelegt sind, löst die Icon.ToBitmap-Methode eine ArgumentOutOfRangeException-Ausnahme aus, wenn das Icon-Objekt PNG-Bilder enthält.

Diese Änderung betrifft Apps, die für .NET Framework 4.6 neu kompiliert werden und eine spezielle Behandlung für die ArgumentOutOfRangeException implementieren, die ausgelöst wird, wenn ein „Icon“-Objekt PNG-Bilder aufweist. Bei der Ausführung unter .NET Framework 4.6 wird die Konvertierung erfolgreich durchgeführt und eine ArgumentOutOfRangeException wird nicht mehr ausgelöst. Daher wird der Ausnahmehandler nicht mehr aufgerufen.

Vorschlag

Wenn dieses Verhalten nicht erwünscht ist, können Sie das vorherige Verhalten beibehalten, indem Sie das folgende Element zum <runtime>-Abschnitt Ihrer app.config-Datei hinzufügen:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true" />

Wenn die Datei „app.config“ bereits das AppContextSwitchOverrides-Element enthält, muss der neue Wert wie folgt mit dem Attribut zusammengeführt werden:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
name Wert
Bereich Gering
Version 4.6
Typ Neuzuweisung

Betroffene APIs

Windows Presentation Foundation (WPF)

CurrentCulture wird zwischen WPF-Dispatcher-Vorgängen nicht beibehalten

Details

Ab .NET Framework 4.6 gehen Änderungen an System.Globalization.CultureInfo.CurrentCulture oder System.Globalization.CultureInfo.CurrentUICulture, die innerhalb eines System.Windows.Threading.Dispatcher-Elements vorgenommen werden, am Ende des Verteilungsvorgangs verloren. Auf ähnliche Weise werden Änderungen an System.Globalization.CultureInfo.CurrentCulture oder System.Globalization.CultureInfo.CurrentUICulture außerhalb eines Verteilungsvorgangs möglicherweise nicht übernommen, wenn der Vorgang ausgeführt wird. In der Praxis bedeutet dies, dass Änderungen an System.Globalization.CultureInfo.CurrentCulture und System.Globalization.CultureInfo.CurrentUICulture möglicherweise zwischen Rückrufen der WPF-Benutzeroberfläche und anderem Code in einer WPF-Anwendung nicht übertragen werden. Der Grund dafür ist eine Änderung in System.Threading.ExecutionContext, durch die System.Globalization.CultureInfo.CurrentCulture und System.Globalization.CultureInfo.CurrentUICulture im Ausführungskontext gespeichert werden. Diese Änderung betrifft Apps mit der Zielplattform .NET Framework 4.6 und höher. WPF-Verteilungsvorgänge speichern den Ausführungskontext, der dazu verwendet wurde, um den Vorgang zu beginnen und stellen den vorherigen Kontext wieder her, wenn der Vorgang abgeschlossen ist. Da System.Globalization.CultureInfo.CurrentCulture und System.Globalization.CultureInfo.CurrentUICulture jetzt Bestandteil dieses Kontexts sind, bleiben innerhalb eines Dispatchervorgangs an ihnen vorgenommene Änderungen außerhalb des Vorgangs nicht erhalten.

Vorschlag

Von dieser Änderung betroffene Apps können dieses Problem möglicherweise umgehen, indem das gewünschte System.Globalization.CultureInfo.CurrentCulture- oder System.Globalization.CultureInfo.CurrentUICulture-Element in einem Feld gespeichert wird und für alle Vorgangstexte der Verteilung (einschließlich der Rückrufereignishandler für Benutzeroberflächenereignisse) geprüft wird, ob das richtige System.Globalization.CultureInfo.CurrentCulture- und System.Globalization.CultureInfo.CurrentUICulture-Element festgelegt ist. Da die ExecutionContext-Änderung, die dieser WPF-Änderung zugrunde liegt, nur Apps betrifft, die auf .NET Framework 4.6 oder höher ausgerichtet sind, kann dieser Fehler alternativ vermieden werden, indem .NET Framework 4.5.2 als Zielplattform verwendet wird. Apps mit der Zielplattform .NET Framework 4.6 oder höher können dieses Problem ebenfalls umgehen, indem die folgende Kompatibilitätsoption festgelegt wird:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Dieses Problem wurde von WPF in .NET Framework 4.6.2 behoben. Es wurde ebenfalls in .NET Framework 4.6 und 4.6.1 durch KB 3139549 behoben. Apps mit der Zielplattform .NET Framework 4.6 oder höher erhalten automatisch das richtige Verhalten in WPF-Anwendungen (System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture), das über Dispatcher-Vorgänge hinweg beibehalten werden würde.

name Wert
Bereich Gering
Version 4.6
Typ Neuzuweisung

Die WPF-Layoutglättung von Rändern wurde geändert

Details

Die Art und Weise, wie Ränder und die Grenzen und der Hintergrund darin geglättet werden, hat sich geändert. Auswirkungen durch diese Änderung:

  • Die Breite oder Höhe der Elemente vergrößert oder verkleinert sich allenfalls um einen Pixel.
  • Die Platzierung eines Objekts kann sich allenfalls um einen Pixel verschieben.
  • Zentrierte Elemente können sich vertikal oder horizontal um allenfalls ein Pixel von der Mitte verschieben. Standardmäßig wird dieses neue Layout nur für Apps aktiviert, die auf .NET Framework 4.6 abzielen.

Vorschlag

Da durch diese Änderung das Clipping die rechte oder Unterseite von WPF-Steuerelementen bei hohen DPIs beseitigt wird, können Apps, die auf frühere Versionen von .NET Framework abzielen, aber auf .NET Framework 4.6 ausgeführt werden, dieses neue Verhalten übernehmen, sofern die folgende Zeile zum Abschnitt <runtime> der Datei „app.config“ hinzugefügt wird:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />

Apps, die auf .NET Framework 4.6 ausgelegt sind, aber WPF-Steuerelemente zum Rendern mithilfe des vorherigen Layoutalgorithmus verwenden möchten, können dies vornehmen, sofern die folgende Zeile zum Abschnitt <runtime> der Datei „app.config“ hinzugefügt wird:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />
name Wert
Bereich Gering
Version 4.6
Typ Neuzuweisung

XML, XSLT

XmlWriter löst bei ungültigen Ersatzzeichenpaaren Ausnahmen aus

Details

Bei Apps, die auf .NET Framework 4.5.2 oder niedrigere Versionen abzielen, löst das Schreiben eines ungültigen Ersatzzeichenpaars mithilfe der Fallbackbehandlung nicht immer eine Ausnahme aus. Bei Apps mit der Zielplattform .NET Framework 4.6 löst der Versuch, ein ungültiges Ersatzzeichenpaar zu schreiben, eine System.ArgumentException aus.

Vorschlag

Falls erforderlich, kann dieser Fehler umgangen werden, indem als Zielplattform.NET Framework 4.5.2 oder eine ältere Version verwendet wird. Alternativ können ungültige Ersatzzeichenpaare vor dem Schreiben auch zuerst in gültigen XML-Code umgewandelt werden.

name Wert
Bereich Microsoft Edge
Version 4.6
Typ Neuzuweisung

Betroffene APIs

Die XSD-Schemaüberprüfung erkennt jetzt Verstöße gegen eindeutige Einschränkungen richtig, wenn Verbundschlüssel verwendet werden und ein Schlüssel leer ist

Details

Versionen von .NET Framework vor 4.6 wiesen einen Fehler auf, der dazu geführt hat, dass die XSD-Validierung eindeutige Einschränkungen für Verbundschlüssel nicht erkannt hat, wenn einer der Schlüssel leer war. Dieses Problem wurde in .NET Framework 4.6 behoben. Dies führt zu einwandfreieren Validierung, aber möglicherweise auch dazu, dass einige XML-Daten nicht überprüft werden, die zuvor überprüft wurden.

Vorschlag

Wenn eine weniger strenge Überprüfung für .NET Framework 4.0 erforderlich ist, kann die überprüfende Anwendung auf Version 4.5 (oder niedriger) von .NET Framework ausgerichtet werden. Wenn eine Neuausrichtung auf .NET Framework 4.6 erfolgt, sollte jedoch eine Code Review erfolgen, um sicherzustellen, dass die Validierung doppelter Verbundschlüssel (wie in dieser Problembeschreibung erläutert) nicht erwartet wird.

name Wert
Bereich Microsoft Edge
Version 4.6
Typ Neuzuweisung

.NET Framework 4.6.1

Kernspeicher

Änderung bei Pfadtrennzeichen in der FullName-Eigenschaft von ZipArchiveEntry-Objekten

Details

Bei Apps für .NET Framework 4.6.1 und höhere Versionen wurde das Pfadtrennzeichen in der FullName-Eigenschaft von ZipArchiveEntry-Objekten, die durch Überladungen der CreateFromDirectory-Methode erstellt wurden, von einem umgekehrten Schrägstrich („\“) in einen Schrägstrich („/“) geändert. Die Änderung bringt die .NET-Implementierung in Einklang mit Abschnitt 4.4.17.1 der ZIP-Dateiformatspezifikation und ermöglicht es, dass ZIP-Archive auf Nicht-Windows-Systemen entpackt werden.
Beim Dekomprimieren einer ZIP-Datei, die für eine frühere Version der .NET Framework-Zielplattform unter einem anderen als dem Windows-Betriebssystem – wie etwa dem Macintosh – erstellt wurde, bleibt die Verzeichnisstruktur nicht erhalten. Beispielsweise werden auf einem Mac mehrere Dateien erstellt, deren Namen eine Verkettung aus dem Verzeichnispfad, allen vorhandenen umgekehrten Schrägstrichen („\“) und dem Dateinamen darstellen. Im Ergebnis wird die Verzeichnisstruktur der dekomprimierten Dateien nicht beibehalten.

Vorschlag

Die Auswirkungen dieser Änderungen auf ZIP-Dateien, die unter dem Windows-Betriebssystem durch die APIs im System.IO-Namespace von .NET Framework dekomprimiert werden, sollten minimal sein, da diese APIs sowohl den Schrägstrich („/“) als auch den umgekehrten Schrägstrich („\“) als Pfadtrennzeichen verarbeiten können.
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.IO.Compression.ZipFile.UseBackslash dargestellt:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
</runtime>

Darüber hinaus kann für Apps mit früheren Versionen von .NET Framework als Zielplattform, die unter .NET Framework 4.6.1 und neueren Versionen ausgeführt werden, die Verwendung dieses Verhaltens akzeptiert werden, indem Sie dem Abschnitt <runtime> der Anwendungskonfigurationsdatei eine Konfigurationseinstellung hinzufügen. Im Folgenden sind sowohl der Abschnitt <runtime> als auch die Option Switch.System.IO.Compression.ZipFile.UseBackslash zur Verwendung dieses Verhaltens dargestellt.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
name Wert
Bereich Microsoft Edge
Version 4.6.1
Typ Neuzuweisung

Betroffene APIs

Windows Communication Foundation (WCF)

WCF-Bindung mit dem TransportWithMessageCredential-Sicherheitsmodus

Details

Ab .NET Framework 4.6.1 kann die WCF-Bindung, die den Sicherheitsmodus „TransportWithMessageCredential“ verwendet, so eingerichtet werden, dass Nachrichten mit nicht signierten to-Headern für asymmetrische Sicherheitsschlüssel empfangen werden. Standardmäßig werden nicht signierte to-Header in .NET Framework 4.6.1 weiterhin abgelehnt. Sie werden nur akzeptiert, wenn eine Anwendung unter Verwendung des Switch.System.ServiceModel.AllowUnsignedToHeader-Konfigurationsschalters diesen neuen Vorgangsmodus aktiviert.

Vorschlag

Da diese Einstellung eine Opt-in-Funktion ist, sollte sie sich nicht auf das Verhalten vorhandener Apps auswirken.
Verwenden Sie die folgende Konfigurationseinstellung, um zu steuern, ob das neue Verhalten verwendet werden soll:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
name Wert
Bereich Transparent
Version 4.6.1
Typ Neuzuweisung

Betroffene APIs

X509CertificateClaimSet.FindClaims berücksichtigt alle claimTypes (Anspruchstypen)

Details

Wenn in Apps, die auf .NET Framework 4.6.1 ausgerichtet sind, ein X509-Anspruchssatz über ein Zertifikat mit mehreren DNS-Einträge im SAN-Feld initialisiert wird, versucht die System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String)-Methode, das claimType-Argument mit allen DNS-Einträgen abzugleichen. Bei Apps, die auf frühere Versionen von .NET Framework ausgerichtet sind, versucht die Methode System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String), das claimType-Argument nur mit dem neuesten DNS-Eintrag abzugleichen.

Vorschlag

Diese Änderung wirkt sich nur auf Anwendungen aus, die auf .NET Framework 4.6.1 ausgerichtet sind. Diese Änderung kann mit dem DisableMultipleDNSEntries-Kompatibilitätsschalter deaktiviert werden (oder bei Versionen vor 4.6.1 aktiviert werden).

name Wert
Bereich Gering
Version 4.6.1
Typ Neuzuweisung

Betroffene APIs

Windows Forms

Application.FilterMessage löst für eintrittsinvariante Implementierungen von IMessageFilter.PreFilterMessage keine Ausnahmen mehr aus

Details

Vor .NET Framework 4.6.1 verursachte das Aufrufen von FilterMessage(Message) mit PreFilterMessage(Message), die System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) oder System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (bei gleichzeitigem Aufrufen von DoEvents()) aufrief, eine System.IndexOutOfRangeException.

In Anwendungen, die auf .NET Framework 4.6.1 ausgelegt sind, wird diese Ausnahme nicht mehr ausgelöst, und es können eintrittsinvariante Filter verwendet werden, wie oben beschrieben.

Vorschlag

Beachten Sie, dass FilterMessage(Message) keine Ausnahmen mehr für das oben beschriebene eintrittsinvariante PreFilterMessage(Message)-Verhalten auslöst. Dies wirkt sich nur auf Anwendungen aus, die auf .NET Framework 4.6.1 ausgerichtet sind. Auf .NET Framework 4.6.1 ausgerichtete Apps können diese Änderung mithilfe der DontSupportReentrantFilterMessage-Kompatibilitätsoption ablehnen (auf ältere Framework-Versionen ausgerichtete Apps können diese Option aktivieren).

name Wert
Bereich Microsoft Edge
Version 4.6.1
Typ Neuzuweisung

Betroffene APIs

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

.NET Framework 4.6.2

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

Core

Die AesCryptoServiceProvider-Entschlüsselungsmethode stellt eine wiederverwendbare Transformation bereit

Details

Für Apps mit der Zielplattform .NET Framework 4.6.2 und höher stellt die AesCryptoServiceProvider-Entschlüsselungsmethode eine wiederverwendbare Transformation bereit. Nach einem Aufruf von System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) wird die Transformation erneut initialisiert und kann wiederverwendet werden. Bei Apps mit früheren Versionen von .NET Framework als Zielplattform wird bei dem Versuch, die Entschlüsselungsmethode durch Aufrufen von System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) nach einem Aufruf von System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) wiederzuverwenden, eine CryptographicException ausgelöst, oder es werden fehlerhafte Daten erstellt.

Vorschlag

Der Einfluss dieser Änderung sollte klein sein, da dies das erwartete Verhalten ist. Für Anwendungen, die vom bisherigen Verhalten abhängen, muss dieses Verhalten nicht übernommen werden, wenn Sie dem Abschnitt <runtime> der Anwendungskonfigurationsdatei die folgende Konfigurationseinstellung hinzufügen:

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

Für Anwendungen, die für frühere Versionen von .NET Framework vorgesehen sind, aber unter .NET Framework 4.6.2 oder einer höheren Version ausgeführt werden, kann dieses Verhalten übernommen werden, indem dem <runtime>-Abschnitt der Anwendungskonfigurationsdatei die folgende Konfigurationseinstellung hinzugefügt wird:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>
name Wert
Bereich Gering
Version 4.6.2
Typ Neuzuweisung

Betroffene APIs

Aufrufe von ClaimsIdentity-Konstruktoren

Details

Ab .NET Framework 4.6.2 legen ClaimsIdentity-Konstruktoren mit einem System.Security.Principal.IIdentity-Parameter die Eigenschaft System.Security.Claims.ClaimsIdentity.Actor anders fest. Wenn es sich bei dem System.Security.Principal.IIdentity-Argument um ein ClaimsIdentity-Objekt handelt und die System.Security.Claims.ClaimsIdentity.Actor-Eigenschaft des ClaimsIdentity-Objekts nicht null ist, wird die System.Security.Claims.ClaimsIdentity.Actor-Eigenschaft mithilfe der Clone()-Methode angefügt. In .NET Framework 4.6.1 und früheren Versionen wurde die System.Security.Claims.ClaimsIdentity.Actor-Eigenschaft als vorhandener Verweis angefügt. Aufgrund der Änderung ab .NET Framework 4.6.2 entspricht die System.Security.Claims.ClaimsIdentity.Actor-Eigenschaft des neuen ClaimsIdentity-Objekts nicht der System.Security.Claims.ClaimsIdentity.Actor-Eigenschaft des Konstruktorarguments System.Security.Principal.IIdentity. In .NET Framework 4.6.1 und früheren Versionen sind die Eigenschaften gleich.

Vorschlag

Wenn dieses Verhalten nicht erwünscht ist, können Sie das vorherige Verhalten wiederherstellen, indem Sie den Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity-Schalter in Ihrer Anwendungskonfigurationsdatei auf true festlegen. Dazu müssen Sie dem Abschnitt <runtime> Ihrer web.config-Datei Folgendes hinzufügen:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>
name Wert
Bereich Microsoft Edge
Version 4.6.2
Typ Neuzuweisung

Betroffene APIs

Änderungen an der Pfadnormalisierung

Details

Bei Apps, die die Zielplattform .NET Framework 4.6.2 und höher verwenden, wurde im Vergleich zu früheren Versionen die Art und Weise verändert, in der die Laufzeit Pfade normalisiert. Das Normalisieren eines Pfads umfasst das Verändern der Zeichenfolge, die einen Pfad oder eine Datei identifiziert, sodass sie einem gültigen Pfad auf dem Zielbetriebssystem entspricht. Normalisierung umfasst ist in der Regel:

  • Die Kanonisierung von Komponenten- und Verzeichnistrennzeichen.
  • Die Anwendung des aktuellen Verzeichnisses auf einen relativen Pfad.
  • Die Auswertung des relativen Verzeichnisses (.) oder des übergeordneten Verzeichnisses (..) in einem Pfad.
  • Das Verkürzen um angegebene Zeichen. Für Apps, die die Zielplattform .NET Framework 4.6.2 und höher verwenden, sind die folgenden Änderungen an der Pfadnormalisierung standardmäßig aktiviert:
    • Die Runtime greift auf die Funktion GetFullPathName des Betriebssystems zurück, um Pfade zu normalisieren.
  • Die Normalisierung beinhaltet nicht mehr das Verkürzen des Endes von Verzeichnissegmenten (etwa im Fall eines Leerzeichens am Ende eines Verzeichnisnamens).
  • Unterstützung für Gerätepfadsyntax mit vollem Vertrauen, einschließlich \\.\ und \\?\ für Datei-E/A-APIs in mscorlib.dll.
  • Die Runtime überprüft Gerätesyntaxpfade nicht.
  • Die Verwendung von Gerätesyntax für den Zugriff auf alternative Datenströme wird unterstützt. Diese Änderungen verbessern die Leistung und ermöglichen zugleich Methoden den Zugriff auf zuvor nicht zugängliche Pfade. Apps mit der Zielplattform .NET Framework 4.6.1 und früheren Versionen, die unter .NET Framework 4.6.2 oder höher ausgeführt werden, sind von dieser Änderung nicht betroffen.

Vorschlag

Apps mit der Zielplattform .NET Framework 4.6.2 oder höher können die Änderung deaktivieren und die Legacynormalisierung verwenden, indem dem Abschnitt <runtime> der Anwendungskonfigurationsdatei Folgendes hinzugefügt wird:

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

Für Apps mit der Zielplattform .NET Framework 4.6.1 oder niedriger, die unter .NET Framework 4.6.2 oder höher ausgeführt werden, können die Änderungen an der Pfadnormalisierung aktiviert werden, indem dem Abschnitt <runtime> der Anwendungskonfigurationsdatei die folgende Zeile hinzugefügt wird:

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

CurrentCulture und CurrentUICulture werden über mehrere Aufgaben übertragen

Details

Ab .NET Framework 4.6 werden System.Globalization.CultureInfo.CurrentCulture und System.Globalization.CultureInfo.CurrentUICulture im System.Threading.ExecutionContext-Objekt des Threads gespeichert, das über mehrere asynchrone Vorgänge übertragen wird. Das heißt, dass Änderungen an System.Globalization.CultureInfo.CurrentCulture oder System.Globalization.CultureInfo.CurrentUICulture sich auf Aufgaben auswirken, die später asynchron ausgeführt werden. Dieses Verhalten weicht von demjenigen früherer .NET Framework-Versionen ab (die System.Globalization.CultureInfo.CurrentCulture und System.Globalization.CultureInfo.CurrentUICulture in allen asynchronen Aufgaben zurückgesetzt haben).

Vorschlag

Apps die von dieser Änderung betroffen sind, können diese möglicherweise umgehen, indem die gewünschte System.Globalization.CultureInfo.CurrentCulture oder System.Globalization.CultureInfo.CurrentUICulture als erster Vorgang in einer asynchronen Aufgabe festgelegt wird. Alternativ können Sie sich für das alte Verhalten (keine Weitergabe von System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) entscheiden, indem Sie die folgende Kompatibilitätsoption festlegen:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Dieses Problem wurde von WPF in .NET Framework 4.6.2 behoben. Es wurde ebenfalls in .NET Framework 4.6 und 4.6.1 durch KB 3139549 behoben. Apps mit der Zielplattform .NET Framework 4.6 oder höher erhalten automatisch das richtige Verhalten in WPF-Anwendungen (System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture), das über Dispatcher-Vorgänge hinweg beibehalten werden würde.

name Wert
Bereich Gering
Version 4.6
Typ Neuzuweisung

Betroffene APIs

ETW-Ereignisnamen können sich nicht nur durch das Suffix „Start“ oder „Stop“ unterscheiden

Details

In .NET Framework 4.6 und 4.6.1 löst die Runtime ArgumentException aus, wenn zwei Ereignisnamen der Ereignisablaufverfolgung für Windows (ETW) sich lediglich durch das Suffix „Start“ oder „Stop“ unterscheiden (z. B. wenn ein Ereignis mit LogUser benannt ist und das andere mit LogUserStart). In diesem Fall kann die Runtime die Ereignisquelle nicht erstellen, die dann keine Protokollierung durchführen kann.

Vorschlag

Stellen Sie sicher, dass zwei Ereignisnamen sich nicht nur durch das Suffix „Start“ oder „Stop“ unterscheiden, um die Ausnahme zu verhindern. Diese Anforderung wird mit .NET Framework 4.6.2 entfernt. Die Runtime kann Ereignisnamen unterscheiden, die sich nur durch das Suffix „Start“ oder „Stop“ unterscheiden.

name Wert
Bereich Microsoft Edge
Version 4.6
Typ Neuzuweisung

Unterstützung für lange Pfade

Details

Für Apps mit der Zielplattform .NET Framework 4.6.2 und höher werden lange Pfade (bis zu 32.000 Zeichen) unterstützt, und die Beschränkung auf 260 Zeichen (oder MAX_PATH) für die Pfadlänge wurde aufgehoben. Bei Apps, die neu kompiliert werden, um .NET Framework 4.6.2 als Zielplattform zu verwenden, lösen Codepfade, die zuvor aufgrund der Überschreitung der Pfadlänge von 260 Zeichen System.IO.PathTooLongException ausgelöst haben, nun unter den folgenden Bedingungen System.IO.PathTooLongException aus:

  • Die Zahl der Pfadzeichen überschreitet MaxValue (32.767).
  • Das Betriebssystem gibt COR_E_PATHTOOLONG oder einen dazu äquivalenten Wert zurück. Bei Apps mit der Zielplattform .NET Framework 4.6.1 und früheren Versionen löst die Laufzeit automatisch eine System.IO.PathTooLongException aus, wenn ein Pfad die Länge von 260 Zeichen überschreitet.

Vorschlag

Für Apps mit der Zielplattform .NET Framework 4.6.2 können Sie sich gegen die Unterstützung von langen Pfaden 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.BlockLongPaths=true" />
</runtime>

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

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

Die Überprüfung von Pfaden auf Doppelpunkte ist genauer

Details

In .NET Framework 4.6.2 wurde eine Reihe von Änderungen vorgenommen, um zuvor nicht unterstützte Pfade zu unterstützen (hinsichtlich Länge und Format). Die Überprüfung auf eine korrekte Syntax bei der Verwendung von Laufwerkstrennzeichen (Doppelpunkt) wurde verbessert. Als Nebenwirkung wurden mehrere URI-Pfade in einigen ausgewählten Pfad-APIs blockiert, in denen sie zuvor toleriert wurden.

Vorschlag

Wenn ein URI an betroffene APIs übergeben wird, sollten Sie zunächst die Zeichenfolge in einen gültigen Pfad ändern.

  • Entfernen Sie das Schema manuell aus den URLs (entfernen Sie z. B. file:// aus den URLs).

  • Übergeben Sie den URI an die Klasse Uri, und verwenden Sie LocalPath.

Stattdessen können Sie sich gegen die Normalisierung des neuen Pfads entscheiden, indem Sie die AppContext-Option Switch.System.IO.UseLegacyPathHandling auf true festlegen.

Name Wert
Bereich Microsoft Edge
Version 4.6.2
Typ Neuzuweisung

Betroffene APIs

Sicherheit

RSACng lädt nun fehlerfrei RSA-Schlüssel, die nicht der Standardschlüsselgröße entsprechen

Details

In .NET Framework-Versionen, die älter sind als Version 4.6.2, können Kunden, die keine Standardschlüsselgrößen für RSA-Zertifikate verwenden, auf diese Schlüssel nicht über die Erweiterungsmethoden System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) und System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2) zugreifen. Eine System.Security.Cryptography.CryptographicException mit der Meldung „The requested key size is not supported“ (Angeforderte Schlüsselgröße wird nicht unterstützt) wird ausgelöst. Dieses Problem wurde in .NET Framework 4.6.2 behoben. Ebenso funktionieren ImportParameters(RSAParameters) und ImportParameters(RSAParameters) nun mit Schlüsselgrößen, die nicht der Standardgröße entsprechen, ohne dass eine System.Security.Cryptography.CryptographicException ausgelöst wird.

Vorschlag

Wenn eine Ausnahmebehandlungslogik auf dem vorherigen Verhalten basiert, durch das eine System.Security.Cryptography.CryptographicException ausgelöst wird, sobald eine von der Standardgröße abweichende Schlüsselgröße verwendet wird, kann das Entfernen der Logik sinnvoll sein.

name Wert
Bereich Microsoft Edge
Version 4.6.2
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)

Bei der Verwendung von Eintrittsinvarianzdiensten können Deadlocks auftreten

Details

Ein Deadlock kann zu einem Eintrittsinvarianzdienst führen, der Instanzen des Diensts auf jeweils einen Ausführungsthread beschränkt. Dienste, die anfällig für dieses Problem sind, verfügen über das folgende ServiceBehaviorAttribute in ihrem Code:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

Vorschlag

Dieses Problem können Sie wie folgt beheben:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
  • Installieren Sie das neueste Update für .NET Framework 4.6.2, oder führen Sie ein Upgrade auf eine höhere Version von .NET Framework durch. Dies deaktiviert die Weitergabe von ExecutionContext in OperationContext.Current. Dieses Verhalten kann konfiguriert werden. Es entspricht dem Hinzufügen der folgenden App-Einstellung zu Ihrer Konfigurationsdatei:
<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

Der Wert Switch.System.ServiceModel.DisableOperationContextAsyncFlow darf für Reentrant-Dienste nicht auf false festgelegt werden.

name Wert
Bereich Gering
Version 4.6.2
Typ Neuzuweisung

Betroffene APIs

OperationContext.Current kann NULL zurückgeben, wenn es in einer using-Klausel aufgerufen wird

Details

OperationContext.Current kann null zurückgeben, und eine NullReferenceException kann ausgelöst werden, wenn alle folgenden Bedingungen zutreffen:

using (new OperationContextScope(OperationContext.Current))
{
    // OperationContext.Current is null.
    OperationContext context = OperationContext.Current;

    // ...
}

Vorschlag

Dieses Problem können Sie wie folgt beheben:

  • Ändern Sie den Code wie folgt, um ein neues Current-Objekt zu instanziieren, das nicht null ist:

    OperationContext ocx = OperationContext.Current;
using (new OperationContextScope(OperationContext.Current))
{
    OperationContext.Current = new OperationContext(ocx.Channel);

    // ...
}

  • Installieren Sie das neueste Update für .NET Framework 4.6.2, oder führen Sie ein Upgrade auf eine höhere Version von .NET Framework durch. Dies deaktiviert die Weitergabe von ExecutionContext in OperationContext.Current und stellt das Verhalten von WCF-Anwendungen in .NET Framework 4.6.1 und früheren Versionen wieder her. Dieses Verhalten kann konfiguriert werden. Es entspricht dem Hinzufügen der folgenden App-Einstellung zu Ihrer Konfigurationsdatei:

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

    Wenn diese Änderung nicht erwünscht ist und Ihre Anwendung von der Weitergabe des Ausführungskontexts zwischen unterschiedlichen Vorgangskontexten abhängig ist, können Sie die Übertragung wie folgt aktivieren:

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
</appSettings>
name Wert
Bereich Microsoft Edge
Version 4.6.2
Typ Neuzuweisung

Betroffene APIs

Unterstützung der WCF-Transportsicherheit für Zertifikate, die mithilfe der CNG gespeichert wurden

Details

Von Apps für die Zielplattform .NET Framework 4.6.2 an unterstützt WCF-Transportsicherheit Zertifikate, die mithilfe der Windows-Kryptographiebibliothek (CNG) gespeichert wurden. Diese Unterstützung ist auf die Verwendung von Zertifikaten mit einem öffentlichen Schlüssel beschränkt, der über einen Exponent mit einer Länge von nicht mehr als 32 Bit verfügt. Wenn eine Anwendung auf .NET Framework 4.6.2 ausgerichtet ist, ist dieses Feature standardmäßig aktiviert. In früheren Versionen von .NET Framework löst der Versuch, X509-Zertifikate mit einem CSG-Schlüsselspeicheranbieter zu verwenden, eine Ausnahme aus.

Vorschlag

Apps für die Zielplattform .NET Framework 4.6.1 und früher, die unter .NET Framework 4.6.2 ausgeführt werden, können Unterstützung für CNG-Zertifikate aktivieren, indem sie dem <runtime>-Abschnitt der app.config- oder der web.config-Datei die folgende Zeile hinzufügen:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IdentityModel.DisableCngCertificates=false" />
</runtime>

Dies kann mithilfe des folgenden Codes auch programmgesteuert erfolgen:

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificate";

AppContext.SetSwitch(disableCngCertificates, false);

Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

Beachten Sie, dass aufgrund dieser Änderung jeglicher Code zur Ausnahmebehandlung, der von dem Versuch zur Einleitung von sicherer Kommunikation mit einem CNG-Zertifikat abhängt, nicht ausgeführt wird.

name Wert
Bereich Gering
Version 4.6.2
Typ Neuzuweisung

Windows Forms

Falsche Implementierung von MemberDescriptor.Equals

Details

Die ursprüngliche Implementierung der MemberDescriptor.Equals-Methode hat zwei verschiedene Zeichenfolgeneigenschaften der zu vergleichenden Objekte miteinander verglichen: den Kategorienamen und die Beschreibungszeichenfolge. Die Korrektur besteht darin, Category des ersten Objekts mit Category des zweiten Objekts und Description des ersten Objekts mit Description des zweiten Objekts zu vergleichen.

Vorschlag

Wenn Ihre Anwendung erfordert, dass MemberDescriptor.Equals manchmal false zurückgibt, wenn Deskriptoren äquivalent sind, und sie als Zielplattform .NET Framework 4.6.2 verwendet, sind mehrere Optionen verfügbar:

  • Nehmen Sie Codeänderungen vor, um die Category- und Description-Felder manuell zusätzlich zum Aufrufen der MemberDescriptor.Equals-Methode zu vergleichen.
  • Sie können diese Änderung deaktivieren, indem Sie der Datei „app.config“ den folgenden Wert hinzufügen:
<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true" />
</runtime>

Wenn Ihre Anwendung für .NET Framework 4.6.1 oder frühere Versionen konzipiert ist, unter .NET Framework 4.6.2 ausgeführt wird und Sie diese Änderung aktivieren möchten, können Sie den Kompatibilitätsschalter auf false festlegen, indem Sie der Datei „app.config“ den folgenden Wert hinzufügen:

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

Betroffene APIs

Windows Presentation Foundation (WPF)

CurrentCulture wird zwischen WPF-Dispatcher-Vorgängen nicht beibehalten

Details

Ab .NET Framework 4.6 gehen Änderungen an System.Globalization.CultureInfo.CurrentCulture oder System.Globalization.CultureInfo.CurrentUICulture, die innerhalb eines System.Windows.Threading.Dispatcher-Elements vorgenommen werden, am Ende des Verteilungsvorgangs verloren. Auf ähnliche Weise werden Änderungen an System.Globalization.CultureInfo.CurrentCulture oder System.Globalization.CultureInfo.CurrentUICulture außerhalb eines Verteilungsvorgangs möglicherweise nicht übernommen, wenn der Vorgang ausgeführt wird. In der Praxis bedeutet dies, dass Änderungen an System.Globalization.CultureInfo.CurrentCulture und System.Globalization.CultureInfo.CurrentUICulture möglicherweise zwischen Rückrufen der WPF-Benutzeroberfläche und anderem Code in einer WPF-Anwendung nicht übertragen werden. Der Grund dafür ist eine Änderung in System.Threading.ExecutionContext, durch die System.Globalization.CultureInfo.CurrentCulture und System.Globalization.CultureInfo.CurrentUICulture im Ausführungskontext gespeichert werden. Diese Änderung betrifft Apps mit der Zielplattform .NET Framework 4.6 und höher. WPF-Verteilungsvorgänge speichern den Ausführungskontext, der dazu verwendet wurde, um den Vorgang zu beginnen und stellen den vorherigen Kontext wieder her, wenn der Vorgang abgeschlossen ist. Da System.Globalization.CultureInfo.CurrentCulture und System.Globalization.CultureInfo.CurrentUICulture jetzt Bestandteil dieses Kontexts sind, bleiben innerhalb eines Dispatchervorgangs an ihnen vorgenommene Änderungen außerhalb des Vorgangs nicht erhalten.

Vorschlag

Von dieser Änderung betroffene Apps können dieses Problem möglicherweise umgehen, indem das gewünschte System.Globalization.CultureInfo.CurrentCulture- oder System.Globalization.CultureInfo.CurrentUICulture-Element in einem Feld gespeichert wird und für alle Vorgangstexte der Verteilung (einschließlich der Rückrufereignishandler für Benutzeroberflächenereignisse) geprüft wird, ob das richtige System.Globalization.CultureInfo.CurrentCulture- und System.Globalization.CultureInfo.CurrentUICulture-Element festgelegt ist. Da die ExecutionContext-Änderung, die dieser WPF-Änderung zugrunde liegt, nur Apps betrifft, die auf .NET Framework 4.6 oder höher ausgerichtet sind, kann dieser Fehler alternativ vermieden werden, indem .NET Framework 4.5.2 als Zielplattform verwendet wird. Apps mit der Zielplattform .NET Framework 4.6 oder höher können dieses Problem ebenfalls umgehen, indem die folgende Kompatibilitätsoption festgelegt wird:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Dieses Problem wurde von WPF in .NET Framework 4.6.2 behoben. Es wurde ebenfalls in .NET Framework 4.6 und 4.6.1 durch KB 3139549 behoben. Apps mit der Zielplattform .NET Framework 4.6 oder höher erhalten automatisch das richtige Verhalten in WPF-Anwendungen (System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture), das über Dispatcher-Vorgänge hinweg beibehalten werden würde.

name Wert
Bereich Gering
Version 4.6
Typ Neuzuweisung