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

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.5.1 zu 4.7 migrieren, finden Sie in den folgenden Abschnitten 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.5.1 to 4.7, review the following topics for application compatibility issues that may affect your app:

ASP.NETASP.NET

HtmlTextWriter rendert das Element <br/> nicht ordnungsgemäßHtmlTextWriter does not render <br/> element correctly

DetailsDetails 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.Beginning in the .NET Framework 4.6, calling RenderBeginTag(String) and RenderEndTag() with a <BR /> element will correctly insert only one <BR /> (instead of two)
VorschlagSuggestion Wenn eine App vom zusätzlichen <BR />-Tag abhängig ist, sollte RenderBeginTag(String) ein zweites Mal aufgerufen werden.If an app depended on the extra <BR /> tag, RenderBeginTag(String) should be called a second time. 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.Note that this behavior change only affects apps that target the .NET Framework 4.6 or later, so another option is to target a previous version of the .NET Framework in order to get the old behavior.
BereichScope Microsoft EdgeEdge
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Einschränken von gleichzeitigen Anforderungen pro SitzungThrottle concurrent requests per session

DetailsDetails In .NET Framework 4.6.2 und früheren Versionen führt ASP.NET Anforderungen mit der gleichen SessionID sequentiell durch, und ASP.NET stellt die SessionID standardmäßig über Cookies aus.In the .NET Framework 4.6.2 and earlier, ASP.NET executes requests with the same Sessionid sequentially, and ASP.NET always issues the Sessionid through cookies by default. Wenn eine Seite zum Reagieren viel Zeit in Anspruch nimmt, wird die Serverleistung durch einfaches Drücken von F5 im Browser erheblich eingeschränkt.If a page takes a long time to respond, it will significantly degrade server performance just by pressing F5 on the browser. Mit der Fehlerbehebung verfolgt ein Zähler die in die Warteschlange eingestellten Anforderungen nach und beendet die Anforderungen, wenn sie einen angegebenen Grenzwert überschreiten.In the fix, we added a counter to track the queued requests and terminate the requests when they exceed a specified limit. Der Standardwert ist 50.The default value is 50. Wenn der Grenzwert erreicht wird, wird eine Warnung in das Ereignisprotokoll geschrieben, und möglicherweise wird eine HTTP 500-Antwort im IIS-Protokoll aufgezeichnet.If the limit is reached, a warning will be logged in the event log, and an HTTP 500 response may be recorded in the IIS log.
VorschlagSuggestion Um das alte Verhalten wiederherzustellen, können Sie Ihrer web.config-Datei die folgende Einstellung hinzufügen, um sich gegen das neue Verhalten zu entscheiden.To restore the old behavior, you can add the following setting to your web.config file to opt out of the new behavior.
<appSettings>
<add key="aspnet:RequestQueueLimitPerSession" value="2147483647"/>
</appSettings>
BereichScope Microsoft EdgeEdge
VersionVersion 4.74.7
TypType NeuzuweisungRetargeting

ClickOnceClickOnce

Mit ClickOnce veröffentlichte Apps, die ein SHA-256-Codesignaturzertifikat verwenden, verursachen unter Windows 2003 möglicherweise einen FehlerApps published with ClickOnce that use a SHA-256 code-signing certificate may fail on Windows 2003

DetailsDetails Die ausführbare Datei ist mit SHA256 signiert.The executable is signed with SHA256. Früher wurde sie mit SHA1 signiert, unabhängig davon, ob das Codesignaturzertifikat SHA-1 oder SHA-256 war.Previously, it was signed with SHA1 regardless of whether the code-signing certificate was SHA-1 or SHA-256. Dies gilt für:This applies to:
  • Alle Anwendungen, die mit Visual Studio 2012 oder höher erstellt wurden.All applications built with Visual Studio 2012 or later.
  • Anwendungen, die mit Visual Studio 2010 oder früher auf Systemen mit vorhandenem .NET Framework 4.5 erstellt wurden.Applications built with Visual Studio 2010 or earlier on systems with the .NET Framework 4.5 present.
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.In addition, if the .NET Framework 4.5 or later is present, the ClickOnce manifest is also signed with SHA-256 for SHA-256 certificates regardless of the .NET Framework version against which it was compiled.
VorschlagSuggestion Die Änderung bei der Signierung der ausführbaren ClickOnce-Datei wirkt sich nur auf Windows Server 2003-Systeme aus. Für diese ist die Installation von „KB 938397“ erforderlich. Durch die Änderung bei der Signierung des Manifests mit SHA-256 wird selbst dann eine Laufzeitabhängigkeit von .NET Framework 4.5 oder einer höheren Version eingeführt, wenn eine App .NET Framework 4.0 oder eine niedrigere Version als Zielplattform verwendet.The change in signing the ClickOnce executable affects only Windows Server 2003 systems; they require that KB 938397 be installed.The change in signing the manifest with SHA-256 even when an app targets the .NET Framework 4.0 or earlier versions introduces a runtime dependency on the .NET Framework 4.5 or a later version.
BereichScope Microsoft EdgeEdge
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting

ClickOnce unterstützt SHA-256 auf Apps, die auf 4.0 ausgerichtet sindClickOnce supports SHA-256 on 4.0-targeted apps

DetailsDetails 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.Previously, a ClickOnce app with a certificate signed with SHA-256 would require .NET Framework 4.5 or later to be present, even if the app targeted 4.0. 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.Now, .NET Framework 4.0-targeted ClickOnce apps can run on .NET Framework 4.0, even if signed with SHA-256.
VorschlagSuggestion 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.This change removes that dependency and allows SHA-256 certificates to be used to sign ClickOnce apps that target .NET Framework 4 and earlier versions.
BereichScope GeringMinor
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting

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

Änderung bei Pfadtrennzeichen in der FullName-Eigenschaft von ZipArchiveEntry-ObjektenChange in path separator character in FullName property of ZipArchiveEntry objects

