Neuzuweisung von Änderungen für die Migration von .NET Framework 4.6.1 zu 4.6.2Retargeting Changes for Migration from .NET Framework 4.6.1 to 4.6.2

EinführungIntroduction

Neuzuweisungsänderungen wirken sich auf Apps aus, die für eine andere .NET Framework-Instanz neu kompiliert wurden.Retargeting changes affect apps that are recompiled to target a different .NET Framework. Dazu zählen:They include:

  • Änderungen in der Entwurfszeitumgebung.Changes in the design-time environment. Beispielsweise können Buildtools Warnungen ausgeben, obwohl dies zuvor nicht der Fall war.For example, build tools may emit warnings when previously they did not.

  • Änderungen in der Laufzeitumgebung.Changes in the runtime environment. Dies betrifft nur Apps, die speziell diese .NET Framework-Instanz als Ziel verwenden.These affect only apps that specifically target the retargeted .NET Framework. Apps, die auf frühere Versionen von .NET Framework abzielen, verhalten sich so, als würden sie in diesen Versionen ausgeführt.Apps that target previous versions of the .NET Framework behave as they did when running under those versions.

In den Artikeln, in denen Neuzuweisungsänderungen beschrieben werden, haben wir die einzelnen Punkte entsprechend ihrer erwarteten Auswirkung eingestuft:In the topics that describe retargeting changes, we have classified individual items by their expected impact, as follows:

Größer Dies ist eine wesentliche Änderung, die viele Apps beeinträchtigt oder erhebliche Änderungen des Codes erforderlich macht.Major This is a significant change that affects a large number of apps or that requires substantial modification of code.

Kleiner Dies ist eine Änderung, die eine kleine Anzahl von Apps beeinträchtigt oder geringfügige Änderungen des Codes erforderlich macht.Minor This is a change that affects a small number of apps or that requires minor modification of code.

Grenzfall Diese Änderung beeinträchtigt Apps nur in sehr spezifischen Szenarien, die nicht häufig vorkommen.Edge case This is a change that affects apps under very specific scenarios that are not common.

Transparent Diese Änderung hat keine nennenswerten Auswirkungen, die Entwickler oder Benutzer beachten müssten.Transparent This is a change that has no noticeable effect on the app's developer or user. Die App sollte keine Änderung benötigen.The app should not require modification because of this change.

Wenn Sie von .NET Framework 4.6.1 zu 4.6.2 migrieren, finden Sie in den folgenden Themen weitere Informationen zu den Anwendungskompatibilitätsproblemen, die sich möglicherweise auf Ihre App auswirken können:If you are migrating from the .NET Framework 4.6.1 to 4.6.2, review the following topics for application compatibility issues that may affect your app:

ASP.NETASP.NET

HttpRuntime.AppDomainAppPath löst NullReferenceException ausHttpRuntime.AppDomainAppPath Throws a NullReferenceException

DetailsDetails 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.In the .NET Framework 4.6.2, the runtime throws a T:System.NullReferenceException when retrieving a P:System.Web.HttpRuntime.AppDomainAppPath value that includes null characters.In the .NET Framework 4.6.1 and earlier versions, the runtime throws an T:System.ArgumentNullException.
VorschlagSuggestion Sie können mit einer der folgenden Möglichkeiten auf diese Änderung reagieren:You can do either of the follow to respond to this change:
  • Behandeln Sie die T:System.NullReferenceException, wenn Ihre Anwendung in .NET Framework 4.6.2 ausgeführt wird.Handle the T:System.NullReferenceException if you application is running on the .NET Framework 4.6.2.
  • Führen Sie ein Upgrade auf .NET Framework 4.7 durch, sodass das vorherige Verhalten wiederhergestellt und eine T:System.ArgumentNullException ausgelöst wird.Upgrade to the .NET Framework 4.7, which restores the previous behavior and throws an T:System.ArgumentNullException.
BereichScope Microsoft EdgeEdge
VersionVersion 4.6.24.6.2
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

KernspeicherCore

Die AesCryptoServiceProvider-Entschlüsselungsmethode stellt eine wiederverwendbare Transformation bereitAesCryptoServiceProvider decryptor provides a reusable transform

DetailsDetails Für Apps mit der Zielplattform .NET Framework 4.6.2 und höher stellt die AesCryptoServiceProvider-Entschlüsselungsmethode eine wiederverwendbare Transformation bereit.Starting with apps that target the .NET Framework 4.6.2, the AesCryptoServiceProvider decryptor provides a reusable transform. Nach einem Aufruf von TransformFinalBlock(Byte[], Int32, Int32) wird die Transformation erneut initialisiert und kann wiederverwendet werden.After a call to TransformFinalBlock(Byte[], Int32, Int32), the transform is reinitialized and can be reused. Bei Apps mit früheren Versionen von .NET Framework als Zielplattform wird bei dem Versuch, die Entschlüsselungsmethode durch Aufrufen von TransformBlock(Byte[], Int32, Int32, Byte[], Int32) nach einem Aufruf von TransformFinalBlock(Byte[], Int32, Int32) wiederzuverwenden, eine CryptographicException ausgelöst, oder es werden fehlerhafte Daten erstellt.For apps that target earlier versions of the .NET Framework, attempting to reuse the decryptor by calling TransformBlock(Byte[], Int32, Int32, Byte[], Int32) after a call to TransformFinalBlock(Byte[], Int32, Int32) throws a CryptographicException or produces corrupted data.
VorschlagSuggestion 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:The impact of this change should be minimal, since this is the expected behavior.Applications that depend on the previous behavior can opt out of it using it by adding the following configuration setting to the <runtime> section of the application's configuration file:
<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:In addition, applications that target a previous version of the .NET Framework but are running under a version of the .NET Framework starting with .NET Framework 4.6.2 can opt in to it by adding the following configuration setting to the <runtime> section of the application's configuration file:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>
BereichScope GeringMinor
VersionVersion 4.6.24.6.2
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Aufrufe von ClaimsIdentity-KonstruktorenCalls to ClaimsIdentity constructors

DetailsDetails Ab .NET Framework 4.6.2 legen ClaimsIdentity-Konstruktoren mit einem IIdentity-Parameter die Eigenschaft Actor anders fest.Starting with the .NET Framework 4.6.2, there is a change in how ClaimsIdentity constructors with an IIdentity parameter set the Actor property. Wenn es sich bei dem IIdentity-Argument um ein ClaimsIdentity-Objekt handelt und die Actor-Eigenschaft des ClaimsIdentity-Objekts nicht null ist, wird die Actor-Eigenschaft mithilfe der Clone()-Methode angefügt.If the IIdentity argument is a ClaimsIdentity object, and the Actor property of that ClaimsIdentity object is not null, the Actor property is attached by using the Clone() method. In .NET Framework 4.6.1 und früheren Versionen wurde die Actor-Eigenschaft als vorhandener Verweis angefügt. Aufgrund der Änderung ab .NET Framework 4.6.2 entspricht die Actor-Eigenschaft des neuen ClaimsIdentity-Objekts nicht der Actor-Eigenschaft des Konstruktorarguments IIdentity.In the Framework 4.6.1 and earlier versions, the Actor property is attached as an existing reference.Because of this change, starting with the .NET Framework 4.6.2, the Actor property of the new ClaimsIdentity object is not equal to the Actor property of the constructor's IIdentity argument. In .NET Framework 4.6.1 und früheren Versionen sind die Eigenschaften gleich.In the .NET Framework 4.6.1 and earlier versions, it is equal.
VorschlagSuggestion 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.If this behavior is undesirable, you can restore the previous behavior by setting the Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity switch in your application configuration file to true. Dazu müssen Sie dem Abschnitt <runtime> Ihrer web.config-Datei Folgendes hinzufügen:This requires that you add the following to the <runtime> section of your web.config file:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
</runtime>
</configuration>
BereichScope Microsoft EdgeEdge
VersionVersion 4.6.24.6.2
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Änderungen an der PfadnormalisierungChanges in path normalization

DetailsDetails 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.Starting with apps that target the .NET Framework 4.6.2, the way in which the runtime normalizes paths has changed.Normalizing a path involves modifying the string that identifies a path or file so that it conforms to a valid path on the target operating system. Normalisierung umfasst ist in der Regel:Normalization typically involves:
  • Die Kanonisierung von Komponenten- und Verzeichnistrennzeichen.Canonicalizing component and directory separators.
  • Die Anwendung des aktuellen Verzeichnisses auf einen relativen Pfad.Applying the current directory to a relative path.
  • Die Auswertung des relativen Verzeichnisses (.) oder des übergeordneten Verzeichnisses (..) in einem Pfad.Evaluating the relative directory (.) or the parent directory (..) in a path.
  • Das Verkürzen um angegebene Zeichen.Trimming specified characters.
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:Starting with apps that target the .NET Framework 4.6.2, the following changes in path normalization are enabled by default:
  • Die Runtime greift auf die Funktion GetFullPathName des Betriebssystems zurück, um Pfade zu normalisieren.The runtime defers to the operating system's GetFullPathName function to normalize paths.
  • Die Normalisierung beinhaltet nicht mehr das Verkürzen des Endes von Verzeichnissegmenten (etwa im Fall eines Leerzeichens am Ende eines Verzeichnisnamens).Normalization no longer involves trimming the end of directory segments (such as a space at the end of a directory name).
  • Unterstützung für Gerätepfadsyntax mit vollem Vertrauen, einschließlich \\.\ und \\?\ für Datei-E/A-APIs in mscorlib.dll.Support for device path syntax in full trust, including \\.\ and, for file I/O APIs in mscorlib.dll, \\?\.
  • Die Runtime überprüft Gerätesyntaxpfade nicht.The runtime does not validate device syntax paths.
  • Die Verwendung von Gerätesyntax für den Zugriff auf alternative Datenströme wird unterstützt.The use of device syntax to access alternate data streams is supported.
Diese Änderungen verbessern die Leistung und ermöglichen zugleich Methoden den Zugriff auf zuvor nicht zugängliche Pfade.These changes improve performance while allowing methods to access previously inaccessible paths. 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.Apps that target the .NET Framework 4.6.1 and earlier versions but are running under the .NET Framework 4.6.2 or later are unaffected by this change.
VorschlagSuggestion 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:Apps that target the .NET Framework 4.6.2 or later can opt out of this change and use legacy normalization by adding the following to the <runtime> section of the application configuration file:
<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:Apps that target the .NET Framework 4.6.1 or earlier but are running on the .NET Framework 4.6.2 or later can enable the changes to path normalization by adding the following line to the <runtime> section of the application .configuration file:
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
BereichScope GeringMinor
VersionVersion 4.6.24.6.2
TypType NeuzuweisungRetargeting

CurrentCulture und CurrentUICulture werden über mehrere Aufgaben übertragenCurrentCulture and CurrentUICulture flow across tasks

DetailsDetails Ab .NET Framework 4.6 werden CurrentCulture und CurrentUICulture im ExecutionContext-Objekt des Threads gespeichert, das über mehrere asynchrone Vorgänge übertragen wird. Das heißt, dass Änderungen an CurrentCulture oder CurrentUICulture sich auf Aufgaben auswirken, die später asynchron ausgeführt werden.Beginning in the .NET Framework 4.6, CurrentCulture and CurrentUICulture are stored in the thread's ExecutionContext, which flows across asynchronous operations.This means that changes to CurrentCulture or CurrentUICulture will be reflected in tasks which are later run asynchronously. Dieses Verhalten weicht von demjenigen früherer .NET Framework-Versionen ab (die CurrentCulture und CurrentUICulture in allen asynchronen Aufgaben zurückgesetzt haben).This is different from the behavior of previous .NET Framework versions (which would reset CurrentCulture and CurrentUICulture in all asynchronous tasks).
VorschlagSuggestion Apps die von dieser Änderung betroffen sind, können diese möglicherweise umgehen, indem die gewünschte CurrentCulture oder CurrentUICulture als erster Vorgang in einer asynchronen Aufgabe festgelegt wird.Apps affected by this change may work around it by explicitly setting the desired CurrentCulture or CurrentUICulture as the first operation in an async Task. Alternativ können Sie sich für das alte Verhalten (keine Weitergabe von CurrentCulture/CurrentUICulture) entscheiden, indem Sie die folgende Kompatibilitätsoption festlegen:Alternatively, the old behavior (of not flowing CurrentCulture/CurrentUICulture) may be opted into by setting the following compatibility switch:
AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);
Dieses Problem wurde von WPF in .NET Framework 4.6.2 behoben.This issue has been fixed by WPF in .NET Framework 4.6.2. Es wurde ebenfalls in .NET Framework 4.6 und 4.6.1 durch KB 3139549 behoben.It has also been fixed in .NET Frameworks 4.6, 4.6.1 through KB 3139549. Apps mit der Zielplattform .NET Framework 4.6 oder höher erhalten automatisch das richtige Verhalten in WPF-Anwendungen (CurrentCulture/CurrentUICulture), das über Dispatcher-Vorgänge hinweg beibehalten werden würde.Applications targeting .NET Framework 4.6 or later will automatically get the right behavior in WPF applications - CurrentCulture/CurrentUICulture) would be preserved across Dispatcher operations.
BereichScope GeringMinor
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

ETW-Ereignisnamen können sich nicht nur durch das Suffix „Start“ oder „Stop“ unterscheidenETW event names cannot differ only by a "Start" or "Stop" suffix

DetailsDetails In .NET Framework 4.6 und 4.6.1 löst die Laufzeit 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 the .NET Framework 4.6 and 4.6.1, the runtime throws an ArgumentException when two Event Tracing for Windows (ETW) event names differ only by a "Start" or "Stop" suffix (as when one event is named LogUser and another is named LogUserStart). In diesem Fall kann die Runtime die Ereignisquelle nicht erstellen, die dann keine Protokollierung durchführen kann.In this case, the runtime cannot construct the event source, which cannot emit any logging.
VorschlagSuggestion 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 Laufzeit kann Ereignisnamen unterscheiden, die sich nur durch das Suffix "Start" oder "Stop" unterscheiden.To prevent the exception, ensure that no two event names differ only by a "Start" or "Stop" suffix.This requirement is removed starting with the .NET Framework 4.6.2; the runtime can disambiguate event names that differ only by the "Start" and "Stop" suffix.
BereichScope Microsoft EdgeEdge
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting

Unterstützung für lange PfadeLong path support

DetailsDetails 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 PathTooLongException ausgelöst haben, nun unter den folgenden Bedingungen PathTooLongException aus:Starting with apps that target the .NET Framework 4.6.2, long paths (of up to 32K characters) are supported, and the 260-character (or MAX_PATH) limitation on path lengths has been removed.For apps that are recompiled to target the .NET Framework 4.6.2, code paths that previously threw a PathTooLongException because a path exceeded 260 characters will now throw a PathTooLongException only under the following conditions:
  • Die Zahl der Pfadzeichen überschreitet MaxValue (32.767).The length of the path is greater than MaxValue (32,767) characters.
  • Das Betriebssystem gibt COR_E_PATHTOOLONG oder einen dazu äquivalenten Wert zurück.The operating system returns COR_E_PATHTOOLONG or its equivalent.
Bei Apps mit der Zielplattform .NET Framework 4.6.1 und früheren Versionen löst die Laufzeit automatisch eine PathTooLongException aus, wenn ein Pfad die Länge von 260 Zeichen überschreitet.For apps that target the .NET Framework 4.6.1 and earlier versions, the runtime automatically throws a PathTooLongException whenever a path exceeds 260 characters.
VorschlagSuggestion 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:For apps that target the .NET Framework 4.6.2, you can opt out of long path support if it is not desirable by adding the following to the <runtime> section of your app.config file:
<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:For apps that target earlier versions of the .NET Framework but run on the .NET Framework 4.6.2 or later, you can opt in to long path support by adding the following to the <runtime> section of your app.config file:
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>
BereichScope GeringMinor
VersionVersion 4.6.24.6.2
TypType NeuzuweisungRetargeting

Die Überprüfung von Pfaden auf Doppelpunkte ist genauerPath colon checks are stricter

DetailsDetails 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).In .NET Framework 4.6.2, a number of changes were made to support previously unsupported paths (both in length and 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 vorher toleriert wurden.Checks for proper drive separator (colon) syntax were made more correct, which had the side effect of blocking some URI paths in a few select Path APIs where they used to be tolerated.
VorschlagSuggestion Wenn ein URI an betroffene APIs übergeben wird, sollten Sie zunächst die Zeichenfolge in einen gültigen Pfad ändern.If passing a URI to affected APIs, modify the string to be a legal path first.
  • Entfernen Sie das Schema manuell aus den URLs (entfernen Sie z.B. file:// aus den URLs).Remove the scheme from URLs manually (e.g. remove file:// from URLs)
  • Übergeben Sie den URI der Klasse Uri und verwenden Sie LocalPath.Pass the URI to the Uri class and use LocalPath
Alternativ können Sie sich gegen die Normalisierung des neuen Pfads entscheiden, indem Sie die AppContext-Option Switch.System.IO.UseLegacyPathHandling auf TRUE festlegen.Alternatively, you can opt out of the new path normalization by setting the Switch.System.IO.UseLegacyPathHandling AppContext switch to true.
BereichScope Microsoft EdgeEdge
VersionVersion 4.6.24.6.2
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

SicherheitSecurity

RSACng lädt nun fehlerfrei RSA-Schlüssel, die nicht der Standardschlüsselgröße entsprechenRSACng now correctly loads RSA keys of non-standard key size

DetailsDetails 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 GetRSAPublicKey(X509Certificate2) und GetRSAPrivateKey(X509Certificate2) zugreifen.In .NET Framework versions prior to 4.6.2, customers with non-standard key sizes for RSA certificates are unable to access those keys via the GetRSAPublicKey(X509Certificate2) and GetRSAPrivateKey(X509Certificate2) extension methods. Eine CryptographicException wird mit der Meldung "The requested key size is not supported" (Die angeforderte Schlüsselgröße wird nicht unterstützt.) ausgelöst.A CryptographicException with the message "The requested key size is not supported" is thrown. Dieses Problem wurde in .NET Framework 4.6.2 behoben.In .NET Framework 4.6.2 this issue has been fixed. Ebenso funktionieren ImportParameters(RSAParameters) und ImportParameters(RSAParameters) nun mit Schlüsselgrößen, die nicht der Standardgröße entsprechen, ohne dass eine CryptographicException ausgelöst wird.Similarly, ImportParameters(RSAParameters) and ImportParameters(RSAParameters) now work with non-standard key sizes without throwing a CryptographicException.
VorschlagSuggestion Wenn eine Ausnahmebehandlungslogik auf dem vorherigen Verhalten basiert, durch das eine CryptographicException ausgelöst wird, sobald eine von der Standardgröße abweichende Schlüsselgröße verwendet wird, kann das Entfernen der Logik sinnvoll sein.If there is any exception handling logic that relies on the previous behavior where a CryptographicException is thrown when non-standard key sizes are used, consider removing the logic.
BereichScope Microsoft EdgeEdge
VersionVersion 4.6.24.6.2
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

SignedXml.GetPublicKey gibt unter .NET Framework 4.6.2 RSACng (oder CngLightup) zurück, ohne Änderungen neu zuzuweisenSignedXml.GetPublicKey returns RSACng on net462 (or lightup) without retargeting change

DetailsDetails 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.Starting with the .NET Framework 4.6.2, the concrete type of the object returned by the SignedXml.GetPublicKey method changed (without a quirk) from a CryptoServiceProvider implementation to a Cng implementation. 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.This is because the implementation changed from using certificate.PublicKey.Key to using the internal certificate.GetAnyPublicKey which forwards to RSACertificateExtensions.GetRSAPublicKey.
VorschlagSuggestion 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:Starting with apps running on the .NET Framework 4.7.1, you can use the CryptoServiceProvider implementation used by default in the .NET Framework 4.6.1 and earlier versions by adding the following configuration switch to the runtime section of your app config file:
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
BereichScope Microsoft EdgeEdge
VersionVersion 4.6.24.6.2
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Windows Communication Foundation (WCF)Windows Communication Foundation (WCF)

Bei der Verwendung von Eintrittsinvarianzdiensten können Deadlocks auftretenDeadlock may result when using Reentrant services

DetailsDetails Ein Deadlock kann zu einem Eintrittsinvarianzdienst führen, der Instanzen des Diensts auf jeweils einen Ausführungsthread beschränkt.A deadlock may result in a Reentrant service, which restricts instances of the service to one thread of execution at a time. Dienste, die anfällig für dieses Problem sind, verfügen über das folgende ServiceBehaviorAttribute in ihrem Code:Services prone to encounter this problem will have the following ServiceBehaviorAttribute in their code:
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
VorschlagSuggestion Dieses Problem können Sie wie folgt beheben:To address this issue, you can do the following:
  • Legen Sie den Parallelitätsmodus des Diensts auf ConcurrencyMode.Single oder <System.ServiceModel.ConcurrencyMode.Multiple?displayProperty=nameWithType> fest.Set the service's concurrency mode to ConcurrencyMode.Single or <System.ServiceModel.ConcurrencyMode.Multiple?displayProperty=nameWithType>. Beispiel:For example:
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
  • 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.Install the latest update to the .NET Framework 4.6.2, or upgrade to a later version of the .NET Framework. Dies deaktiviert die Weitergabe von ExecutionContext in OperationContext.Current.This disables the flow of the ExecutionContext in OperationContext.Current. Dieses Verhalten kann konfiguriert werden. Es entspricht dem Hinzufügen der folgenden App-Einstellung zu Ihrer Konfigurationsdatei:This behavior is configurable; it is equivalent to adding the following app setting to your configuration file:
<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.The value of Switch.System.ServiceModel.DisableOperationContextAsyncFlow should never be set to false for Reentrant services.
BereichScope GeringMinor
VersionVersion 4.6.24.6.2
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

OperationContext.Current kann NULL zurückgeben, wenn es in einer using-Klausel aufgerufen wirdOperationContext.Current may return null when called in a using clause

DetailsDetails OperationContext.Current kann null zurückgeben, und eine NullReferenceException kann ausgelöst werden, wenn alle folgenden Bedingungen zutreffen:may return null and a NullReferenceException may result if all of the following conditions are true:
using (new OperationContextScope(OperationContext.Current))
{
OperationContext context = OperationContext.Current;      // OperationContext.Current is null.
// ...
}
VorschlagSuggestion Dieses Problem können Sie wie folgt beheben:To address this issue, you can do the following:
  • Ändern Sie den Code wie folgt, um ein neues Current-Objekt zu instanziieren, das nicht null ist:Modify your code as follows to instantiate a new non-null Current object:
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.Install the latest update to the .NET Framework 4.6.2, or upgrade to a later version of the .NET Framework. 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.This disables the flow of the ExecutionContext in OperationContext.Current and restores the behavior of WCF applications in the .NET Framework 4.6.1 and earlier versions. Dieses Verhalten kann konfiguriert werden. Es entspricht dem Hinzufügen der folgenden App-Einstellung zu Ihrer Konfigurationsdatei:This behavior is configurable; it is equivalent to adding the following app setting to your configuration file:
<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:If this change is undesirable and your application depends on execution context flowing between operation contexts, you can enable its flow as follows:
<appSettings>
<add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
</appSettings>
BereichScope Microsoft EdgeEdge
VersionVersion 4.6.24.6.2
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Unterstützung der WCF-Transportsicherheit für Zertifikate, die mithilfe der CNG gespeichert wurdenWCF transport security supports certificates stored using CNG

DetailsDetails 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.Starting with apps that target the .NET Framework 4.6.2, WCF transport security supports certificates stored using the Windows Cryptography Library (CNG). 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.This support is limited to certificates with a public key that has an exponent no more than 32 bits in length. 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.When an application targets the .NET Framework 4.6.2, this feature is on by default.In earlier versions of the .NET Framework, the attempt to use X509 certificates with a CSG key storage provider throws an exception.
VorschlagSuggestion 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:Apps that target the .NET Framework 4.6.1 and earlier but are running on the .NET Framework 4.6.2 can enable support for CNG certificates by adding the following line to the <runtime> section of the app.config or web.config file:
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableCngCertificates=false" />
</runtime>
Dies kann mithilfe des folgenden Codes auch programmgesteuert erfolgen:This can also be done programmatically with the following code:
private const string DisableCngCertificates = @"Switch.System.ServiceModel.DisableCngCertificate";
AppContext.SetSwitch(disableCngCertificates, false);
Const DisableCngCertificates As String = "Switch.System.ServiceModel.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.Note that, because of this change, any exception handling code that depends on the attempt to initiate secure communication with a CNG certificate to fail will no longer execute.
BereichScope GeringMinor
VersionVersion 4.6.24.6.2
TypType NeuzuweisungRetargeting

Windows FormsWindows Forms

Falsche Implementierung von MemberDescriptor.EqualsIncorrect implementation of MemberDescriptor.Equals

DetailsDetails Die ursprüngliche Implementierung der MemberDescriptor.Equals-Methode hat zwei verschiedene Zeichenfolgeneigenschaften der zu vergleichenden Objekte miteinander verglichen: den Kategorienamen und die Beschreibungszeichenfolge.The original implementation of the MemberDescriptor.Equals method compares two different string properties from the objects being compared: the category name and the description string. 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.The fix is to compare the Category of the first object to the Category of the second one, and the Description of the first to the Description of the second.
VorschlagSuggestion 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:If your application depends on MemberDescriptor.Equals sometimes returning false when descriptors are equivalent, and you are targeting the .NET Framework 4.6.2 or later, you have several options:
  1. Nehmen Sie Codeänderungen vor, um die Category- und Description-Felder manuell zusätzlich zum Aufrufen der MemberDescriptor.Equals-Methode zu vergleichen.Make code changes to compare the Category and Description fields manually in addition to calling the MemberDescriptor.Equals method.
  2. Sie können diese Änderung deaktivieren, indem Sie der Datei „app.config“ den folgenden Wert hinzufügen:Opt out of this change by adding the following value to the app.config file:
<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:If your application targets .NET Framework 4.6.1 or earlier and is running on the .NET Framework 4.6.2 or later and you want this change enabled, you can set the compatibility switch to false by adding the following value to the app.config file:
<runtime>
<AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>
BereichScope Microsoft EdgeEdge
VersionVersion 4.6.24.6.2
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Windows Presentation Foundation (WPF)Windows Presentation Foundation (WPF)

CurrentCulture wird zwischen WPF-Dispatcher-Vorgängen nicht beibehaltenCurrentCulture is not preserved across WPF Dispatcher operations

DetailsDetails Ab .NET Framework 4.6 gehen Änderungen an CurrentCulture oder CurrentUICulture, die innerhalb eines Dispatcher-Elements vorgenommen werden, am Ende des Verteilungsvorgangs verloren.Beginning in the .NET Framework 4.6, changes to CurrentCulture or CurrentUICulture made within a Dispatcher will be lost at the end of that dispatcher operation. Auf ähnliche Weise werden Änderungen an CurrentCulture oder CurrentUICulture außerhalb eines Verteilungsvorgangs möglicherweise nicht übernommen, wenn der Vorgang ausgeführt wird. In der Praxis bedeutet dies, dass Änderungen an CurrentCulture und 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 ExecutionContext, durch die CurrentCulture und CurrentUICulture im Ausführungskontext gespeichert werden. Diese Änderung betrifft Apps mit der Zielplattform .NET Framework 4.6 und höher.Similarly, changes to CurrentCulture or CurrentUICulture made outside of a Dispatcher operation may not be reflected when that operation executes.Practically speaking, this means that CurrentCulture and CurrentUICulture changes may not flow between WPF UI callbacks and other code in a WPF application.This is due to a change in ExecutionContext that causes CurrentCulture and CurrentUICulture to be stored in the execution context beginning with apps targeting the .NET Framework 4.6. 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.WPF dispatcher operations store the execution context used to begin the operation and restore the previous context when the operation is completed. Da CurrentCulture und CurrentUICulture jetzt Bestandteil dieses Kontexts sind, bleiben innerhalb eines Dispatchervorgangs an ihnen vorgenommene Änderungen außerhalb des Vorgangs nicht erhalten.Because CurrentCulture and CurrentUICulture are now part of that context, changes to them within a dispatcher operation are not persisted outside of the operation.
VorschlagSuggestion Von dieser Änderung betroffene Apps können dieses Problem möglicherweise umgehen, indem das gewünschte CurrentCulture- oder 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 CurrentCulture- und CurrentUICulture-Element festgelegt ist.Apps affected by this change may work around it by storing the desired CurrentCulture or CurrentUICulture in a field and checking in all Dispatcher operation bodies (including UI event callback handlers) that the correct CurrentCulture and CurrentUICulture are set. 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:Alternatively, because the ExecutionContext change underlying this WPF change only affects apps targeting the .NET Framework 4.6 or newer, this break can be avoided by targeting the .NET Framework 4.5.2.Apps that target .NET Framework 4.6 or later can also work around this by setting the following compatibility switch:
AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);
Dieses Problem wurde von WPF in .NET Framework 4.6.2 behoben.This issue has been fixed by WPF in .NET Framework 4.6.2. Es wurde ebenfalls in .NET Framework 4.6 und 4.6.1 durch KB 3139549 behoben.It has also been fixed in .NET Frameworks 4.6, 4.6.1 through KB 3139549. Apps mit der Zielplattform .NET Framework 4.6 oder höher erhalten automatisch das richtige Verhalten in WPF-Anwendungen (CurrentCulture/CurrentUICulture), das über Dispatcher-Vorgänge hinweg beibehalten werden würde.Applications targeting .NET Framework 4.6 or later will automatically get the right behavior in WPF applications - CurrentCulture/CurrentUICulture) would be preserved across Dispatcher operations.
BereichScope GeringMinor
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting