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

Introduction

Retargeting changes affect apps that are recompiled to target a different .NET Framework. They include:

  • Changes in the design-time environment. For example, build tools may emit warnings when previously they did not.

  • Changes in the runtime environment. These affect only apps that specifically target the retargeted .NET Framework. Apps that target previous versions of the .NET Framework behave as they did when running under those versions.

In the topics that describe retargeting changes, we have classified individual items by their expected impact, as follows:

Major This is a significant change that affects a large number of apps or that requires substantial modification of code.

Minor This is a change that affects a small number of apps or that requires minor modification of code.

Edge case This is a change that affects apps under very specific scenarios that are not common.

Transparent This is a change that has no noticeable effect on the app's developer or user. The app should not require modification because of this change.

Wenn Sie von .NET Framework 4.0 zu 4.6 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.0 to 4.6, review the following topics for application compatibility issues that may affect your app:

ADO.NETADO.NET

DbParameter.Precision und DbParameter.Scale sind jetzt öffentliche virtuelle MemberDbParameter.Precision and DbParameter.Scale are now public virtual members

DetailsDetails Precision und Scale werden als öffentliche virtuelle Eigenschaften implementiert.and Scale are implemented as public virtual properties. Sie ersetzen die entsprechenden expliziten Schnittstellenimplementierungen IDbDataParameter.Precision und IDbDataParameter.Scale.They replace the corresponding explicit interface implementations, IDbDataParameter.Precision and IDbDataParameter.Scale.
VorschlagSuggestion Wenn Sie einen ADO.NET-Datenbankanbieter neu erstellen, erfordern diese Unterschiede die Anwendung des Schlüsselworts „override“ auf die Eigenschaften „Precision“ und „Scale“.When re-building an ADO.NET database provider, these differences will require the 'override' keyword to be applied to the Precision and Scale properties. Dies ist nur beim erneuten Erstellen von Komponenten erforderlich. Vorhandene Binärdateien funktionieren weiterhin.This is only needed when re-building the components; existing binaries will continue to work.
BereichScope GeringMinor
VersionVersion 4.5.14.5.1
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

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

Die Methoden MachineKey.Encode und MachineKey.Decode sind jetzt veraltetMachineKey.Encode and MachineKey.Decode methods are now obsolete

DetailsDetails Diese Methoden sind jetzt veraltet.These methods are now obsolete. Die Kompilierung von Code, der diese Methoden aufruft, erzeugt eine Compilerwarnung.Compilation of code that calls these methods produces a compiler warning.
VorschlagSuggestion Die empfohlenen Alternativen sind Protect(Byte[], String[]) und Unprotect(Byte[], String[]).The recommended alternatives are Protect(Byte[], String[]) and Unprotect(Byte[], String[]). Alternativ können die Buildwarnungen unterdrückt oder durch die Verwendung eines älteren Compilers vermieden werden.Alternatively, the build warnings can be suppressed, or they can be avoided by using an older compiler. Die APIs werden weiterhin unterstützt.The APIs are still supported.
BereichScope GeringMinor
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Der Abstand für mehrzeilige ASP.NET-Textfelder (TextBox) wurde bei der Verwendung von AntiXSSEncoder geändertMulti-line ASP.Net TextBox spacing changed when using AntiXSSEncoder

DetailsDetails In .NET Framework 4.0 wurden zwischen Zeilen eines mehrzeiligen Textfelds beim Postback zusätzliche Zeilen eingefügt, wenn AntiXssEncoder verwendet wird.In .NET Framework 4.0, extra lines were inserted between lines of a multi-line text box on postback, if using the AntiXssEncoder. In .NET Framework 4.5 sind diese zusätzlichen Zeilenumbrüche nicht enthalten, wenn die Web-App auf .NET Framework 4.5 ausgelegt ist.In .NET Framework 4.5, those extra line breaks are not included, but only if the web app is targeting .NET Framework 4.5
VorschlagSuggestion Beachten Sie, dass bei Web-Apps der Version 4.0, die auf .NET Framework 4.5 neu ausgelegt wurden, mehrzeilige Textfelder möglicherweise verbessert wurden, damit diese keine zusätzlichen Zeilenumbrüche mehr einfügen.Be aware that 4.0 web apps retargeted to .NET Framework 4.5 may have multi-line text boxes improved to no longer insert extra line breaks. Wenn dies nicht erwünscht ist, kann die App das alte Verhalten verwenden, wenn sie unter .NET Framework 4.5 ausgeführt wird, indem sie auf .NET Framework 4.0 ausgerichtet wird.If this is not desirable, the app can have the old behavior when running on .NET Framework 4.5 by targeting the .NET Framework 4.0.
BereichScope GeringMinor
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting

WebUtility.HtmlEncode und WebUtility.HtmlDecode führen für die BMP eine ordnungsgemäße Roundtripkonvertierung durchWebUtility.HtmlEncode and WebUtility.HtmlDecode round-trip BMP correctly

DetailsDetails Bei Anwendungen mit der Zielplattform .NET Framework 4.5 wird für Zeichen, die sich außerhalb der Basic Multilingual Plane (BMP) befinden, eine erfolgreiche Roundtripkonvertierung durchgeführt, wenn sie an die HtmlDecode(String)-Methoden übergeben werden.For applications that target the .NET Framework 4.5, characters that are outside the Basic Multilingual Plane (BMP) round-trip correctly when they are passed to the HtmlDecode(String) methods.
VorschlagSuggestion Diese Änderung sollte keine Auswirkung auf aktuelle Anwendungen haben. Wenn Sie jedoch das ursprüngliche Verhalten wiederherstellen möchten, legen Sie das Attribut targetFramework des Elements <httpRuntime> auf eine andere Zeichenfolge als "4.5" fest.This change should have no effect on current applications, but to restore the original behavior, set the targetFramework attribute of the <httpRuntime> element to a string other than "4.5". Sie können die unicodeEncodingConformance- und unicodeDecodingConformance-Attribute des <webUtility>-Konfigurationselements auch festlegen, um dieses Verhalten unabhängig von der Zielversion von .NET Framework zu steuern.You can also set the unicodeEncodingConformance and unicodeDecodingConformance attributes of the <webUtility> configuration element to control this behavior independently of the targeted version of the .NET Framework.
BereichScope Microsoft EdgeEdge
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

ClickOnceClickOnce

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

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

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

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

DetailsDetails In .NET Framework 4.6 und 4.6.1 löst die Laufzeit ArgumentException aus, wenn zwei Ereignisnamen der Ereignisablaufverfolgung für Windows (ETW) sich lediglich durch das Suffix "Start" oder "Stop" unterscheiden (z.B. wenn ein Ereignis mit LogUser benannt ist und das andere mit LogUserStart).In the .NET Framework 4.6 and 4.6.1, the runtime throws an ArgumentException when two Event Tracing for Windows (ETW) event names differ only by a "Start" or "Stop" suffix (as when one event is named LogUser and another is named LogUserStart). In diesem Fall kann die Runtime die Ereignisquelle nicht erstellen, die dann keine Protokollierung durchführen kann.In this case, the runtime cannot construct the event source, which cannot emit any logging.
VorschlagSuggestion Stellen Sie sicher, dass zwei Ereignisnamen sich nicht nur durch das Suffix "Start" oder "Stop" unterscheiden, um die Ausnahme zu verhindern. Diese Anforderung wird mit .NET Framework 4.6.2 entfernt. Die Laufzeit kann Ereignisnamen unterscheiden, die sich nur durch das Suffix "Start" oder "Stop" unterscheiden.To prevent the exception, ensure that no two event names differ only by a "Start" or "Stop" suffix.This requirement is removed starting with the .NET Framework 4.6.2; the runtime can disambiguate event names that differ only by the "Start" and "Stop" suffix.
BereichScope Microsoft EdgeEdge
VersionVersion 4.64.6
TypType NeuzuweisungRetargeting

Der Gültigkeitsbereich der Foreach-Iteratorvariable ist jetzt auf die Iteration beschränkt, weswegen sich die Semantik für die Abschlusserfassung (in C# 5) unterscheidetForeach iterator variable is now scoped within the iteration, so closure capturing semantics are different (in C#5)

DetailsDetails Ab C# 5 (Visual Studio 2012) ist der Gültigkeitsbereich von foreach-Iteratorvariablen auf die Iteration beschränkt.Beginning with C# 5 (Visual Studio 2012), foreach iterator variables are scoped within the iteration. Dies kann zu Fehlern führen, wenn der Code zuvor davon abhängig war, dass die Variablen nicht in den foreach-Abschluss einbezogen wurden.This can cause breaks if code was previously depending on the variables to not be included in the foreach's closure. Diese Änderung führt dazu, dass eine an einen Delegaten übergebene Iteratorvariable als der Wert behandelt wird, den sie zum Zeitpunkt der Erstellung des Delegaten aufwies, anstatt sie als den Wert zu behandeln, den sie zum Zeitpunkt aufwies, als der Delegat aufgerufen wurde.The symptom of this change is that an iterator variable passed to a delegate is treated as the value it has at the time the delegate is created, rather than the value it has at the time the delegate is invoked.
VorschlagSuggestion Idealerweise sollte der Code aktualisiert werden, um das neue Compilerverhalten zu erwarten.Ideally, code should be updated to expect the new compiler behavior. Wenn die alte Semantik erforderlich ist, kann die Iteratorvariable durch eine separate Variable ersetzt werden, die explizit außerhalb des Gültigkeitsbereichs der Schleife platziert wird.If the old semantics are required, the iterator variable can be replaced with a separate variable which is explicitly placed outside of the loop's scope.
BereichScope HauptversionMajor
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting

Die IAsyncResult.CompletedSynchronously-Eigenschaft muss korrekt sein, damit die resultierende Aufgabe abgeschlossen wirdIAsyncResult.CompletedSynchronously property must be correct for the resulting task to complete

DetailsDetails Wenn Sie TaskFactory.FromAsync aufrufen, muss die Implementierung der CompletedSynchronously-Eigenschaft korrekt sein, damit die resultierende Aufgabe abgeschlossen wird.When calling TaskFactory.FromAsync, the implementation of the CompletedSynchronously property must be correct for the resulting task to complete. Das heißt, die Eigenschaft muss für den Fall, und ausschließlich für den Fall, dass die Implementierung synchron abgeschlossen wurde, „true“ zurückgeben.That is, the property must return true if, and only if, the implementation completed synchronously. Zuvor wurde die Eigenschaft nicht überprüft.Previously, the property was not checked.
VorschlagSuggestion Wenn IAsyncResult-Implementierungen nur dann ordnungsgemäß TRUE für die CompletedSynchronously-Eigenschaft zurückgeben, wenn eine Aufgabe synchron abgeschlossen wurde, tritt kein Fehler auf.If IAsyncResult implementations correctly return true for the CompletedSynchronously property only when a task completed synchronously, then no break will be observed. Benutzer sollten IAsyncResult-Implementierungen überprüfen, die sie ggf. besitzen, um sicherzustellen, dass ordnungsgemäß ausgewertet wird, ob eine Aufgabe synchron abgeschlossen wurde.Users should review IAsyncResult implementations they own (if any) to ensure that they correctly evaluate whether a task completed synchronously or not.
BereichScope Microsoft EdgeEdge
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

List<T>.ForEach kann beim Ändern eines Listenelements eine Ausnahme auslösenList<T>.ForEach can throw exception when modifying list item

DetailsDetails Ab .NET Framework 4.5 löst ein ForEach(Action<T>)-Enumerator eine InvalidOperationException-Ausnahme aus, wenn ein Element in der aufrufenden Sammlung geändert wird.Beginning in .NET Framework 4.5, a ForEach(Action<T>) enumerator will throw an InvalidOperationException exception if an element in the calling collection is modified. Zuvor hätte dies keine Ausnahme ausgelöst, aber zu Racebedingungen geführt.Previously, this would not throw an exception but could lead to race conditions.
VorschlagSuggestion Im Idealfall sollte der Code unveränderlich sein, damit Listen nicht geändert werden, während ihre Elemente aufgezählt werden, da dies nie ein sicherer Vorgang ist.Ideally, code should be fixed to not modify lists while enumerating their elements because that is never a safe operation. Eine App kann auf .NET Framework 4.0 ausgelegt werden, um zum vorherigen Verhalten zurückzukehren.To revert to the previous behavior, though, an app may target .NET Framework 4.0.
BereichScope Microsoft EdgeEdge
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

ObsoleteAttribute wird in WinMD-Szenarios sowohl als ObsoleteAttribute als auch als DeprecatedAttribute exportiertObsoleteAttribute exports as both ObsoleteAttribute and DeprecatedAttribute in WinMD scenarios

DetailsDetails Wenn Sie eine Windows-Metadatenbibliothek (WINMD-Datei) erstellen, wird das Attribut ObsoleteAttribute als ObsoleteAttribute und als Windows.Foundation.DeprecatedAttribute exportiert.When you create a Windows Metadata library (.winmd file), the ObsoleteAttribute attribute is exported as both ObsoleteAttribute and Windows.Foundation.DeprecatedAttribute.
VorschlagSuggestion Durch die Neukompilierung von vorhandenem Quellcode, in dem das Attribut ObsoleteAttribute verwendet wird, können Warnungen generiert werden, wenn dieser Code von C++/CX oder JavaScript verarbeitet wird. Es wird davon abgeraten, sowohl ObsoleteAttribute als auch Windows.Foundation.DeprecatedAttribute in Code in verwalteten Assemblys anzuwenden, da dies zu Buildwarnungen führen kann.Recompilation of existing source code that uses the ObsoleteAttribute attribute may generate warnings when consuming that code from C++/CX or JavaScript.We do not recommend applying both ObsoleteAttribute and Windows.Foundation.DeprecatedAttribute to code in managed assemblies; it may result in build warnings.
BereichScope Microsoft EdgeEdge
VersionVersion 4.5.14.5.1
TypType NeuzuweisungRetargeting

Die System.Uri-Analyse entspricht den Vorgaben in RFC 3987System.Uri parsing adheres to RFC 3987

DetailsDetails Die URI-Analyse hat sich seit .NET Framework 4.5 auf verschiedene Weisen geändert.URI parsing has changed in several ways in .NET Framework 4.5. Beachten Sie jedoch, dass sich diese Änderungen nur auf Code auswirken, der auf .NET Framework 4.5 ausgelegt ist.Note, however, that these changes only affect code targeting .NET Framework 4.5. Wenn eine Binärdatei auf .NET Framework 4.0 ausgelegt ist, wird das alte Verhalten beachtet.If a binary targets .NET Framework 4.0, the old behavior will be observed. Änderungen an der URI-Analyse in .NET Framework 4.5 umfassen Folgendes:Changes to URI parsing in .NET Framework 4.5 include:
  • Die URI-Analyse führt die Normalisierung und Zeichenüberprüfung gemäß den neuesten IRI-Regeln in RFC 3987 aus.URI parsing will perform normalization and character checking according to the latest IRI rules in RFC 3987.
  • Die Unicode-Normalisierungsform C wird nur für den Hostteil des URIs ausgeführt.Unicode normalization form C will only be performed on the host portion of the URI.
  • Ungültige Angabe für „Mailto“: URIs lösen nun eine Ausnahme aus.Invalid mailto: URIs will now cause an exception.
  • Nachgestellte Punkte am Ende eines Pfadsegments bleiben nun erhalten.Trailing dots at the end of a path segment are now preserved.
  • file:// -URIs versehen das ?-Zeichen nicht mit einem Escapezeichen.URIs do not escape the ? character.
  • Die Unicode-Steuerzeichen U+0080 bis U+009F werden nicht unterstützt.Unicode control characters U+0080 through U+009F are not supported.
  • Für die Kommazeichen , und %2c wird das Escapezeichen nicht automatisch entfernt.Comma characters , or %2c are not automatically unescaped.
VorschlagSuggestion Wenn die alte Semantik der .NET Framework 4.0-URI-Analyse erforderlich ist (was nicht häufig der Fall ist), kann sie durch Ausrichtung auf .NET Framework 4.0 verwendet werden.If the old .NET Framework 4.0 URI parsing semantics are necessary (they often aren't), they can be used by targeting .NET Framework 4.0. Dies kann mithilfe von TargetFrameworkAttribute für die Assembly oder auf der Seite „Projekteigenschaften“ über die Benutzeroberfläche des Projektsystems von Visual Studio erreicht werden.This can be accomplished by using a TargetFrameworkAttribute on the assembly, or through Visual Studio's project system UI in the 'project properties' page.
BereichScope HauptversionMajor
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Die Methode System.Uri.IsWellFormedUriString gibt für relative URIs mit einem Doppelpunktzeichen im ersten Segment FALSE zurückSystem.Uri.IsWellFormedUriString method returns false for relative URIs with a colon char in first segment

DetailsDetails Ab .NET Framework 4.5 zeigt IsWellFormedUriString(String, UriKind) für relative URIs mit einem : im ersten Segment an, dass es sich nicht um einen wohlgeformten relativen URI handelt.Beginning with the .NET Framework 4.5, IsWellFormedUriString(String, UriKind) will treat relative URIs with a : in their first segment as not well formed. Dies ist eine Änderung des IsWellFormedUriString(String, UriKind)-Verhaltens in .NET Framework 4.0, die vorgenommen wurde, um eine Übereinstimmung mit RFC3986 sicherzustellen.This is a change from IsWellFormedUriString(String, UriKind) behavior in the .NET Framework 4.0 that was made to conform to RFC3986.
VorschlagSuggestion Diese Änderung wirkt sich (wie viele andere URI-Änderungen auch) nur auf Anwendungen aus, die auf .NET Framework 4.5 (oder höher) ausgerichtet sind.This change (like many other URI changes) will only affect applications targeting the .NET Framework 4.5 (or later). Damit Sie weiterhin das alte Verhalten verwenden können, müssen Sie als Zielplattform für die App NET Framework 4.0 verwenden.To keep using the old behavior, target the app against the .NET Framework 4.0. Überprüfen Sie alternativ die URIs, bevor Sie IsWellFormedUriString(String, UriKind) aufrufen, und suchen Sie nach :-Zeichen, die Sie für die Überprüfung entfernen sollten, wenn das alte Verhalten bevorzugt wird.Alternatively, scan URI's prior to calling IsWellFormedUriString(String, UriKind) looking for : characters that you may want to remove for validation purposes, if the old behavior is desirable.
BereichScope GeringMinor
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Entity FrameworkEntity Framework

Die Version von Entity Framework muss mit der Version von .NET Framework übereinstimmenEntity Framework version must match the .NET Framework version

DetailsDetails Die Version von Entity Framework muss mit der Version von .NET Framework übereinstimmen.The entity framework version should be matched with the .NET framework version. Für .NET Framework 4.5 wird Entity Framework 5 empfohlen.Entity Framework 5 is recommended for .NET Framework 4.5. Bei EF 4.x in einem .NET Framework 4.5-Projekt sind im Zusammenhang mit System.ComponentModel.DataAnnotations mehrere Probleme bekannt.There are some known issues with EF 4.x in a .NET Framework 4.5 project around System.ComponentModel.DataAnnotations. In .NET 4.5 wurden diese in eine andere Assembly verschoben, daher gibt es Probleme mit der Bestimmung der zu verwendenden Anmerkungen.In .NET 4.5, these were moved to a different assembly, so there are issues determining which annotations to use.
VorschlagSuggestion Führen Sie bei Verwendung von .NET Framework 4.5 ein Upgrade auf Entity Framework 5 durch.Upgrade to Entity Framework 5 for .NET Framework 4.5
BereichScope HauptversionMajor
VersionVersion 4.54.5
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.This change does not affect the 32-bit JIT compiler. Die bekannten Unterschiede umfassen folgende Punkte: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

MSBuildMSBuild

Die ResolveAssemblyReference-Aufgabe warnt jetzt vor Abhängigkeiten von der falschen ArchitekturResolveAssemblyReference task now warns of dependencies with the wrong architecture

DetailsDetails Die Aufgabe gibt die Warnung MSB3270 aus, die angibt, dass ein Verweis oder eine seiner Abhängigkeiten nicht der Architektur der App entspricht.The task emits a warning, MSB3270, which indicates that a reference or any of its dependencies does not match the app's architecture. Dies erfolgt z. B., wenn eine App, die mit der AnyCPU-Option kompiliert wurde, einen x86-Verweis enthält.For example, this occurs if an app that was compiled with the AnyCPU option includes an x86 reference. Ein solches Szenario kann einen App-Fehler zur Laufzeit ergeben (in diesem Fall, wenn die App als x64-Prozess bereitgestellt wird).Such a scenario could result in an app failure at run time (in this case, if the app is deployed as an x64 process).
VorschlagSuggestion Es gibt zwei Bereiche mit Auswirkungen:There are two areas of impact:
  • Bei der Neukompilierung werden Warnungen generiert, die nicht angezeigt wurden, als die App mit einer früheren Version von MSBuild kompiliert wurde.Recompilation generates warnings that did not appear when the app was compiled under a previous version of MSBuild. Da die Warnung eine potenzielle Quelle des Laufzeitfehlers angibt, sollte sie untersucht werden.However, because the warning identifies a possible source of runtime failure, it should be investigated and addressed.
  • Wenn Warnungen wie Fehler behandelt werden, kann die Anwendung nicht kompiliert werden.If warnings are treated as errors, the app will fail to compile.
BereichScope GeringMinor
VersionVersion 4.5.14.5.1
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

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 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:
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
BereichScope GeringMinor
VersionVersion 4.64.6
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 bewirkt, dass SCHANNEL die zu verschlüsselnden Daten auf zwei Datensätze aufteilt, wobei der erste aus einem Einzelbyte und der zweite aus n – 1 Bytes besteht. In seltenen Fällen unterbricht dies die Kommunikation zwischen Clients und vorhandenen Servern, die von der Annahme ausgehen, dass die Daten in einem einzelnen Datensatz gespeichert sind.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 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 Flags SCH_SEND_AUX_RECORD deaktivieren und das vorherige Verhalten wiederherstellen, mit dem Daten nicht in separate Datensätze aufgeteilt werden, indem Sie dem Element < den folgenden Parameter im Abschnitt < Ihrer Anwendungskonfigurationsdatei 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 < element in the < 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

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

Windows FormsWindows Forms

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

EncoderParameter ctor ist veraltetEncoderParameter ctor is obsolete

DetailsDetails Der EncoderParameter(Encoder, Int32, Int32, Int32, Int32)-Konstruktor ist jetzt veraltet und gibt Buildwarnungen aus, wenn er verwendet wird.The EncoderParameter(Encoder, Int32, Int32, Int32, Int32) constructor is obsolete now and will introduce build warnings if used.
VorschlagSuggestion Obwohl der EncoderParameter(Encoder, Int32, Int32, Int32, Int32)-Konstruktor weiterhin funktioniert, sollte stattdessen der folgende Konstruktor verwendet werden, um die veraltete Buildwarnung zu vermeiden, wenn Code mit .NET Framework 4.5-Tools erneut kompiliert wird: EncoderParameter(Encoder, Int32, EncoderParameterValueType, IntPtr).Although the EncoderParameter(Encoder, Int32, Int32, Int32, Int32)constructor will continue to work, the following constructor should be used instead to avoid the obsolete build warning when re-compiling code with .NET Framework 4.5 tools: EncoderParameter(Encoder, Int32, EncoderParameterValueType, IntPtr).
BereichScope GeringMinor
VersionVersion 4.54.5
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

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

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

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

Die bidirektionale Datenbindung an eine Eigenschaft mit einem nicht öffentlichen Setter wird nicht unterstütztTwo-way data-binding to a property with a non-public setter is not supported

DetailsDetails Der Versuch, Daten ohne einen öffentlichen Setter an eine Eigenschaft zu binden, wurde nie unterstützt.Attempting to data bind to a property without a public setter has never been a supported scenario. Ab .NET Framework 4.5.1 löst dieses Szenario InvalidOperationException aus.Beginning in the .NET Framework 4.5.1, this scenario will throw an InvalidOperationException. Beachten Sie, dass diese neue Ausnahme nur für Apps ausgelöst wird, die speziell auf .NET Framework 4.5.1 abzielen.Note that this new exception will only be thrown for apps that specifically target the .NET Framework 4.5.1. Wenn eine App auf .NET Framework 4.5 ausgerichtet ist, wird der Aufruf zugelassen.If an app targets the .NET Framework 4.5, the call will be allowed. Wenn die App nicht auf eine bestimmte Version von .NET Framework ausgerichtet ist, wird die Bindung als unidirektionale Bindung behandelt.If the app does not target a particular .NET Framework version, the binding will be treated as one-way.
VorschlagSuggestion Die App sollte aktualisiert werden, um entweder die unidirektionale Bindung zu verwenden oder den Setter der Eigenschaft öffentlich zur Verfügung zu stellen.The app should be updated to either use one-way binding, or expose the property's setter publicly. Alternativ können Sie die App auf .NET Framework 4.5 ausrichten, um das alte Verhalten zu erreichen.Alternatively, targeting the .NET Framework 4.5 will cause the app to exhibit the old behavior.
BereichScope GeringMinor
VersionVersion 4.5.14.5.1
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

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

WPF-TextBox.Text wird möglicherweise nicht mehr mit der Datenbindung synchronisiertWPF TextBox.Text can be out-of-sync with databinding

DetailsDetails In einigen Fällen stellt die Text-Eigenschaft einen früheren Wert des datengebundenen Eigenschaftswerts dar, wenn die Eigenschaft während eines Datenbindungsschreibvorgangs geändert wird.In some cases, the Text property reflects a previous value of the databound property value if the property is modified during a databinding write operation.
VorschlagSuggestion Dies sollte keine negativen Auswirkungen haben.This should have no negative impact. Sie können jedoch das vorherige Verhalten wiederherstellen, indem Sie die KeepTextBoxDisplaySynchronizedWithTextProperty-Eigenschaft auf false festlegen.However, you can restore the previous behavior by setting the KeepTextBoxDisplaySynchronizedWithTextProperty property to false.
BereichScope Microsoft EdgeEdge
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

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

Neue (mehrdeutige) Dispatcher.Invoke-Überladungen können zu unterschiedlichem Verhalten führenNew (ambiguous) Dispatcher.Invoke overloads could result in different behavior

DetailsDetails .NET Framework 4.5 wurde um neue Überladungen für Dispatcher.Invoke ergänzt, die einen Parameter vom Typ Action enthalten.The .NET Framework 4.5 adds new overloads to Dispatcher.Invoke that include a parameter of type Action. Wenn vorhandener Code erneut kompiliert wird, lösen die Compiler möglicherweise Aufrufe der Dispatcher.Invoke-Methoden, die einen Delegate-Parameter aufweisen, als Aufrufe von Dispatcher.Invoke-Methoden mit einem Action-Parameter auf.When existing code is recompiled, compilers may resolve calls to Dispatcher.Invoke methods that have a Delegate parameter as calls to Dispatcher.Invoke methods with an Action parameter. Wird ein Aufruf an eine Dispatcher.Invoke-Überladung mit einem Delegate-Parameter als Aufruf an eine Dispatcher.Invoke-Überladung mit einem Action-Parameter aufgelöst, kann es zu folgenden unterschiedlichen Verhalten kommen:If a call to a Dispatcher.Invoke overload with a Delegate parameter is resolved as a call to a Dispatcher.Invoke overload with an Action parameter, the following differences in behavior may occur:
VorschlagSuggestion Um Unklarheiten zu vermeiden (und mögliche Abweichungen bei der Ausnahmebehandlung oder bei blockierendem Verhalten), kann Code, der „Dispatcher.Invoke“ aufruft, ein leeres Objekt [] als zweiten Parameter an den Invoke-Aufruf übergeben, um sicherzustellen, dass nach der .NET Framework 4.0-Methodenüberladung aufgelöst wird.To avoid ambiguity (and potential differences in exception handling or blocking behaviors), code calling Dispatcher.Invoke can pass an empty object[] as a second parameter to the Invoke call to be sure of resolving to the .NET Framework 4.0 method overload.
BereichScope GeringMinor
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

Einige Drag & Drop-APIs für WorkFlow sind veraltet.Some WorkFlow drag-and-drop APIs are obsolete

DetailsDetails Diese Drag & Drop-API für WorkFlow ist veraltet und löst Compilerwarnungen aus, wenn die App mit Version 4.5 neu erstellt wird.This WorkFlow drag-and-drop API is obsolete and will cause compiler warnings if the app is rebuilt against 4.5.
VorschlagSuggestion Stattdessen sollten neue DragDropHelper-APIs verwendet werden, die Vorgänge mit mehreren Objekten unterstützen.New DragDropHelper APIs that support operations with multiple objects should be used instead. Alternativ können die Buildwarnungen unterdrückt oder durch die Verwendung eines älteren Compilers vermieden werden.Alternatively, the build warnings can be suppressed or they can be avoided by using an older compiler. Die APIs werden weiterhin unterstützt.The APIs are still supported.
BereichScope GeringMinor
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting
Betroffene APIsAffected APIs

WorkFlow 3.0-Typen sind veraltetWorkFlow 3.0 types are obsolete

DetailsDetails WWF 3.0-APIs (Windows Workflow Foundation ) (aus dem System.Workflow-Namespace) sind jetzt veraltet.Windows Workflow Foundation (WWF) 3.0 APIs (those from the System.Workflow namespace) are now obsolete.
VorschlagSuggestion Stattdessen sollten die neuen WWF 4.0-APIs (in System.Activities) verwendet werden.New WWF 4.0 APIs (in System.Activities) should be used instead. Ein Beispiel zur Verwendung der neuen APIs finden Sie hier und weitere Anleitungen sind hier verfügbar.An example of using the new APIs can be found here and further guidance is available here. Da die WWF-3.0-APIs weiterhin unterstützt werden, können sie verwendet und die Warnung zur Buildzeit vermieden werden, indem sie entweder unterdrückt oder ein älterer Compiler verwendet wird.Alternatively, since the WWF 3.0 APIs are still supported, they may be used and the build-time warning avoided either by suppressing it or by using an older compiler.
BereichScope HauptversionMajor
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting

XML, XSLTXML, XSLT

Die XML-Schemaüberprüfung ist genauerXML schema validation is stricter

DetailsDetails In .NET Framework 4.5 ist die XML-Schemaüberprüfung genauer.In the .NET Framework 4.5, XML schema validation is more strict. Wenn Sie xsd:anyURI verwenden, um einen URI wie ein mailto-Protokoll zu überprüfen, tritt bei der Validierung ein Fehler auf, wenn der URI Leerzeichen enthält.If you use xsd:anyURI to validate a URI such as a mailto protocol, validation fails if there are spaces in the URI. In früheren Versionen von .NET Framework war die Validierung erfolgreich.In previous versions of the .NET Framework, validation succeeded. Die Änderung betrifft nur Anwendungen, die auf .NET Framework 4.5 ausgerichtet sind.The change affects only applications that target the .NET Framework 4.5.
VorschlagSuggestion Wenn eine weniger genaue Überprüfung für .NET Framework 4.0 erforderlich ist, kann die überprüfende Anwendung auf Version 4.0 von .NET Framework ausgerichtet werden.If looser .NET Framework 4.0 validation is needed, the validating application can target version 4.0 of the .NET Framework. Bei einer Neuausrichtung auf .NET Framework 4.5 sollte jedoch ein Code Review erfolgen, um sicherzustellen, dass ungültige URIs (mit Leerzeichen) nicht als Attributwerte mit dem Datentyp „anyURI“ erwartet werden.When retargeting to .NET Framework 4.5, however, code review should be done to be sure that invalid URIs (with spaces) are not expected as attribute values with the anyURI data type.
BereichScope GeringMinor
VersionVersion 4.54.5
TypType NeuzuweisungRetargeting

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