DetailsDetails Bei Apps für .NET Framework 4.6.1 und höhere Versionen hat sich das Pfadtrennzeichen in der FullName-Eigenschaft von ZipArchiveEntry-Objekten, die durch Überladungen der CreateFromDirectory-Methode erstellt wurden, von einem umgekehrten Schrägstrich ("") in einen normalen Schrägstrich ("/") geändert.For apps that target the .NET Framework 4.6.1 and later versions, the path separator character has changed from a backslash ("") to a forward slash ("/") in the FullName property of ZipArchiveEntry objects created by overloads of the CreateFromDirectory method. 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.The change brings the .NET implementation into conformity with section 4.4.17.1 of the .ZIP File Format Specification and allows .ZIP archives to be decompressed on non-Windows systems.
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.Decompressing a zip file created by an app that targets a previous version of the .NET Framework on non-Windows operating systems such as the Macintosh fails to preserve the directory structure. Beispielsweise werden auf einem Macintosh mehrere Dateien erstellt, deren Dateinamen eine Verkettung aus dem Verzeichnispfad, allen vorhandenen umgekehrten Schrägstrichzeichen ("") und dem Dateinamen darstellen.For example, on the Macintosh, it creates a set of files whose filename concatenates the directory path, along with any backslash ("") characters, and the filename. Im Ergebnis wird die Verzeichnisstruktur der dekomprimierten Dateien nicht beibehalten.As a result, the directory structure of decompressed files is not preserved.
VorschlagSuggestion Die Auswirkungen dieser Änderungen auf ZIP-Dateien, die unter dem Windows-Betriebssystem durch die APIs im .NET Framework System.IO-Namespace dekomprimiert werden, sollten minimal sein, da diese APIs sowohl den einfachen Schrägstrich („/“) als auch den umgekehrten Schrägstrich („\“) als Pfadtrennzeichen verarbeiten können.The impact of this change on .ZIP files that are decompressed on the Windows operating system by APIs in the .NET Framework System.IO namespace should be minimal, since these APIs can seamlessly handle either a slash ("/") or a backslash ("\") as the path separator character.
Wenn diese Änderung nicht erwünscht ist, können Sie sich dagegen entscheiden, indem Sie dem Abschnitt <runtime> Ihrer Anwendungskonfigurationsdatei eine Konfigurationseinstellung hinzufügen.If this change is undesirable, you can opt out of it by adding a configuration setting to the <runtime> section of your application configuration file. Im folgenden Beispiel sind sowohl der Abschnitt <runtime> als auch die Ablehnungsoption Switch.System.IO.Compression.ZipFile.UseBackslash dargestellt:The following example shows both the <runtime> section and the Switch.System.IO.Compression.ZipFile.UseBackslash opt-out switch:
<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.In addition, apps that target previous versions of the .NET Framework but are running on the .NET Framework 4.6.1 and later versions can opt in to this behavior by adding a configuration setting to the <runtime> section of the application configuration file. Im Folgenden sind sowohl der Abschnitt <runtime> als auch die Option Switch.System.IO.Compression.ZipFile.UseBackslash zur Verwendung dieses Verhaltens dargestellt.The following shows both the <runtime> section and the Switch.System.IO.Compression.ZipFile.UseBackslash opt-in switch.
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
BereichScope Microsoft EdgeEdge
VersionVersion 4.6.14.6.1
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

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

Entity FrameworkEntity Framework

Beim Erstellen einer Entity Framework-EDMX-Datei mit Visual Studio 2013 kann der Fehler MSB4062 auftreten, wenn die Aufgabe „EntityDeploySplit“ oder „EntityClean“ verwendet wirdBuilding an Entity Framework edmx with Visual Studio 2013 can fail with error MSB4062 if using the EntityDeploySplit or EntityClean tasks

DetailsDetails MSBuild 12.0-Tools (enthalten in Visual Studio 2013) haben die MSBuild-Dateispeicherorte geändert, wodurch ältere Entity Framework-Zieldateien ungültig geworden sind.MSBuild 12.0 tools (included in Visual Studio 2013) changed MSBuild file locations, causing older Entity Framework targets files to be invalid. Das führt dazu, dass EntityDeploySplit- und EntityClean-Aufgaben fehlschlagen, da sie Microsoft.Data.Entity.Build.Tasks.dll nicht finden können.The result is that EntityDeploySplit and EntityClean tasks fail because they are unable to find Microsoft.Data.Entity.Build.Tasks.dll. Beachten Sie, dass dieses Problem aufgrund einer Änderung des Toolsets (MSBuild/VS) und nicht aufgrund einer Änderung an .NET Framework auftritt.Note that this break is because of a toolset (MSBuild/VS) change, not because of a .NET Framework change. Es tritt nur beim Upgrade von Entwicklertools und nicht beim Aktualisieren von .NET Framework auf.It will only occur when upgrading developer tools, not when merely upgrading the .NET Framework.
VorschlagSuggestion 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.Entity Framework targets files are fixed to work with the new MSBuild layout beginning in the .NET Framework 4.6. Ein Upgrade auf diese Version von .NET Framework wird dieses Problem beheben.Upgrading to that version of the Framework will fix this issue. Alternativ können Sie diese Problemumgehung verwenden, um die Zieldateien direkt zu patchen.Alternatively, this workaround can be used to patch the targets files directly.
BereichScope HauptversionMajor
VersionVersion 4.5.14.5.1
TypType NeuzuweisungRetargeting

JITJIT

Die IL-ret-Anweisung ist in einem try-Block nicht zulässigIL ret not allowed in a try region

DetailsDetails Im Gegensatz zum JIT64-Compiler lässt (in .NET Framework 4.6 verwendets) RyuJIT keine IL-ret-Anweisung in einem „try“-Block zu.Unlike the JIT64 just-in-time compiler, RyuJIT (used in .NET Framework 4.6) does not allow an IL ret instruction in a try region. 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.Returning from a try region is disallowed by the ECMA-335 specification, and no known managed compiler generates such IL. Allerdings führt der JIT64-Compiler solche IL aus, wenn sie mithilfe von Reflektionsausgabe generiert wurde.However, the JIT64 compiler will execute such IL if it is generated using reflection emit.
VorschlagSuggestion 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.If an app is generating IL that includes a ret opcode in a try region, the app may target .NET Framework 4.5 to use the old JIT and avoid this break. Alternativ kann die generierte IL aktualisiert und nach dem try-Block zurückgegeben werden.Alternatively, the generated IL may be updated to return after the try region.
BereichScope Microsoft EdgeEdge
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting

Neuer 64-Bit-JIT-Compiler in .NET Framework 4.6New 64-bit JIT compiler in the .NET Framework 4.6

DetailsDetails Ab .NET Framework 4.6 wird ein neuer 64-Bit-JIT-Compiler für die Just-in-Time-Kompilierung verwendet.Starting with the .NET Framework 4.6, a new 64-bit JIT compiler is used for just-in-time compilation. 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.In some cases, an unexpected exception is thrown or a different behavior is observed than if an app is run using the 32-bit compiler or the older 64-bit JIT compiler. Diese Änderung wirkt sich nicht auf den 32-Bit-JIT-Compiler aus. Die bekannten Unterschiede umfassen Folgendes:This change does not affect the 32-bit JIT compiler.The known differences include the following:
  • Unter bestimmten Umständen kann ein Unboxingvorgang in Releasebuilds mit aktivierter Optimierung eine NullReferenceException-Ausnahme auslösen.Under certain conditions, an unboxing operation may throw a NullReferenceException in Release builds with optimization turned on.
  • In manchen Fällen kann bei der Ausführung von Produktionscode in einem großen Methodentext eine StackOverflowException-Ausnahme ausgelöst werden.In some cases, execution of production code in a large method body may throw a StackOverflowException.
  • Unter bestimmten Bedingungen werden in Releasebuilds an eine Methode übergebene Strukturen als Verweistypen statt als Werttypen behandelt.Under certain conditions, structures passed to a method are treated as reference types rather than as value types in Release builds. Eins der Anzeichen dieses Problems besteht darin, dass die einzelnen Elemente einer Sammlung in unerwarteter Reihenfolge angezeigt werden.One of the manifestations of this issue is that the individual items in a collection appear in an unexpected order.
  • Unter bestimmten Bedingungen ist der Vergleich von UInt16-Werten mit festgelegtem hohem Bit fehlerhaft, wenn Optimierung aktiviert ist.Under certain conditions, the comparison of UInt16 values with their high bit set is incorrect if optimization is enabled.
  • Unter bestimmten Umständen, insbesondere beim Initialisieren von Arraywerten, kann die Speicherinitialisierung durch die IL-Anweisung OpCodes.Initblk mit einem falschen Wert erfolgen.Under certain conditions, particularly when initializing array values, memory initialization by the OpCodes.Initblk IL instruction may initialize memory with an incorrect value. Dies kann entweder zu einem Ausnahmefehler oder zu einer falschen Ausgabe führen.This can result either in an unhandled exception or incorrect output.
  • Unter bestimmten seltenen Bedingungen kann ein bedingter Bittest den falschen Boolean-Wert zurückgeben oder eine Ausnahme auslösen, wenn Compileroptimierungen aktiviert sind.Under certain rare conditions, a conditional bit test can return the incorrect Boolean value or throw an exception if compiler optimizations are enabled.
  • Wenn unter bestimmten Umständen eine if-Anweisung für die Prüfung auf eine Bedingung vor dem Eintritt in einen try-Block oder 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.Under certain conditions, if an if statement is used to test for a condition before entering a try block and in the exit from the try block, and the same condition is evaluated in the catch or finally block, the new 64-bit JIT compiler removes the if condition from the catch or finally block when it optimizes code. Daher wird Code innerhalb der if-Anweisung im catch- oder finally-Block ohne Bedingung ausgeführt.As a result, code inside the if statement in the catch or finally block is executed unconditionally.
VorschlagSuggestion Entschärfung bekannter ProblemeMitigation of known issues
Wenn bei Ihnen die oben aufgeführten Probleme auftreten, können Sie darauf mit einer der folgenden Maßnahmen reagieren:If you encounter the issues listed above, you can address them by doing any of the following:
  • Ausführen eines Upgrades auf .NET Framework 4.6.2.Upgrade to the .NET Framework 4.6.2. Der neue 64-Bit-Compiler, der in .NET Framework 4.6.2 enthalten ist, behebt jedes dieser bekannten Probleme.The new 64-bit compiler included with the .NET Framework 4.6.2 addresses each of these known issues.
  • Stellen Sie sicher, dass ihre Windows-Version auf dem aktuellen Stand ist, indem Sie Windows Update ausführen.Ensure that your version of Windows is up to date by running Windows Update. Serviceupdates für .NET Framework 4.6 und 4.6.1 beheben jedes dieser Probleme, mit Ausnahme der NullReferenceException-Ausnahme bei Unboxingvorgängen.Service updates to the .NET Framework 4.6 and 4.6.1 address each of these issues except the NullReferenceException in an unboxing operation.
  • Kompilieren Sie mit dem älteren 64-Bit-JIT-Compiler.Compile with the older 64-bit JIT compiler. Informationen zum Vorgehen dazu finden Sie unter Entschärfung anderer Probleme.See the Mitigation of other issues section for more information on how to do this.
Entschärfung anderer ProblemeMitigation of other issues
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:If you encounter any other difference in behavior between code compiled with the older 64-bit compiler and the new 64-bit JIT compiler, or between the debug and release versions of your app that are both compiled with the new 64-bit JIT compiler, you can do the following to compile your app with the older 64-bit JIT compiler:
  • Sie können der Konfigurationsdatei Ihrer Anwendung auf Anwendungsbasis das <-Element hinzufügen.On a per-application basis, you can add the < element to your application's configuration file. Die folgende Anweisung deaktiviert die Kompilierung mit dem neuen 64-Bit-JIT-Compiler und verwendet stattdessen den 64-Bit-Legacy-JIT-Compiler.The following disables compilation with the new 64-bit JIT compiler and instead uses the legacy 64-bit 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.On a per-user basis, you can add a REG_DWORD value named useLegacyJit to the HKEY_CURRENT_USER\SOFTWARE\Microsoft.NETFramework key of the registry. Der Wert 1 aktiviert den 64-Bit-Legacy-JIT-Compiler, der Wert 0 deaktiviert ihn und aktiviert stattdessen den neuen 64-Bit-JIT-Compiler.A value of 1 enables the legacy 64-bit JIT compiler; a value of 0 disables it and enables the new 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.On a per-machine basis, you can add a REG_DWORD value named useLegacyJit to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework key of the registry. Der Wert 1 aktiviert den 64-Bit-Legacy-JIT-Compiler, der Wert 0 deaktiviert ihn und aktiviert stattdessen den neuen 64-Bit-JIT-Compiler.A value of 1 enables the legacy 64-bit JIT compiler; a value of 0 disables it and enables the new 64-bit JIT compiler.
Ferner können Sie uns über das Problem informieren, indem Sie einen Bug auf Microsoft Connect melden.You can also let us know about the problem by reporting a bug on Microsoft Connect.
BereichScope Microsoft EdgeEdge
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting

NetzwerkNetworking

EKU-OID-ZertifikatüberprüfungCertificate EKU OID validation

DetailsDetails 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.Starting with .NET Framework 4.6, the SslStream or ServicePointManager classes perform enhanced key use (EKU) object identifier (OID) validation. Eine EKU-Erweiterung ist eine Sammlung von OIDs, die Anwendungen kennzeichnen, die den Schlüssel verwenden.An enhanced key usage (EKU) extension is a collection of object identifiers (OIDs) that indicate the applications that use the key. 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.EKU OID validation uses remote certificate callbacks to ensure that the remote certificate has the correct OIDs for the intended purpose.
VorschlagSuggestion Wenn diese Änderung nicht erwünscht ist, können Sie die EKU-OID-Zertifikatüberprüfung deaktivieren, indem Sie die folgende Option <AppContextSwitchOverrides> im `-Element Ihrer Anwendungskonfigurationsdatei hinzufügen:If this change is undesirable, you can disable certificate EKU OID validation by adding the following switch to the <AppContextSwitchOverrides> in the ` of your app configuration file:
<runtime>
<AppContextSwitchOverrides
value="Switch.System.Net.DontCheckCertificateEKUs=true" />
</runtime>
[!IMPORTANT] Diese Einstellung wird lediglich aus Gründen der Abwärtskompatibilität bereitgestellt.This setting is provided for backward compatibility only. Abgesehen davon wird die Verwendung nicht empfohlen.Its use is otherwise not recommended.
BereichScope GeringMinor
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Der Standardwert von ServicePointManager.SecurityProtocol ist SecurityProtocolType.System.DefaultDefault value of ServicePointManager.SecurityProtocol is SecurityProtocolType.System.Default

DetailsDetails Bei Apps mit der Zielplattform .NET Framework 4.7 und höher ist der Standardwert der ServicePointManager.SecurityProtocol-Eigenschaft SecurityProtocolType.SystemDefault.Starting with apps that target the .NET Framework 4.7, the default value of the ServicePointManager.SecurityProtocol property is SecurityProtocolType.SystemDefault. Diese Änderungen ermöglicht den Netzwerk-APIs von .NET Framework, die auf SslStream (z.B. FTP, HTTPS und SMTP) basieren, die Standardsicherheitsprotokolle des Betriebssystems zu erben, anstatt hartcodierte Werte zu verwenden, die von .NET Framework definiert werden.This change allows .NET Framework networking APIs based on SslStream (such as FTP, HTTPS, and SMTP) to inherit the default security protocols from the operating system instead of using hard-coded values defined by the .NET Framework. Der Standard variiert je nach Betriebssystem und sämtlichen benutzerdefinierten Konfigurationen, die vom Systemadministrator vorgenommen werden.The default varies by operating system and any custom configuration performed by the system administrator. Informationen zum standardmäßigen SChannel-Protokoll in der jeweiligen Version des Windows-Betriebssystems finden Sie unter Protokolle in TLS/SSL (SChannel SSP).For information on the default SChannel protocol in each version of the Windows operating system, see Protocols in TLS/SSL (Schannel SSP).

Bei Anwendungen, die auf eine frühere Version des .NET-Frameworks ausgelegt sind, hängt der Standardwert der ServicePointManager.SecurityProtocol-Eigenschaft von der .NET Framework-Zielversion ab.For applications that target an earlier version of the .NET Framework, the default value of the ServicePointManager.SecurityProtocol property depends on the version of the .NET Framework targeted. Weitere Informationen finden Sie im Abschnitt „Netzwerk“ des Artikels „Neuzuweisung von Änderungen für die Migration von .NET Framework 4.5.2 zu 4.6“.See the Networking section of Retargeting Changes for Migration from .NET Framework 4.5.2 to 4.6 for more information.

VorschlagSuggestion Diese Änderung betrifft nur Anwendungen, die auf .NET Framework 4.7 oder höher ausgelegt sind.This change affects applications that target the .NET Framework 4.7 or later versions.
Wenn Sie lieber ein definiertes Protokoll anstelle des Systemstandards verwenden möchten, können Sie den Wert der ServicePointManager.SecurityProtocol-Eigenschaft explizit festlegen.If you prefer to use a defined protocol rather than relying on the system default, you can explicitly set the value of the ServicePointManager.SecurityProtocol property.
Wenn diese Änderung nicht erwünscht ist, können Sie sich dagegen entscheiden, indem Sie dem Abschnitt <runtime> Ihrer Anwendungskonfigurationsdatei eine Konfigurationseinstellung hinzufügen.If this change is undesirable, you can opt out of it by adding a configuration setting to the <runtime> section of your application configuration file. Im folgenden Beispiel sind sowohl der Abschnitt <runtime> als auch die Ablehnungsoption Switch.System.Net.DontEnableSystemDefaultTlsVersions dargestellt:The following example shows both the <runtime> section and the Switch.System.Net.DontEnableSystemDefaultTlsVersions opt-out switch:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=true" />
</runtime>
BereichScope GeringMinor
VersionVersion 4.74.7
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Nur die Protokolle TLS 1.0, 1.1 und 1.2 werden in System.Net.ServicePointManager und System.Net.Security.SslStream unterstütztOnly Tls 1.0, 1.1 and 1.2 protocols supported in System.Net.ServicePointManager and System.Net.Security.SslStream

DetailsDetails 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.Starting with the .NET Framework 4.6, the ServicePointManager and SslStream classes are only allowed to use one of the following three protocols: Tls1.0, Tls1.1, or Tls1.2. Weder das SSL3.0-Protokoll noch das RC4-Verschlüsselungsverfahren werden unterstützt.The SSL3.0 protocol and RC4 cipher are not supported.
VorschlagSuggestion Die empfohlene Risikominderung besteht darin, für die serverseitige App ein Upgrade auf TLS 1.0, TLS 1.1 oder TLS 1.2 vorzunehmen.The recommended mitigation is to upgrade the sever-side app to Tls1.0, Tls1.1, or Tls1.2. Wenn dies nicht möglich ist oder die Client-Apps fehlerhaft sind, kann die Klasse AppContext verwendet werden, um das Feature auf zwei verschiedene Art und Weisen abzuwählen: If this is not feasible, or if client apps are broken, the AppContext class can be used to opt out of this feature in either of two ways:
  1. durch programmgesteuertes Festlegen von Kompatibilitätsoptionen für AppContext, wie hier beschrieben wirdBy programmatically setting compat switches on the AppContext, as explained here
  2. durch Hinzufügen der folgenden Zeile zum Abschnitt <runtime> der Datei „app.config“: <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>By adding the following line to the <runtime> section of the app.config file: <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>;
BereichScope GeringMinor
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

SslStream unterstützt TLS-WarnungenSslStream supports TLS Alerts

DetailsDetails Nach einem fehlgeschlagenen TLS-Handshake wird eine IOException mit einer inneren Win32Exception von dem ersten E/A-Lese-/Schreibvorgang ausgelöst.After a failed TLS handshake, an IOException with an inner Win32Exception exception will be thrown by the first I/O Read/Write operation. Der NativeErrorCode-Code für die Win32Exception kann der TLS-Warnung von der Remotepartei mit den Schannel-Fehlercodes für TLS- und SSL-Warnungen zugeordnet werden.The NativeErrorCode code for the Win32Exception can be mapped to the TLS Alert from the remote party using the Schannel error codes for TLS and SSL alerts. Weitere Informationen finden Sie unter RFC 2246: Abschnitt 7.2.2, Fehlerwarnungen.For more information, see RFC 2246: Section 7.2.2 Error alerts.
Das Verhalten in .NET Framework 4.6.2 und früheren Versionen besteht darin, dass für den Transportkanal (in der Regel eine TCP-Verbindung) ein Timeout während des Schreib- oder Lesevorgangs auftritt, wenn beim Handshake bei der anderen Partei ein Fehler aufgetreten ist und die Verbindung unmittelbar danach zurückgewiesen wurde.The behavior in .NET Framework 4.6.2 and earlier is that the transport channel (usually TCP connection) will timeout during either Write or Read if the other party failed the handshake and immediately afterwards rejected the connection.
VorschlagSuggestion Anwendungen, die Netzwerk-E/A-APIs aufrufen (z.B. Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32)) sollten IOException oder TimeoutException verarbeiten.Applications calling network I/O APIs such as Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) should handle IOException or TimeoutException.
Die TLS-Warnfunktion ist ab .NET Framework 4.7 standardmäßig aktiviert.The TLS Alerts feature is enabled by default starting with .NET Framework 4.7. Für Anwendungen für Versionen von .NET Framework von 4.0 bis 4.6.2, die auf einem System mit .NET Framework 4.7 oder höher ausgeführt werden, ist diese Funktion deaktiviert, um die Kompatibilität zu erhalten.Applications targeting versions of the .NET Framework from 4.0 through 4.6.2 running on a .NET Framework 4.7 or higher system will have the feature disabled to preserve compatibility.
Die folgende Konfigurations-API ist zum Aktivieren oder Deaktivieren des Features für .NET Framework 4.6- oder höhere Anwendungen, die unter .NET Framework 4.7 oder höher ausgeführt werden, verfügbar.The following configuration API is available to enable or disable the feature for .NET Framework 4.6 and later applications running on .NET Framework 4.7 or later.
  • Programmgesteuert:Programmatically:
Die folgenden Methoden müssen unmittelbar nach dem Anwendungsstart aufgerufen werden, da ServicePointManager nur einmal initialisiert wird:Must be the very first thing the application does since ServicePointManager will initialize only once:
AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true);
AppContext.SetSwitch("Switch.System.Net.DontEnableTlsAlerts", true); // Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2.
  • AppConfig:AppConfig:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableTlsAlerts=true"/>
<!-- Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. -->
</runtime>
  • Registrierungsschlüssel (globaler Wert für einen Computer):Registry key (machine global):

    Legen Sie den Wert auf false fest, um das Feature in .NET Framework 4.6 bis 4.6.2 zu aktivieren.Set the Value to false to enable the feature in .NET Framework 4.6 - 4.6.2.

    • >Schlüssel: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts>Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts
    • Typ: ZeichenfolgeType: String
    • Wert: "TRUE&quotValue: "true&quot
BereichScope Microsoft EdgeEdge
VersionVersion 4.74.7
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

TLS 1.x übergibt standardmäßig das Flag SCH_SEND_AUX_RECORD an die zugrunde liegende SCHANNEL-APITLS 1.x by default passes the SCH_SEND_AUX_RECORD flag to the underlying SCHANNEL API

DetailsDetails Bei Nutzung von TLS 1 verwendet .NET Framework die zugrunde liegende Windows-SCHANNEL-API.When using TLS 1.x, the .NET Framework relies on the underlying Windows SCHANNEL API. Ab .NET Framework 4.6 wird das Flag SCH_SEND_AUX_RECORD standardmäßig an SCHANNEL übergeben.Starting with .NET Framework 4.6, the SCH_SEND_AUX_RECORD flag is passed by default to SCHANNEL. 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.This causes SCHANNEL to split data to be encrypted into two separate records, the first as a single byte and the second as 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.In rare cases, this breaks communication between clients and existing servers that make the assumption that the data resides in a single record.
VorschlagSuggestion Wenn diese Änderung die Kommunikation mit einem vorhandenen Server unterbricht, können Sie das Senden des SCH_SEND_AUX_RECORD-Flags deaktivieren und das vorherige Verhalten wiederherstellen, Daten nicht in separate Datensätze aufzuteilen, indem Sie den folgenden Schalter zum Element <AppContextSwitchOverrides> im Abschnitt <runtime> Ihrer App-Konfigurationsdatei hinzufügen:If this change breaks communication with an existing server, you can disable sending the SCH_SEND_AUX_RECORD flag and restore the previous behavior of not splitting data into separate records by adding the following switch to the <AppContextSwitchOverrides> element in the <runtime> section of your app configuration file:
<runtime>
<AppContextSwitchOverrides
value="Switch.System.Net.DontEnableSchSendAuxRecord=true" />
</runtime>
[!IMPORTANT] Diese Einstellung wird lediglich aus Gründen der Abwärtskompatibilität bereitgestellt.This setting is provided for backward compatibility only. Abgesehen davon wird die Verwendung nicht empfohlen.Its use is otherwise not recommended.
BereichScope Microsoft EdgeEdge
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

SicherheitSecurity

CspParameters.ParentWindowHandle erwartet nun einen HWND-WertCspParameters.ParentWindowHandle now expects HWND value

DetailsDetails Der ParentWindowHandle-Wert, der in .NET Framework 2.0 eingeführt wurde, ermöglicht einer Anwendung die Registrierung eines Handlewerts für das übergeordnete Fenster, sodass jedes Benutzeroberflächenelement, das auf den Schlüssel zugreifen muss (wie etwa eine PIN-Eingabeaufforderung oder ein Zustimmungsdialogfeld), als untergeordnetes modales Fenster des angegebenen Fensters geöffnet wird. Für eine Windows Forms-App, deren Zielplattform .NET Framework 4.7 oder höher ist, kann die Eigenschaft ParentWindowHandle beispielsweise mit dem folgenden Code festgelegt werden:The ParentWindowHandle value, introduced in .NET Framework 2.0, allows an application to register a parent window handle value such that any UI required to access the key (such as a PIN prompt or consent dialog) opens as a modal child to the specified window.Starting with apps that target the .NET Framework 4.7, a Windows Forms application can set the ParentWindowHandle property with code like the following:
cspParameters.ParentWindowHandle = form.Handle;
In früheren Versionen von .NET Framework wurde erwartet, dass der Wert ein IntPtr-Objekt ist, das einen Speicherort im Arbeitsspeicher darstellt, an dem sich der HWND-Wert befindet.In previous versions of the .NET Framework, the value was expected to be an IntPtr representing a location in memory where the HWND value resided. Das Festlegen der Eigenschaft auf form.Handle hatte unter Windows 7 und früheren Versionen keine Auswirkungen, unter Windows 8 und höheren Versionen resultiert dies jedoch in einer "CryptographicException: The parameter is incorrect. (Der Parameter ist falsch)."Setting the property to form.Handle on Windows 7 and earlier versions had no effect, but on Windows 8 and later versions, it results in a "CryptographicException: The parameter is incorrect."
VorschlagSuggestion Für Apps mit der Zielplattform .NET Framework 4.7 oder höher, die eine übergeordnete Fensterbeziehung registrieren sollen, wird die Verwendung eines vereinfachten Formulars wie dem folgenden empfohlen:Applications targeting .NET Framework 4.7 or higher wishing to register a parent window relationship are encouraged to use the simplified form:
cspParameters.ParentWindowHandle = form.Handle;
Einige Benutzer haben erkannt, dass der richtige zu übergebende Wert die Adresse eines Speicherorts im Arbeitsspeicher war, der den Wert form.Handle enthielt. Benutzer können sich gegen dieses geänderte Verhalten entscheiden, indem sie die AppContext-Option Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle auf true festlegen. Dies kannUsers who had identified that the correct value to pass was the address of a memory location which held the value form.Handle can opt out of the behavior change by setting the AppContext switch Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle to true.
  1. durch programmgesteuertes Festlegen von Kompatibilitätsoptionen für AppContext, wie hier beschrieben wird,By programmatically setting compat switches on the AppContext, as explained here
  2. Durch Hinzufügen der folgenden Zeile zum Abschnitt <runtime> der app.config-Datei:By adding the following line to the <runtime> section of the app.config file:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle=true"/>
</runtime>
Benutzer, die sich umgekehrt für das neue Verhalten der Laufzeit von .NET Framework 4.7 entscheiden, können die AppContext-Option auf false festlegen, wenn die Anwendung in älteren Versionen von .NET Framework geladen wird.Conversely, users who wish to opt in to the new behavior on the .NET Framework 4.7 runtime when the application loads under older .NET Framework versions can set the AppContext switch to false.
BereichScope GeringMinor
VersionVersion 4.74.7
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

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

SslStream unterstützt TLS-WarnungenSslStream supports TLS Alerts

DetailsDetails Nach einem fehlgeschlagenen TLS-Handshake wird eine IOException mit einer inneren Win32Exception von dem ersten E/A-Lese-/Schreibvorgang ausgelöst.After a failed TLS handshake, an IOException with an inner Win32Exception exception will be thrown by the first I/O Read/Write operation. Der NativeErrorCode-Code für die Win32Exception kann der TLS-Warnung von der Remotepartei mit den Schannel-Fehlercodes für TLS- und SSL-Warnungen zugeordnet werden.The NativeErrorCode code for the Win32Exception can be mapped to the TLS Alert from the remote party using the Schannel error codes for TLS and SSL alerts. Weitere Informationen finden Sie unter RFC 2246: Abschnitt 7.2.2, Fehlerwarnungen.For more information, see RFC 2246: Section 7.2.2 Error alerts.
Das Verhalten in .NET Framework 4.6.2 und früheren Versionen besteht darin, dass für den Transportkanal (in der Regel eine TCP-Verbindung) ein Timeout während des Schreib- oder Lesevorgangs auftritt, wenn beim Handshake bei der anderen Partei ein Fehler aufgetreten ist und die Verbindung unmittelbar danach zurückgewiesen wurde.The behavior in .NET Framework 4.6.2 and earlier is that the transport channel (usually TCP connection) will timeout during either Write or Read if the other party failed the handshake and immediately afterwards rejected the connection.
VorschlagSuggestion Anwendungen, die Netzwerk-E/A-APIs aufrufen (z.B. Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32)) sollten IOException oder TimeoutException verarbeiten.Applications calling network I/O APIs such as Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) should handle IOException or TimeoutException.
Die TLS-Warnfunktion ist ab .NET Framework 4.7 standardmäßig aktiviert.The TLS Alerts feature is enabled by default starting with .NET Framework 4.7. Für Anwendungen für Versionen von .NET Framework von 4.0 bis 4.6.2, die auf einem System mit .NET Framework 4.7 oder höher ausgeführt werden, ist diese Funktion deaktiviert, um die Kompatibilität zu erhalten.Applications targeting versions of the .NET Framework from 4.0 through 4.6.2 running on a .NET Framework 4.7 or higher system will have the feature disabled to preserve compatibility.
Die folgende Konfigurations-API ist zum Aktivieren oder Deaktivieren des Features für .NET Framework 4.6- oder höhere Anwendungen, die unter .NET Framework 4.7 oder höher ausgeführt werden, verfügbar.The following configuration API is available to enable or disable the feature for .NET Framework 4.6 and later applications running on .NET Framework 4.7 or later.
  • Programmgesteuert:Programmatically:
Die folgenden Methoden müssen unmittelbar nach dem Anwendungsstart aufgerufen werden, da ServicePointManager nur einmal initialisiert wird:Must be the very first thing the application does since ServicePointManager will initialize only once:
AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true);
AppContext.SetSwitch("Switch.System.Net.DontEnableTlsAlerts", true); // Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2.
  • AppConfig:AppConfig:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableTlsAlerts=true"/>
<!-- Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. -->
</runtime>
  • Registrierungsschlüssel (globaler Wert für einen Computer):Registry key (machine global):

    Legen Sie den Wert auf false fest, um das Feature in .NET Framework 4.6 bis 4.6.2 zu aktivieren.Set the Value to false to enable the feature in .NET Framework 4.6 - 4.6.2.

    • >Schlüssel: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts>Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts
    • Typ: ZeichenfolgeType: String
    • Wert: "TRUE&quotValue: "true&quot
BereichScope Microsoft EdgeEdge
VersionVersion 4.74.7
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Visual Basic .NETVisual Basic .NET

VB.NET unterstützt die Angabe partieller Namespaces für System.Windows-APIs nicht mehrVB.NET no longer supports partial namespace qualification for System.Windows APIs

DetailsDetails Ab .NET Framework 4.5.2 können VB.NET-Projekte keine System.Windows-APIs mit teilweise qualifizierten Namespaces angeben.Beginning in .NET Framework 4.5.2, VB.NET projects cannot specify System.Windows APIs with partially-qualified namespaces. Der Verweis auf Windows.Forms.DialogResult führt z. B. zu einem Fehler.For example, referring to Windows.Forms.DialogResult will fail. Stattdessen muss der Code auf den vollqualifizierten Namen (DialogResult) verweisen oder den bestimmten Namespace importieren und dann einfach auf DialogResult verweisen.Instead, code must refer to the fully qualified name (DialogResult) or import the specific namespace and refer simply to DialogResult.
VorschlagSuggestion Der Code sollte aktualisiert werden, um auf System.Windows-APIs mit einfachen Namen (und den entsprechenden Namespace importieren) oder mit vollqualifizierten Namen zu verweisen.Code should be updated to refer to System.Windows APIs either with simple names (and importing the relevant namespace) or with fully qualified names.
BereichScope GeringMinor
VersionVersion 4.5.24.5.2
TypType NeuzuweisungRetargeting

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

Das Aufrufen von CreateDefaultAuthorizationContext mit einem NULL-Argument wurde geändertCalling CreateDefaultAuthorizationContext with a null argument has changed

DetailsDetails Die Implementierung des AuthorizationContext-Elements, das von einem Aufruf von CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) mit dem NULL-Wert als Argument „authorizationPolicies“ zurückgegeben wurde, hat seine Implementierung in .NET Framework 4.6 geändert.The implementation of the AuthorizationContext returned by a call to the CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) with a null authorizationPolicies argument has changed its implementation in the .NET Framework 4.6.
VorschlagSuggestion In seltenen Fällen liegen bei WCF-Apps, die die benutzerdefinierte Authentifizierung verwenden, möglicherweise Verhaltensunterschiede vor.In rare cases, WCF apps that use custom authentication may see behavioral differences. In derartigen Fällen gibt es zwei Möglichkeiten, um das vorherige Verhalten wiederherzustellen:In such cases, the previous behavior can be restored in either of two ways:
  1. Kompilieren Sie Ihre App erneut, damit sie auf eine frühere Version als .NET Framework 4.6 abzielt.Recompile your app to target an earlier version of the .NET Framework than 4.6. Verwenden Sie für mithilfe von IIS gehosteten Diensten das <httpRuntime targetFramework="x.x" />-Element, um Ihre Apps auf eine frühere Version von .NET Framework auszurichten.For IIS-hosted services, use the <httpRuntime targetFramework="x.x" /> element to target an earlier version of the .NET Framework.
  2. Fügen Sie dem Abschnitt <appSettings> Ihrer Datei „app.config“ die folgende Zeile hinzu: <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />Add the following line to the <appSettings> section of your app.config file: <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
BereichScope GeringMinor
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

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

Die Serialisierung von Steuerzeichen in DataContractJsonSerializer ist jetzt konform mit ECMAScript V6 und V8Serialization of control characters with DataContractJsonSerializer is now compatible with ECMAScript V6 and V8

DetailsDetails In .NET Framework 4.6.2 und früheren Versionen serialisierte der DataContractJsonSerializer einige besondere Steuerzeichen, wie etwa \b, \f und \t nicht in einer Weise, die mit den ECMAScript V6- und V8-Standards konform ist.In the .NET framework 4.6.2 and earlier versions, the DataContractJsonSerializer did not serialize some special control characters, such as \b, \f, and \t, in a way that was compatible with the ECMAScript V6 and V8 standards. Ab .NET Framework 4.7 ist die Serialisierung dieser Steuerzeichen mit ECMAScript V6 und V8 kompatibel.Starting with the .NET Framework 4.7, serialization of these control characters is compatible with ECMAScript V6 and V8.
VorschlagSuggestion Standardmäßig wird dieses neue Feature nur für Apps aktiviert, die für .NET Framework 4.7 konzipiert sind.For apps that target the .NET Framework 4.7, this feature is enabled by default. Wenn dieses Verhalten unerwünscht ist, können Sie sich gegen diese Funktion entscheiden, indem Sie dem Abschnitt <runtime> der app.config- oder web.config-Datei die folgende Zeile hinzufügen:If this behavior is not desirable, you can opt out of this feature by adding the following line to the <runtime> section of the app.config or web.config file:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseECMAScriptV6EscapeControlCharacter=false" />
</runtime>
BereichScope Microsoft EdgeEdge
VersionVersion 4.74.7
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

WCF-Bindung mit dem TransportWithMessageCredential-SicherheitsmodusWCF binding with the TransportWithMessageCredential security mode

DetailsDetails Ab .NET Framework 4.6.1 kann die WCF-Bindung, die den TransportWithMessageCredential-Sicherheitsmodus 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 weiter abgelehnt.Beginning in the .NET Framework 4.6.1, WCF binding that uses the TransportWithMessageCredential security mode can be set up to receive messages with unsigned "to" headers for asymmetric security keys.By default, unsigned "to" headers will continue to be rejected in .NET Framework 4.6.1. Sie werden nur akzeptiert, wenn eine Anwendung unter Verwendung des Switch.System.ServiceModel.AllowUnsignedToHeader-Konfigurationsschalters diesen neuen Vorgangsmodus aktiviert.They will only be accepted if an application opts into this new mode of operation using the Switch.System.ServiceModel.AllowUnsignedToHeader configuration switch.
VorschlagSuggestion Da diese Einstellung eine Opt-in-Funktion ist, sollte sie sich nicht auf das Verhalten vorhandener Apps auswirken.Because this is an opt-in feature, it should not affect the behavior of existing apps.
Verwenden Sie die folgende Konfigurationseinstellung, um zu steuern, ob das neue Verhalten verwendet werden soll:To control whether the new behavior is used or not, use the following configuration setting:
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
BereichScope TransparentTransparent
VersionVersion 4.6.14.6.1
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

WCF-Nachrichtensicherheit kann jetzt TLS1.1 und TLS1.2 verwendenWCF message security now is able to use TLS1.1 and TLS1.2

DetailsDetails Ab .NET Framework 4.7 können Kunden über die Anwendungskonfigurationseinstellungen neben SSL3.0 und TLS1.0 entweder TLS1.1 oder TLS1.2 in WCF-Nachrichtensicherheit konfigurieren.Starting in the .NET Framework 4.7, customers can configure either TLS1.1 or TLS1.2 in WCF message security in addition to SSL3.0 and TLS1.0 through application configuration settings.
VorschlagSuggestion In .NET Framework 4.7 werden TLS1.1 und TLS1.2 in WCF-Nachrichtensicherheit standardmäßig nicht unterstützt.In the .NET Framework 4.7, support for TLS1.1 and TLS1.2 in WCF message security is disabled by default. Sie können die Unterstützung aktivieren, indem Sie die folgende Zeile zum Abschnitt <runtime> der app.config- oder der web.config-Datei hinzufügen:You can enable it by adding the following line to the <runtime> section of the app.config or web.config file:
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>
BereichScope Microsoft EdgeEdge
VersionVersion 4.74.7
TypType NeuzuweisungRetargeting

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

X509CertificateClaimSet.FindClaims berücksichtigt alle claimTypes (Anspruchstypen)X509CertificateClaimSet.FindClaims Considers All claimTypes

DetailsDetails 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 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 FindClaims(String, String), das claimType-Argument nur mit dem neuesten DNS-Eintrag abzugleichen.In apps that target the .NET Framework 4.6.1, if an X509 claim set is initialized from a certificate that has multiple DNS entries in its SAN field, the FindClaims(String, String) method attempts to match the claimType argument with all the DNS entries.For apps that target previous versions of the .NET Framework, the FindClaims(String, String) method attempts to match the claimType argument only with the last DNS entry.
VorschlagSuggestion Diese Änderung wirkt sich nur auf Anwendungen aus, die auf .NET Framework 4.6.1 ausgerichtet sind.This change only affects applications targeting the .NET Framework 4.6.1. Diese Änderung kann mit dem DisableMultipleDNSEntries-Kompatibilitätsschalter deaktiviert werden (oder bei Versionen vor 4.6.1 aktiviert werden).This change may be disabled (or enabled if targeting pre-4.6.1) with the DisableMultipleDNSEntries compatibility switch.
BereichScope GeringMinor
VersionVersion 4.6.14.6.1
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Windows FormsWindows Forms

Application.FilterMessage löst für eintrittsinvariante Implementierungen von IMessageFilter.PreFilterMessage keine Ausnahmen mehr ausApplication.FilterMessage no longer throws for re-entrant implementations of IMessageFilter.PreFilterMessage

DetailsDetails Vor .NET Framework 4.6.1 verursachte das Aufrufen von FilterMessage(Message) mit PreFilterMessage(Message), die AddMessageFilter(IMessageFilter) oder RemoveMessageFilter(IMessageFilter) (bei gleichzeitigem Aufrufen von DoEvents()) aufrief, eine IndexOutOfRangeException.Prior to the .NET Framework 4.6.1, calling FilterMessage(Message) with an PreFilterMessage(Message) which called AddMessageFilter(IMessageFilter) or RemoveMessageFilter(IMessageFilter) (while also calling DoEvents()) would cause an IndexOutOfRangeException.

Seit der Verwendung von Anwendungen, die auf .NET Framework 4.6.1 abzielen, wird diese Ausnahme nicht mehr ausgelöst und es können eintrittsinvariante Filter verwendet werden, wie oben beschrieben.Beginning with applications targeting the .NET Framework 4.6.1, this exception is no longer thrown, and re-entrant filters as described above may be used.

VorschlagSuggestion Beachten Sie, dass FilterMessage(Message) keine Ausnahmen mehr für das oben beschriebene eintrittsinvariante PreFilterMessage(Message)-Verhalten auslöst.Be aware that FilterMessage(Message) will no longer throw for the re-entrant PreFilterMessage(Message) behavior described above. 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).This only affects applications targeting the .NET Framework 4.6.1.Apps targeting the .NET Framework 4.6.1 can opt out of this change (or apps targeting older Frameworks may opt in) by using the DontSupportReentrantFilterMessage compatibility switch.
BereichScope Microsoft EdgeEdge
VersionVersion 4.6.14.6.1
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

DataObject.GetData ruft Daten jetzt als UTF-8 abDataObject.GetData now retrieves data as UTF-8

DetailsDetails In Apps, die für .NET Framework 4 konzipiert sind oder die unter .NET Framework 4.5.1 oder früheren Versionen ausgeführt werden, ruft DataObject.GetData HTML-formatierte Daten als ASCII-Zeichenfolge ab.For apps that target the .NET Framework 4 or that run on the .NET Framework 4.5.1 or earlier versions, DataObject.GetData retrieves HTML-formatted data as an ASCII string. Als Resultat werden nicht-ASCII-Zeichen (Zeichen mit ASCII-Codes größer als 0x7F) durch zwei zufällige Zeichen dargestellt.As a result, non-ASCII characters (characters whose ASCII codes are greater than 0x7F) are represented by two random characters.

In Apps, die .NET Framework 4.5 oder eine neuere Version als Ziel verwenden und unter .NET Framework 4.5.2 ausgeführt werden, ruft DataObject.GetData HTML-formatierte Daten als UTF-8 ab und stellt Zeichen größer als „0x7F“ korrekt dar.For apps that target the .NET Framework 4.5 or later and run on the .NET Framework 4.5.2, DataObject.GetData retrieves HTML-formatted data as UTF-8, which represents characters greater than 0x7F correctly.

VorschlagSuggestion Wenn Sie eine Problemumgehung für das Codierungsproblem mit HTML-formatierten Zeichenfolgen implementiert haben (z.B. durch explizites Codieren der HTML-Zeichenfolge aus der Zwischenablage durch Übergabe an GetString(Byte[], Int32, Int32)) und das Ziel Ihrer App von Version 4 zu 4.5 neu zuweisen, sollten Sie diese Problemumgehung entfernen. Wenn das alte Verhalten benötigt wird, kann die App auf .NET Framework 4.0 ausgerichtet werden.If you implemented a workaround for the encoding problem with HTML-formatted strings (for example, by explicitly encoding the HTML string retrieved from the Clipboard by passing it to GetString(Byte[], Int32, Int32)) and you're retargeting your app from version 4 to 4.5, that workaround should be removed.If the old behavior is needed for some reason, the app can target the .NET Framework 4.0 to get that behavior.
BereichScope Microsoft EdgeEdge
VersionVersion 4.5.24.5.2
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Icon.ToBitmap konvertiert Symbole mit PNG-Frames erfolgreich in Bitmap-ObjekteIcon.ToBitmap successfully converts icons with PNG frames into Bitmap objects

DetailsDetails Beginnend mit den Apps für .NET Framework 4.6 konvertiert die Icon.ToBitmap-Methode Symbole mit PNG-Bildern erfolgreich in „Bitmap“-Objekte.Starting with the apps that target the .NET Framework 4.6, the Icon.ToBitmap method successfully converts icons with PNG frames into Bitmap objects.

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 aufweist.In apps that target the .NET Framework 4.5.2 and earlier versions, the Icon.ToBitmap method throws an ArgumentOutOfRangeException exception if the Icon object has PNG frames.

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.This change affects apps that are recompiled to target the .NET Framework 4.6 and that implement special handling for the ArgumentOutOfRangeException that is thrown when an Icon object has PNG frames. 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.When running under the .NET Framework 4.6, the conversion is successful, an ArgumentOutOfRangeException is no longer thrown, and therefore the exception handler is no longer invoked.

VorschlagSuggestion 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:If this behavior is undesirable, you can retain the previous behavior by adding the following element to the <runtime> section of your app.config file:
<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:If the app.config file already contains the AppContextSwitchOverrides element, the new value should be merged with the value attribute like this:
<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
BereichScope GeringMinor
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

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)

NullReferenceException im Ausnahmebehandlungscode von ImageSourceConverter.ConvertFromNullReferenceException in exception handling code from ImageSourceConverter.ConvertFrom

DetailsDetails Ein Fehler im Ausnahmebehandlungscode für ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) löste eine inkorrekte NullReferenceException anstelle der beabsichtigten Ausnahme (z.B. DirectoryNotFoundException oder FileNotFoundException) aus.An error in the exception handling code for ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) caused an incorrect NullReferenceException to be thrown instead of the intended exception (e.g. DirectoryNotFoundException, FileNotFoundException). Diese Änderung korrigiert diesen Fehler, damit die Methode nun die richtige Ausnahme auslöst.This change corrects that error so that the method now throws the right exception.

In der Standardeinstellung lösen Anwendungen mit dem Ziel .NET Framework 4.6.2 und früher der Kompatibilität wegen weiterhin NullReferenceException aus.By default all applications targeting .NET Framework 4.6.2 and earlier continue to throw NullReferenceException for compatibility. Entwickler, die .NET Framework 4.7 und höher anzielen, sollten die richtigen Ausnahmen angezeigt bekommen.Developers targeting .NET Framework 4.7 and above should see the right exceptions.

VorschlagSuggestion Entwickler, die wieder NullReferenceException erhalten möchten, wenn Sie .NET Framework 4.7 als Zielplattform verwenden, können der Datei „app.config“ ihrer Anwendung Folgendes hinzufügen oder die entsprechenden Angaben zusammenführen:Developers who wish to revert to getting NullReferenceException when targeting .NET Framework 4.7 can add/merge the following to their application's App.config file:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Media.ImageSourceConverter.OverrideExceptionWithNullReferenceException=true"/>
</runtime>
</configuration>
BereichScope Microsoft EdgeEdge
VersionVersion 4.74.7
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Platzvergabe im Raster für *-SpaltenWPF Grid allocation of space to star-columns

DetailsDetails Ab .NET Framework 4.7 ersetzt WPF den Algorithmus, den Grid verwendet, um Platz für *-Spalten zuzuweisen.Starting with the .NET Framework 4.7, WPF replaces the algorithm that Grid uses to allocate space to *-columns. Dadurch wird die den *-Spalten zugewiesene tatsächliche Breite unter den folgenden Umständen geändert:This will change the actual width assigned to *-columns in a number of cases:
  • Wenn eine oder mehrere *-Spalten außerdem eine Minimal- oder Maximalbreite aufweisen, die die proportionale Zuweisung für die betreffende Spalte außer Kraft setzt.When one or more *-columns also have a minimum or maximum width that overrides the proportional allocation for that column. (Die Minimalbreite kann aus einer expliziten MinWidth-Deklaration oder aus einem impliziten Minimalwert abgeleitet werden, der sich aus dem Spalteninhalt ergibt.(The minimum width can derive from an explicit MinWidth declaration, or from an implicit minimum obtained from the column's content. Die maximale Breite kann nur explizit aus einer MaxWidth-Deklaration definiert werden.)The maximum width can only be defined explicitly, from a MaxWidth declaration.)
  • Wenn eine oder mehrere *-Spalten eine extrem große *-Gewichtung deklarieren, größer als 10^298.When one or more *-columns declare an extremely large *-weight, greater than 10^298.
  • Wenn die *-Gewichtungen ausreichend verschieden sind, um zu Gleitkommainstabilität zu führen (Überlauf, Unterlauf, Genauigkeitsverlust).When the *-weights are sufficiently different to encounter floating-point instability (overflow, underflow, loss of precision).
  • Wenn Layoutglättung aktiviert ist und der effektive DPI-Wert der Anzeige ausreichend hoch ist.When layout rounding is enabled, and the effective display DPI is sufficiently high.
In den beiden ersten Fällen können sich die vom neuen Algorithmus erzeugten Breiten erheblich von den durch den alten Algorithmus erzeugten unterscheiden; im letzten Fall beträgt der Unterschied höchstens ein oder zwei Pixel.In the first two cases, the widths produced by the new algorithm can be significantly different from those produced by the old algorithm; in the last case, the difference will be at most one or two pixels.

Der neue Algorithmus behebt mehrere Probleme, die beim alten Algorithmus auftreten:The new algorithm fixes several bugs present in the old algorithm:

  1. Die Gesamtzuweisung an Spalten kann die Breite des Rasters überschreiten.Total allocation to columns can exceed the Grid's width. Dies kann beim Zuweisen von Platz an eine Spalte geschehen, deren proportionaler Anteil geringer als ihre Mindestgröße ist.This can occur when allocating space to a column whose proportional share is less than its minimum size. Der Algorithmus weist die Mindestgröße zu, wodurch der für andere Spalten verfügbare Platz verringert wird.The algorithm allocates the minimum size, which decreases the space available to other columns. Wenn keine zuzuweisenden *-Spalten mehr vorhanden sind, ist die Gesamtzuweisung zu groß.If there are no *-columns left to allocate, the total allocation will be too large.
  2. Die Gesamtzuweisung kann die Breite des Rasters unterschreiten.Total allocation can fall short of the Grid's width. Dies ist das umgekehrte Problem zu Nr. 1, das beim Zuweisen zu einer Spalte auftritt, deren proportionaler Anteil größer als ihre Maximalgröße ist, wenn keine *-Spalten zum Ausgleich des Über- oder Untermaßes vorhanden sind.This is the dual problem to #1, arising when allocating to a column whose proportional share is greater than its maximum size, with no *-columns left to take up the slack.
  3. Zwei *-Spalten können Zuweisungen erhalten, die nicht proportional zu ihren *-Gewichtungen sind.Two *-columns can receive allocations not proportional to their *-weights. Dies ist eine mildere Version von Nr. 1/Nr. 2, die beim Zuweisen zu den *-Spalten A, B und C (in dieser Reihenfolge) auftritt, wobei der proportionale Anteil von B gegen deren Min- oder Max-Bedingung verstößt.This is a milder version of #1/#2, arising when allocating to *-columns A, B, and C (in that order), where B's proportional share violates its min (or max) constraint. Wie oben ändert sich dadurch der für Spalte C zur Verfügung stehende Platz, die proportional eine kleinere (oder größeren) Zuweisung als A erhält.As above, this changes the space available to column C, who gets less (or more) proportional allocation than A did,
  4. Spalten mit extrem hohen Gewichtungen (> 10^298) werden alle behandelt, als würden sie die Gewichtung 10^298 aufweisen.Columns with extremely large weights (> 10^298) are all treated as if they had weight 10^298. Proportionale Unterschiede zwischen ihnen (und zwischen Spalten mit erheblich kleineren Gewichtungen) werden nicht berücksichtigt.Proportional differences between them (and between columns with slightly smaller weights) are not honored.
  5. Spalten mit der Gewichtung unendlich werden nicht ordnungsgemäß behandelt.Columns with infinite weights are not handled correctly. [Tatsächlich lässt sich die Gewichtung nicht auf unendlich festlegen, aber das ist eine künstliche Einschränkung.[Actually you can't set a weight to Infinity, but this is an artificial restriction. Der Zuweisungscode hat versucht, das Problem zu behandeln, dabei aber versagt.]The allocation code was trying to handle it, but doing a bad job.]
  6. Mehrere kleinere Probleme beim Vermeiden von Überlauf, Unterlauf, Genauigkeitsverlust und ähnlichen Gleitkommaproblemen.Several minor problems while avoiding overflow, underflow, loss of precision and similar floating-point issues.
  7. Anpassungen für Layoutglättung sind bei ausreichend hohem DPI fehlerhaft.Adjustments for layout rounding are incorrect at sufficiently high DPI.
Der neue Algorithmus erzeugt Ergebnisse, die den folgenden Kriterien genügen:The new algorithm produces results that meet the following criteria:

A.A. Die einer *-Spalte zugewiesene Breite ist niemals kleiner als ihre Mindestbreite oder größer als ihre Maximalbreite.The actual width assigned to a *-column is never less than its minimum width nor greater than its maximum width.
B.B. Jede -Spalte, der nicht ihre Mindest- oder Maximalbreite zugewiesen wird, wird eine Breite zugewiesen, die proportional zu ihrer -Gewichtung ist. Genauer gesagt, wenn zwei Spalten die Breite x bzw. y zugewiesen werden und keine der beiden Spalten ihre Minimal- oder Maximalbreite erhält, stehen die den Spalten zugewiesenen tatsächlichen Breiten v und w im gleichen Verhältnis: v / w == x / y.Each -column that is not assigned its minimum or maximum width is assigned a width proportional to its -weight. To be precise, if two columns are declared with width x and y respectively, and if neither column receives its minimum or maximum width, the actual widths v and w assigned to the columns are in the same proportion: v / w == x / y.
C.C. Die Gesamtbreite, die den "proportionalen" *-Spalten zugewiesen wird, entspricht dem verfügbaren Platz nach der Zuweisung an die Spalten, die Bedingungen unterliegen (feste Spalten, Spalten mit automatischer Breite und *-Spalten, denen die Minimal- oder Maximalbreite zugewiesen wird).The total width allocated to "proportional" *-columns is equal to the space available after allocating to the constrained columns (fixed, auto, and *-columns that are allocated their min or max width). Diese kann Null sein, beispielsweise, wenn die Summe der Mindestbreiten die zur Verfügung stehende Breite des Rasters überschreitet.This might be zero, for instance if the sum of the minimum widths exceeds the Grid's available width.
D.D. Alle diese Anweisungen müssen im Hinblick auf das "ideale" Layout interpretiert werden.All these statements are to be interpreted with respect to the "ideal" layout. Wenn Layoutglättung aktiviert ist, können die tatsächlichen Breiten um bis zu ein Pixel von den idealen Breiten abweichen.When layout rounding is in effect, the actual widths can differ from the ideal widths by as much as one pixel.
Der alte Algorithmus berücksichtigte in den oben dargestellten Fällen (A), nicht jedoch die anderen Kriterien.The old algorithm honored (A) but failed to honor the other criteria in the cases outlined above.

Alle Aussagen über Spalten und Breiten in diesem Artikel gelten ebenso für Zeilen und Höhen.Everything said about columns and widths in this article applies as well to rows and heights.

VorschlagSuggestion Standardmäßig verwenden Apps mit einer .NET Framework-Zielplattform ab .NET Framework 4.7 den neuen Algorithmus, während Apps mit der Zielplattform .NET Framework 4.6.2 oder früher den alten Algorithmus verwenden.By default, apps that target versions of the .NET Framework starting with the .NET Framework 4.7 will see the new algorithm, while apps that target the .NET Framework 4.6.2 or earlier versions will see the old algorithm.

Um die Standardeinstellung außer Kraft zu setzen, verwenden Sie die folgenden Konfigurationseinstellung:To override the default, use the following configuration setting:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>
Der Wert true legt den alten Algorithmus fest, false den neuen.The value true selects the old algorithm, false selects the new algorithm.
BereichScope GeringMinor
VersionVersion 4.74.7
TypType NeuzuweisungRetargeting

Die WPF-Layoutglättung von Rändern wurde geändertWPF layout rounding of margins has changed

DetailsDetails Die Art und Weise, wie Ränder und die Grenzen und der Hintergrund darin geglättet werden, hat sich geändert.The way in which margins are rounded and borders and the background inside of them has changed. Auswirkungen durch diese Änderung:As a result of this change:
  • Die Breite oder Höhe der Elemente vergrößert oder verkleinert sich allenfalls um einen Pixel.The width or height of elements may grow or shrink by at most one pixel.
  • Die Platzierung eines Objekts kann sich allenfalls um einen Pixel verschieben.The placement of an object can move by at most one pixel.
  • Zentrierte Elemente können sich vertikal oder horizontal um allenfalls ein Pixel von der Mitte verschieben.Centered elements can be vertically or horizontally off center by at most one pixel.
Standardmäßig wird dieses neue Layout nur für Apps aktiviert, die auf .NET Framework 4.6 abzielen.By default, this new layout is enabled only for apps that target the .NET Framework 4.6.
VorschlagSuggestion 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:Since this modification tends to eliminate clipping of the right or bottom of WPF controls at high DPIs, apps that target earlier versions of the .NET Framework but are running on the .NET Framework 4.6 can opt into this new behavior by adding the following line to the <runtime> section of the app.config file:
<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:Apps that target the .NET Framework 4.6 but want WPF controls to render using the previous layout algorithm can do so by adding the following line to the <runtime> section of the app.config file:
<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />'.
BereichScope GeringMinor
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting

Zeigerbasierte Touch-Stapel in WPFWPF Pointer-Based Touch Stack

DetailsDetails Diese Änderung ermöglicht das Aktivieren eines optionalen WM_POINTER-basierten WPF-Touch-/Stift-Stapels.This change adds the ability to enable an optional WM_POINTER based WPF touch/stylus stack. Entwickler, die diesen Stapel nicht explizit aktivieren, sollten keine Änderung im WPF-Touch/Stift-Verhalten feststellen. Folgende Probleme sind mit dem optionalen WM_POINTER-basierten Touch-/Stift-Stapel bekannt:Developers that do not explicitly enable this should see no change in WPF touch/stylus behavior.Current Known Issues With optional WM_POINTER based touch/stylus stack:
  • Keine Unterstützung für Freihand in Echtzeit.No support for real-time inking.
  • Zwar funktionieren Freihand- und Stift-Plug-Ins nach wie vor, jedoch werden sie im Benutzeroberflächenthread verarbeitet, was zu schlechter Leistung führen kann.While inking and StylusPlugins will still work, they will be processed on the UI Thread which can lead to poor performance.
  • Verhaltensänderungen aufgrund der Verlagerung von Touch/Stift-Ereignissen zu Mausereignissen.Behavioral changes due to changes in promotion from touch/stylus events to mouse events
  • Die Bearbeitung verhält sich möglicherweise anders.Manipulation may behave differently
  • Drag/Drop zeigt keine angemessene Rückmeldung bei Toucheingaben.Drag/Drop will not show appropriate feedback for touch input
  • Dies betrifft keine Stifteingaben.This does not affect stylus input
  • Drag/Drop kann für Touch/Stift-Ereignisse nicht mehr ausgelöst werden.Drag/Drop can no longer be initiated on touch/stylus events
  • Dadurch kann es vorkommen, dass die Anwendung nicht mehr reagiert, bis die Mauseingabe erkannt wird.This can potentially cause the application to stop responding until mouse input is detected.
  • Stattdessen sollten Entwickler Drag & Drop über Mausereignisse einleiten.Instead, developers should initiate drag and drop from mouse events.
VorschlagSuggestion Entwickler, die diesen Stapel aktivieren möchten, können der Datei „app.config“ ihrer Anwendung Folgendes hinzufügen:Developers who wish to enable this stack can add/merge the following to their application's App.config file:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Input.Stylus.EnablePointerSupport=true"/>
</runtime>
</configuration>
Entfernen oder Festlegen des Werts auf FALSE deaktiviert diesen optionalen Stapel. Beachten Sie, dass dieser Stapel nur unter Windows 10 Creators Update und höher verfügbar ist.Removing this or setting the value to false will turn this optional stack off.Note that this stack is available only on Windows 10 Creators Update and above.
BereichScope Microsoft EdgeEdge
VersionVersion 4.74.7
TypType NeuzuweisungRetargeting

Windows Workflow Foundation (WF)Windows Workflow Foundation (WF)

Änderung der Workflowprüfsummen von MD5 in SHA1Workflow checksums changed from MD5 to SHA1

DetailsDetails Die Workflowlaufzeit generiert unter Verwendung eines Hashalgorithmus zur Unterstützung des Debuggens mit Visual Studio eine Prüfsumme für eine Workflowinstanz.To support debugging with Visual Studio, the Workflow runtime generates a checksum for a workflow instance using a hashing algorithm. In .NET Framework 4.6.2 und früheren Versionen wird beim Hashing der Workflowprüfsumme der MD5-Algorithmus verwendet, der auf Systemen, auf den FIPS aktiviert ist, Probleme verursacht hat.In the .NET Framework 4.6.2 and earlier versions, workflow checksum hashing used the MD5 algorithm, which caused issues on FIPS-enabled systems. Ab .NET Framework 4.7 wird der SHA1-Algorithmus verwendet.Starting with the .NET Framework 4.7, the algorithm is SHA1. Wenn Ihr Code diese Prüfsummen dauerhaft gespeichert hat, sind diese nicht kompatibel.If your code has persisted these checksums, they will be incompatible.
VorschlagSuggestion Wenn Ihr Code aufgrund eines Prüfsummenfehlers keine Workflowinstanzen laden kann, sollten Sie versuchen, den AppContext-Schalter "Switch.System.Activities.UseMD5ForWFDebugger" auf TRUE festzulegen. Dies können Sie in Form von Code tun:If your code is unable to load workflow instances due to a checksum failure, try setting the AppContext switch "Switch.System.Activities.UseMD5ForWFDebugger" to true.In code:
System.AppContext.SetSwitch("Switch.System.Activities.UseMD5ForWFDebugger", true);
Stattdessen können Sie dies auch im Rahmen der Konfiguration vornehmen:Or in configuration:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Activities.UseMD5ForWFDebugger=true" />
</runtime>
</configuration>
BereichScope GeringMinor
VersionVersion 4.74.7
TypType NeuzuweisungRetargeting

WorkflowDesigner.Load entfernt die Symbol-Eigenschaft nichtWorkflowDesigner.Load doesn't remove symbol property

DetailsDetails Wenn für den Workflow-Designer .NET Framework 4.5 als Zielplattform verwendet und ein neu gehosteter Workflow der Version 3.5 mit der Methode Load() geladen wird, wird beim Speichern des Workflows eine XamlDuplicateMemberException ausgelöst.When targeting the .NET Framework 4.5 in the workflow designer, and loading a re-hosted 3.5 workflow with the Load() method, a XamlDuplicateMemberException is thrown while saving the workflow.
VorschlagSuggestion Dieser Fehler tritt nur auf, wenn der Workflow-Designer auf .NET Framework 4.5 ausgerichtet ist. Daher kann das Problem umgangen werden, indem WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName auf .NET Framework 4.0 festgelegt wird. Alternativ kann der Fehler umgangen werden, indem anstelle von Load() die Methode Load(String) zum Laden des Workflows verwendet wird.This bug only manifests when targeting .NET Framework 4.5 in the workflow designer, so it can be worked around by setting the WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName to the 4.0 .NET Framework.Alternatively, the issue may be avoided by using the Load(String) method to load the workflow, instead of Load().
BereichScope HauptversionMajor
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

XML, XSLTXML, XSLT

XmlWriter löst bei ungültigen Ersatzzeichenpaaren Ausnahmen ausXmlWriter throws on invalid surrogate pairs

DetailsDetails 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.For apps that target the .NET Framework 4.5.2 or previous versions, writing an invalid surrogate pair using exception fallback handling does not always throw an exception. Bei Apps mit der Zielplattform .NET Framework 4.6 löst der Versuch, ein ungültiges Ersatzzeichenpaar zu schreiben, eine ArgumentException aus.For apps that target the .NET Framework 4.6, attempting to write an invalid surrogate pair throws an ArgumentException.
VorschlagSuggestion Falls erforderlich, kann dieser Fehler umgangen werden, indem als Zielplattform.NET Framework 4.5.2 oder eine ältere Version verwendet wird.If necessary, this break can be avoided by targeting the .NET Framework 4.5.2 or earlier. Alternativ können ungültige Ersatzzeichenpaare vor dem Schreiben auch zuerst in gültigen XML-Code umgewandelt werden.Alternatively, invalid surrogate pairs can be pre-processed into valid xml prior to writing them.
BereichScope Microsoft EdgeEdge
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting
Betroffene APIsAffected 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 istXSD Schema validation now correctly detects violations of unique constraints if compound keys are used and one key is empty

DetailsDetails 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.Versions of the .NET Framework prior to 4.6 had a bug that caused XSD validation to not detect unique constraints on compound keys if one of the keys was empty. Dieses Problem wurde in .NET Framework 4.6 behoben.In the .NET Framework 4.6, this issue is corrected. Dies führt zu einwandfreieren Validierung, aber möglicherweise auch dazu, dass einige XML-Daten nicht überprüft werden, die zuvor überprüft wurden.This will result in more correct validation, but it may also result in some XML not validating which previously would have.
VorschlagSuggestion 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.If looser .NET Framework 4.0 validation is needed, the validating application can target version 4.5 (or earlier) of the .NET Framework. 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.When retargeting to .NET Framework 4.6, however, code review should be done to be sure that duplicate compound keys (as described in this issue's description) are not expected to validate.
BereichScope Microsoft EdgeEdge
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting