Runtimeänderungen für die Migration zu .NET Framework 4.5.x

In diesem Artikel werden App-Kompatibilitätsprobleme aufgeführt, die in .NET Framework 4.5, 4.5.1 und 4.5.2 auftreten.

.NET Framework 4.5

ASP.NET

GridView-Steuerelemente, bei denen „AllowCustomPaging“ auf TRUE festgelegt ist, kann das Ereignis „PageIndexChanging“ ausgelöst werden, wenn die letzte Seite der Ansicht verlassen wird

Details

Ein Fehler in .NET Framework 4.5 führt dazu, dass System.Web.UI.WebControls.GridView.PageIndexChanging für System.Web.UI.WebControls.GridView-Steuerelemente, bei denen System.Web.UI.WebControls.GridView.AllowCustomPaging nicht aktiviert ist, manchmal nicht ausgelöst wird.

Vorschlag

Dieses Problem wurde in .NET Framework 4.6 behoben und kann durch ein Upgrade auf diese Version von .NET Framework vermieden werden. Das Problem kann umgangen werden, indem die App eine explizite BindGrid-Bindung an eine beliebige Page_Load-Methode durchführt, die diese Bedingungen erfüllt (System.Web.UI.WebControls.GridView befindet sich auf der letzten Seite und LastSystem.Web.UI.WebControls.GridView.PageSize unterscheidet sich von System.Web.UI.WebControls.GridView.PageSize). Alternativ kann die App geändert werden, um Paging (statt benutzerdefiniertem Paging) zuzulassen, da das Problem in diesem Szenario nicht auftritt.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• GridView.AllowCustomPaging

HttpRequest.ContentEncoding-Eigenschaft verhindert UTF7

Details

Ab .NET Framework 4.5 ist die UTF-7-Codierung in System.Web.HttpRequest-Texten nicht zulässig. Teilweise treten bei Daten für Anwendungen, die von eingehenden UTF-7-Daten abhängen, Decodierungsprobleme auf.

Vorschlag

Im Idealfall sollten Anwendungen aktualisiert verwenden, damit sie die UTF-7-Codierung in System.Web.HttpRequest nicht verwenden. Alternativ kann das Legacyverhalten mithilfe des aspnet:AllowUtf7RequestContentEncoding-Attributs des appSettings-Elements wiederhergestellt werden.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• HttpRequest.ContentEncoding

HttpUtility.JavaScriptStringEncode versieht kaufmännisches Und-Zeichen mit Escapezeichen

Details

Ab .NET Framework 4.5 wird das kaufmännische Und-Zeichen (&) von System.Web.HttpUtility.JavaScriptStringEncode(String) mit einem Escapezeichen versehen.

Vorschlag

Wenn Ihre App vom vorherigen Verhalten dieser Methode abhängig ist, können Sie dem appSettings-Element von ASP.NET eine „aspnet:JavaScriptDoNotEncodeAmpersand“-Einstellung in der Konfigurationsdatei hinzufügen.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• HttpUtility.JavaScriptStringEncode(String)
• HttpUtility.JavaScriptStringEncode(String, Boolean)

„iPad“ sollte in der Datei für benutzerdefinierte Funktionen nicht verwendet werden, da es sich dabei nun um eine Browserfunktion handelt

Details

Ab .NET Framework 4.5 handelt es sich bei „iPad“ um einen Bezeichner in der ASP.NET-Standarddatei für Browserfunktionen, der deshalb nicht in einer Datei für benutzerdefinierte Funktionen verwendet werden sollte.

Vorschlag

Wenn bestimmte Funktionen von „iPad“ erforderlich sind, muss das Verhalten von „iPad“ geändert werden, indem die Funktionen auf dem vorab definierten Gateway auf refID „iPad“ festgelegt werden, statt eine neue ID für „iPad“ durch Abgleich mit dem Benutzer-Agent zu generieren.

Name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Das Page.LoadComplete-Ereignis führt nicht mehr dazu, dass das System.Web.UI.WebControls.EntityDataSource-Steuerelement die Datenbindung aufruft

Details

Das LoadComplete-Ereignis führt nicht mehr dazu, dass das System.Web.UI.WebControls.EntityDataSource-Steuerelement Datenbindungen für Änderungen an Erstellungs-/Update-/Löschparametern aufruft. Diese Änderung schließt unnötige Roundtrips zur Datenbank sowie ein Zurücksetzen der Werte von Steuerelementen aus und erzeugt Verhaltensweisen, die mit anderen Datensteuerelementen, z. B. System.Web.UI.WebControls.SqlDataSource und System.Web.UI.WebControls.ObjectDataSource konsistent sind. Diese Änderung erzeugt im unwahrscheinlichen Fall, dass Anwendungen im LoadComplete-Ereignis auf Aufrufen der Datenbindung basieren, ein anderes Verhalten.

Vorschlag

Wenn die Datenbindung erforderlich ist, rufen Sie sie manuell in einem Ereignis auf, das im Postback früher auftritt.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Profilerstellung für ASP.NET MVC4-Apps kann zu schwerwiegendem Fehler der Ausführungs-Engine führen

Details

Profiler, die NGEN- bzw. Profilassemblys verwenden, lösen möglicherweise beim Start von ASP.NET MVC4-Anwendungen mit Profilen einen „schwerwiegenden Fehler der Ausführungs-Engine“ aus

Vorschlag

Dieses Problem wurde in .NET Framework 4.5.2 behoben. Der Profiler kann das Problem jedoch umgehen, indem er COR_PRF_DISABLE_ALL_NGEN_IMAGES in der Ereignismaske angibt.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Für das Freigeben des Sitzungszustands mit ASP.NET StateServer müssen alle Server in der Webfarm dieselbe .NET Framework-Version verwenden

Details

Wenn ein System.Web.SessionState.SessionStateMode.StateServer-Sitzungszustand aktiviert wird, müssen alle Server in der jeweiligen Webfarm dieselbe Version von .NET Framework verwenden, damit der Zustand ohne Probleme freigegeben werden kann.

Vorschlag

Führen Sie für alle .NET Framework-Versionen auf Webservern, für die ein Zustand freigegeben wird, gleichzeitig ein Upgrade aus.

	Wert
Umfang	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• SessionStateMode.StateServer

WebUtility.HtmlDecode decodiert keine ungültigen Eingabesequenzen mehr

Details

Decodierungsmethoden decodieren nicht mehr standardmäßig ungültige Eingabesequenzen in ungültige UTF-16-Zeichenfolgen. Stattdessen geben sie die ursprüngliche Eingabe zurück.

Vorschlag

Die Änderung der Decoderausgabe sollte nur von Bedeutung sein, wenn Sie Binärdaten statt der UTF-16-Daten in Zeichenfolgen speichern. Um dieses Verhalten explizit zu steuern, legen Sie das aspnet:AllowRelaxedUnicodeDecoding-Attribut des appSettings-Elements auf true fest, um Legacyverhalten zu aktivieren, oder auf false, um das aktuelle Verhalten zu aktivieren.

	Wert
Umfang	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• WebUtility.HtmlDecode(String)
• WebUtility.HtmlDecode(String, TextWriter)
• WebUtility.UrlDecode(String)

Core

Mit der Regex.CompileToAssembly-Methode kompilierte Assemblys zwischen 4.0 und 4.5 werden unterbrochen

Details

Wenn eine Assembly aus kompilierten regulären Ausdrücken mit .NET Framework 4.5 erstellt wird und auf .NET Framework 4 ausgerichtet ist, wird bei dem Versuch, die regulären Ausdrücke in dieser Assembly auf einem System zu verwenden, auf dem .NET Framework 4 installiert ist, eine Ausnahme ausgelöst.

Vorschlag

Um dieses Problem zu umgehen, haben Sie die folgenden Möglichkeiten:

• Erstellen Sie die Assembly, die die regulären Ausdrücke enthält, mit .NET Framework 4.
• Verwenden Sie einen interpretierten regulären Ausdruck.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName)
• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName, CustomAttributeBuilder[])
• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName, CustomAttributeBuilder[], String)

BlockingCollection<T>.TryTakeFromAny löst keine Ausnahmen mehr aus

Details

Wenn eine der Eingabeauflistungen als abgeschlossen markiert ist, gibt TryTakeFromAny(BlockingCollection<T>[], T) nicht länger „-1“ zurück und TakeFromAny(BlockingCollection<T>[], T) löst keine Ausnahme mehr aus. Diese Änderung ermöglicht das Verwenden von Auflistungen, wenn eine der Auflistungen entweder leer oder abgeschlossen ist, die andere Auflistung aber weiterhin abrufbare Elemente enthält.

Vorschlag

Wenn die Rückgabe von „-1“ durch „TryTakeFromAny“ oder das Auslösen einer Ausnahme durch „TakeFromAny“ für solche Situationen zu Ablaufsteuerungszwecken verwendet wurde, in denen eine blockierende Auflistung abgeschlossen wurde, sollte dieser Code jetzt geändert werden, um .Any(b => b.IsCompleted) zum Erkennen dieser Bedingung zu verwenden.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• BlockingCollection<T>.TakeFromAny(BlockingCollection<T>[], T)
• BlockingCollection<T>.TakeFromAny(BlockingCollection<T>[], T, CancellationToken)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, Int32)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, TimeSpan)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, TimeSpan)

Änderung des Verhaltens für Task.WaitAll-Methoden mit Timeout-Argumenten

Details

Das Task.WaitAll-Verhalten wurde in .NET Framework 4.5 einheitlicher gestaltet. In .NET Framework 4 haben sich diese Methoden unterschiedlich verhalten. Wenn vor dem abgelaufenen Timeoutintervall eine oder mehrere Aufgaben vor dem Methodenaufruf abgeschlossen oder abgebrochen wurden, löste die Methode eine System.AggregateException-Ausnahme aus. Wenn vor dem abgelaufenen Timeoutintervall keine Aufgaben vor dem Methodenaufruf abgeschlossen oder abgebrochen wurden, aber eine oder mehrere Aufgaben nach dem Methodenaufruf in diesen Zustand eingetreten waren, gab die Methode „false“ zurück.

In .NET Framework 4.5 geben diese Methodenüberladungen jetzt FALSE zurück, falls noch Aufgaben ausgeführt werden, wenn das Timeoutintervall abläuft, und sie lösen nur dann eine System.AggregateException-Ausnahme aus, wenn eine Eingabeaufgabe abgebrochen wurde (unabhängig davon, ob dies vor oder nach dem Aufruf der Methode erfolgt ist) und keine anderen Aufgaben mehr ausgeführt werden.

Vorschlag

Wenn eine System.AggregateException als Mittel zum Erkennen einer Aufgabe abgefangen wurde, die vor dem WaitAll-Aufruf abgebrochen wurde, sollte dieser Code stattdessen dieselbe Erkennung über die IsCanceled-Eigenschaft durchführen (Beispiel: .Any(t => t.IsCanceled)), da .NET Framework 4.6 nur in dem Fall eine Ausnahme auslöst, wenn alle erwarteten Aufgaben vor dem Timeout abgeschlossen sind.

	Wert
Umfang	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• Task.WaitAll(Task[], Int32)
• Task.WaitAll(Task[], Int32, CancellationToken)
• Task.WaitAll(Task[], TimeSpan)

Compilerunterstützung für Typweiterleitung bei Festlegung von Zielversionen für das mscorlib-Element

Details

Durch ein neues CodeDOM-Feature kann ein Compiler anhand der Zielversion von mscorlib.dll anstelle der .NET Framework 4.5-Version von mscorlib.dll kompilieren.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

ConcurrentQueue<T>.TryPeek kann über einen out-Parameter einen fehlerhaften NULL-Wert zurückgeben

Details

In einigen Multithreaded-Szenarien kann System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) „true“ zurückgeben, aber den Out-Parameter mit einem Nullwert füllen (anstelle des richtigen Werts).

Vorschlag

Dieses Problem wurde in .NET Framework 4.5.1 behoben. Dieses Problem wird durch ein Upgrade auf diese .NET Framework-Version behoben.

name	Wert
Bereich	Hauptversion
Version	4.5
Typ	Laufzeit

Betroffene APIs

• ConcurrentQueue<T>.TryPeek(T)

ETW EventListeners erfassen keine Ereignisse von Anbietern mit expliziten Schlüsselwörtern (wie der TPL-Anbieter).

Details

ETW EventListeners mit leerer Schlüsselwortmaske erfassen Ereignisse von Anbietern mit expliziten Schlüsselwörtern nicht ordnungsgemäß. In .NET Framework 4.5 hat der TPL-Anbieter damit begonnen, explizite Schlüsselwörter bereitzustellen und dadurch dieses Problem ausgelöst. In .NET Framework 4.6 wurde „EventListeners“ aktualisiert, damit dieses Problem nicht mehr auftritt.

Vorschlag

Ersetzen Sie zur Umgehung dieses Problems Aufrufe von EnableEvents(EventSource, EventLevel) durch Aufrufe der EnableEvents-Überladung, die explizit die Maske für beliebige Schlüsselwörter angibt: EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff)).

Dieses Problem wurde alternativ in .NET Framework 4.6 behoben und kann durch ein Upgrade auf diese Version von .NET Framework vermieden werden.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• EventListener.EnableEvents(EventSource, EventLevel)

Ausnahmen während der nicht überwachten Verarbeitung in System.Threading.Tasks.Task werden nicht mehr an den Finalizerthread weitergegeben

Details

Da die System.Threading.Tasks.Task-Klasse einen asynchronen Vorgang darstellt, fängt sie alle nicht schwerwiegenden Ausnahmen ab, die während einer asynchronen Verarbeitung auftreten. Wenn eine Ausnahme in .NET Framework 4.5 nicht überwacht wird und der Code nie auf die Aufgabe wartet, wird die Ausnahme nicht mehr im Finalizer-Thread weitergegeben und führt dazu, dass der Prozess während der Garbage Collection abstürzt. Diese Änderung erhöht die Zuverlässigkeit von Anwendungen, die mithilfe der Task-Klasse nicht überwachte asynchrone Verarbeitungen ausführen.

Vorschlag

Wenn eine App von nicht überwachten asynchronen Ausnahmen abhängt, die an den Finalizer-Thread weitergegeben werden, kann das vorherige Verhalten wiederhergestellt werden, indem ein entsprechender Handler für das UnobservedTaskException-Ereignis bereitgestellt oder ein Runtimekonfigurationselement festgelegt wird.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• Task.Run(Action)
• Task.Run(Action, CancellationToken)
• Task.Run(Func<Task>)
• Task.Run(Func<Task>, CancellationToken)
• Task.Run<TResult>(Func<TResult>)
• Task.Run<TResult>(Func<TResult>, CancellationToken)
• Task.Run<TResult>(Func<Task<TResult>>)
• Task.Run<TResult>(Func<Task<TResult>>, CancellationToken)
• Task.Start()
• Task.Start(TaskScheduler)

Der List.Sort-Algorithmus wurde geändert

Details

Ab .NET Framework 4.5 wird als Sortieralgorithmus von System.Collections.Generic.List<T> nicht mehr Quicksort, sondern Introsort verwendet. Der Sortieralgorithmus von System.Collections.Generic.List<T> war noch nie stabil. Nun treten jedoch möglicherweise bei Sortiervorgängen in anderen Szenarios Instabilitäten auf. Das bedeutet, dass gleichwertige Elemente bei aufeinanderfolgenden Aufrufen der API in verschiedenen Reihenfolgen sortiert werden.

Vorschlag

Da der alte Sortieralgorithmus ebenfalls instabil war (wenn auch in anderer Hinsicht), sollte kein Code vorhanden sein, in dem gleichwertige Element immer in einer bestimmten Reihenfolge sortiert werden müssen. Wenn andere Codeinstanzen auf dieses Verhalten oder das alte Verhalten angewiesen sind, sollte dieser Code durch die Einführung einer Vergleichsfunktion aktualisiert werden, die die Elemente deterministisch in der gewünschten Reihenfolge sortiert.

name	Wert
Bereich	Transparent
Version	4.5
Typ	Laufzeit

Betroffene APIs

• List<T>.Sort()
• List<T>.Sort(IComparer<T>)
• List<T>.Sort(Comparison<T>)
• List<T>.Sort(Int32, Int32, IComparer<T>)

Fehlender Zielframeworkmoniker führt zum Verhalten der Version 4.0

Details

Anwendungen, bei denen auf Assemblyebene kein System.Runtime.Versioning.TargetFrameworkAttribute angewendet wurde, werden automatisch mit der Semantik (den Quirks) von .NET Framework 4.0 ausgeführt. Um eine hohe Qualität sicherzustellen, empfiehlt es sich, dass alle Binärdateien ein System.Runtime.Versioning.TargetFrameworkAttribute als Attribut erhalten, wodurch die Version von .NET Framework angegeben wird, mit denen sie erstellt wurden. Beachten Sie, dass die Verwendung eines Zielframeworkmonikers in einer Projektdatei dazu führt, dass MSBuild automatisch ein System.Runtime.Versioning.TargetFrameworkAttribute anwendet.

Vorschlag

Es sollte ein System.Runtime.Versioning.TargetFrameworkAttribute bereitgestellt werden, entweder durch direktes Hinzufügen des Attributs zur Assembly oder durch Angeben eines Zielframeworks in der Projektdatei oder über die Visual Studio-GUI für Projekteigenschaften.

name	Wert
Bereich	Hauptversion
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Einige .NET-APIs führen zu erstmaligen (behandelten) EntryPointNotFoundExceptions

Details

In .NET Framework 4.5 hat eine geringe Anzahl von .NET-Methoden damit begonnen, erstmalige System.EntryPointNotFoundException auszulösen. Diese Ausnahmen wurden in .NET Framework behandelt, konnten aber die Testautomatisierung unterbrechen, die keine erstmaligen Ausnahmen erwartete. Dieselben APIs stören einige ApiVerifier-Szenarien, wenn „HighVersionLie“ aktiviert ist.

Vorschlag

Dieser Fehler kann durch ein Upgrade auf .NET Framework 4.5.1 vermieden werden. Alternativ kann die Testautomatisierung aktualisiert werden, damit keine Störung durch erstmalige System.EntryPointNotFoundException-Ausnahmen erfolgt.

	Wert
Umfang	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• Debug.Assert(Boolean)
• Debug.Assert(Boolean, String)
• Debug.Assert(Boolean, String, String)
• Debug.Assert(Boolean, String, String, Object[])
• XmlSerializer(Type)

System.Threading.Tasks.Task löst kein ObjectDisposedException mehr aus, nachdem das Objekt verworfen wurde

Details

Mit Ausnahme von IAsyncResult.AsyncWaitHandle lösen System.Threading.Tasks.Task-Methoden keine System.ObjectDisposedException-Ausnahme mehr aus, nachdem das Objekt freigegeben wurde. Durch diese Änderung wird die Verwendung von zwischengespeicherten Tasks unterstützt. Beispielsweise kann eine Methode eine zwischengespeicherte Aufgabe zurückgeben, um einen bereits abgeschlossenen Vorgang darzustellen, anstatt eine neue Aufgabe zuzuordnen. Dies war in früheren .NET Framework-Versionen nicht möglich, da jeder Consumer der Aufgabe diese freigeben konnte und somit unbrauchbar machte.

Vorschlag

Denken Sie daran, dass Task-Methoden in Situationen, in denen das Objekt verworfen wird, keine System.ObjectDisposedException mehr auslösen. Wenn eine App von dieser Ausnahme (zu wissen, dass ein Task verworfen wurde) abhängig war, sollte sie explizit aktualisiert werden, um den Taskstatus mithilfe von Status zu prüfen.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

RFC 3986 kann jetzt verwendet werden, um System.Uri mit Escapezeichen zu versehen

Details

URI-Escapezeichen in .NET Framework 4.5 wurden geändert, um RFC 3986 zu unterstützen. Die speziellen Änderungen umfassen Folgendes:

• System.Uri.EscapeDataString(String) versieht reservierte Zeichen basierend auf RFC 3986 mit Escapezeichen.
• System.Uri.EscapeUriString(String) versieht reservierte Zeichen nicht mit Escapezeichen.
• System.Uri.UnescapeDataString(String) löst keine Ausnahme aus, wenn eine ungültige Escapesequenz gefunden wird.
• Bei nicht reservierten Zeichen mit Escapezeichen werden letztere entfernt.

Vorschlag

• Aktualisieren Sie die Anwendungen, um nicht auf System.Uri.UnescapeDataString(String) angewiesen zu sein, wenn Sie bei einer ungültigen Escapesequenz eine Ausnahme auslösen möchten. Derartige Sequenzen müssen jetzt direkt erkannt werden.
• Erwarten Sie zudem, dass URI- und Datenzeichenfolgen mit und ohne Escapezeichen zwischen .NET Framework 4.0 und .NET Framework 4.5 möglicherweise abweichen und für .NET-Versionen nicht direkt verglichen werden sollten. Stattdessen sollten sie in einer einzelnen .NET-Version analysiert und normalisiert werden, bevor Vergleiche durchgeführt werden.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• Uri.EscapeDataString(String)
• Uri.EscapeUriString(String)
• Uri.UnescapeDataString(String)

Daten

Sql_variant-Daten verwenden sql_variant-Sortierreihenfolgen anstatt Datenbanksortierreihenfolgen

Details

sql_variant-Daten verwenden sql_variant-Sortierreihenfolgen anstatt Datenbanksortierreihenfolgen.

Vorschlag

Diese Änderung behandelt potenzielle Datenbeschädigungen, die verursacht werden, wenn sich die Datenbanksortierreihenfolge von der sql_variant-Sortierreihenfolge unterscheidet. Bei Anwendungen, die auf den beschädigten Daten basieren, treten möglicherweise Fehler auf.

name	Wert
Bereich	Transparent
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

„SqlBulkCopy“ verwendet die Codierung der Zielspalte für Zeichenfolgen

Details

Beim Einfügen von Daten in eine Spalte verwendet System.Data.SqlClient.SqlBulkCopy die Codierung der Zielspalte, und nicht die Standardcodierung für VARCHAR- und CHAR-Typen. Diese Änderung schließt die Gefahr einer möglichen Datenbeschädigung aus, die bei Verwenden der Standardcodierung verursacht wird, wenn diese nicht von der Zielspalte verwendet wird. In seltenen Fällen kann eine vorhandene Anwendung eine SqlException-Ausnahme auslösen, wenn die Änderung der Codierung Daten erzeugt, die zu groß für die Zielspalte sind.

Vorschlag

Gehen Sie davon aus, dass System.Data.SqlClient.SqlBulkCopy keine Daten mehr aufgrund von Codierungsunterschieden beschädigt. Wenn Zeichenfolgen kopiert werden, die fast das Größenlimit der Zielspalte erreicht haben, kann es erforderlich sein, die Daten (die kopiert werden sollen, um zu überprüfen, dass die Daten in die Zielspalte passen) vorab zu codieren oder System.Data.SqlClient.SqlException-Ausnahmen abzufangen.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• System.Data.SqlClient.SqlBulkCopy
• SqlBulkCopy(SqlConnection)

SqlConnection kann keine Verbindung mit SQL Server 1997 oder Datenbanken herstellen, die den VIA-Adapter verwenden

Details

Verbindungen mit SQL Server-Datenbanken unter Verwendung des Virtual Interface Adapter-Protokolls (VIA) werden nicht mehr unterstützt. Das Protokoll, das verwendet wird, um eine Verbindung mit der SQL Server-Datenbank herzustellen, wird in der Verbindungszeichenfolge angezeigt. Eine VIA-Verbindung bleibt über <servername> erhalten. Wenn diese App über ein anderes Protokoll als das VIA-Protokoll eine Verbindung mit SQL herstellt (z. B. tcp: oder np:) kommt es nicht zu einem Breaking Change. Außerdem werden Verbindungen mit SQL Server 7 (1997) nicht mehr unterstützt.

Vorschlag

Das VIA-Protokoll ist veraltet. Daher sollte ein anderes Protokoll verwendet werden, um eine Verbindung mit SQL-Datenbanken herzustellen. TCP/IP ist das am häufigsten verwendete Protokoll. Weitere Informationen zum Herstellen einer Verbindung über TCP/IP finden Sie unter Aktivieren des TCP/IP-Protokolls für eine Datenbankinstanz. Wenn Sie nur über ein Intranet auf eine Datenbank zugreifen, ist die Leistung des Protokolls für freigegebene Pipes möglicherweise besser, wenn das Netzwerk langsam ist.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• SqlConnection(String)
• SqlConnection(String, SqlCredential)

SqlConnection.Open schlägt unter Windows 7 mit vorhandenem Nicht-IFS-Winsock-BSP oder -LSP fehl

Details

Auf einem Windows 7-Computer mit einem Nicht-IFS-Winsock-BSP oder -LSP schlagen Open() und OpenAsync(CancellationToken) in .NET Framework 4.5 fehl. Verwenden Sie den Befehl netsh WinSock Show Catalog, und untersuchen Sie alle Winsock Catalog Provider Entry-Elemente, die zurückgegeben werden, um zu erkennen, ob ein Nicht-IFS-Winsock-BSP oder -LSP installiert ist. Wenn für den Servicekennzeichenwert das 0x20000-Bit gesetzt ist, verwendet der Anbieter IFS-Handle und funktioniert daher ordnungsgemäß. Wenn das 0x20000-Bit leer (nicht festgelegt) ist, handelt es sich um ein Nicht-IFS-BSP oder -LSP.

Vorschlag

Dieses Problem wurde in .NET Framework 4.5.2 behoben, daher kann es durch ein Upgrade von .NET Framework vermieden werden. Alternativ kann es durch Entfernen aller installierten Nicht-IFS-Winsock-LSPs vermieden werden.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• SqlConnection.Open()
• SqlConnection.OpenAsync(CancellationToken)

Debugger

NULL-Zusammenfügungswerte werden erst im nächsten Schritt angezeigt

Details

Durch einen Fehler in .NET Framework 4.5 werden Werte, die über einen zusammenfügenden NULL-Vorgang festgelegt werden, nicht unmittelbar im Anschluss an die Zuweisung im Debugger angezeigt, wenn sie auf einer 64-Bit-Version des Frameworks ausgeführt werden.

Vorschlag

Wenn Sie im Debugger einen zusätzlichen Schritt ausführen, wird der lokale Wert bzw. der Feldwert ohne Probleme aktualisiert. Dieses Problem wurde auch in .NET Framework 4.6 behoben und sollte nach einem Upgrade auf diese Version nicht mehr auftreten.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Entity Framework

Änderung des Verhaltens in DDL-APIs (Data Definition Language, Datendefinitionssprachen)

Details

Das Verhalten von DDL-APIs beim Angeben von „AttachDBFilename“ hat sich wie folgt geändert:

• Verbindungszeichenfolgen müssen keinen „Initial Catalog“-Wert angeben. Zuvor waren „AttatchDBFilename“ und „Initial Catalog“ erforderlich.
• Wenn „AttatchDBFilename“ und „Initial Catalog“ angegeben sind und die angegebene MDF-Datei vorhanden ist, gibt die DatabaseExists-Methode true zurück. Bislang hat sie false zurückgegeben.
• Wenn „AttatchDBFilename“ und „Initial Catalog“ angegeben sind und die angegebene MDF-Datei vorhanden ist, werden die Dateien durch Aufrufen der DeleteDatabase-Methode gelöscht.
• Wird DeleteDatabase aufgerufen, wenn die Verbindungszeichenfolge einen „AttachDBFilename“-Wert mit einer MDF-Datei und einem „Initial Catalog“ angibt, die beide nicht vorhanden sind, löst die Methode eine InvalidOperationException-Ausnahme aus. Zuvor hat sie eine SqlException-Ausnahme ausgelöst.

Vorschlag

Diese Änderungen erleichtern das Erstellen von Tools und Anwendungen, die die DDL-APIs verwenden. Diese Änderungen können sich in den folgenden Szenarien auf die Anwendungskompatibilität auswirken:

• Der Benutzer schreibt Code, der einen DROP DATABASE-Befehl ausführt, anstatt direkt DeleteDatabase aufzurufen, wenn DatabaseExiststrue zurückgibt. Ist die Datenbank nicht angefügt, die MDF-Datei jedoch vorhanden, wird vorhandener Code hierdurch unbrauchbar.
• Der Benutzer schreibt Code, der erwartet, dass die DeleteDatabase-Methode eine SqlException- anstelle einer InvalidOperationException-Ausnahme auslöst, wenn „Initial Catalog“ und MDF-Datei nicht vorhanden sind.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Unterschiedliche Ausnahmebehandlung für die Methoden „ObjectContext.CreateDatabase“ und „DbProviderServices.CreateDatabase“

Details

Ab .NET Framework 4.5 versuchen CreateDatabase-Methoden, eine leere Datenbank zu löschen, wenn die Datenbankerstellung fehlgeschlagen ist. Wenn dieser Vorgang erfolgreich ist, wird die ursprüngliche System.Data.SqlClient.SqlException weitergegeben (anstelle der System.InvalidOperationException, die in .NET Framework 4.0 immer ausgelöst wurde).

Vorschlag

Beim Abfangen einer System.InvalidOperationException-Ausnahme während der Ausführung von CreateDatabase() oder CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection) sollten SQLExceptions-Ausnahmen nun ebenfalls abgefangen werden.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• ObjectContext.CreateDatabase()
• DbProviderServices.CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection)

EntityFramework 6.0 wird in Apps, die über Visual Studio gestartet wurden, sehr langsam geladen

Details

Das Starten einer App, die EntityFramework 6.0 verwendet, kann über Visual Studio 2013 sehr langsam sein.

Vorschlag

Dieses Problem wurde in EntityFramework 6.0.2 behoben. Aktualisieren Sie EntityFramework, um die Leistungsprobleme zu vermeiden.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Der von der ObjectContext.CreateDatabase-Methode erstellte Protokolldateiname wurde geändert, um den SQL Server-Spezifikationen zu entsprechen

Details

Wenn die System.Data.Objects.ObjectContext.CreateDatabase()-Methode entweder direkt oder durch Code First mit dem SqlClient-Anbieter und einem AttachDBFilename-Wert in der Verbindungszeichenfolge aufgerufen wird, erstellt sie eine Protokolldatei namens „Dateiname_log.ldf“ anstelle von „Dateiname.ldf“ (wobei „Dateiname“ der vom AttachDBFilename-Wert angegebene Name der Datei ist). Diese Änderung verbessert das Debuggen, indem eine Protokolldatei bereitgestellt wird, die nach den SQL Server-Spezifikationen benannt wird.

Vorschlag

Wenn der Name der Protokolldatei für eine App wichtig ist, sollte die App aktualisiert werden, um das standardmäßige Dateinamenformat „_log.ldf“ zu erwarten.

	Wert
Umfang	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• ObjectContext.CreateDatabase()

ObjectContext.Translate und ObjectContext.ExecuteStoreQuery unterstützen jetzt den Enumerationstyp

Details

In .NET Framework 4.0 konnte der generische Parameter T von ObjectContext.Translate- und ObjectContext.ExecuteStoreQuery-Methoden kein Enumerationstyp sein. Dieses Szenario wird jetzt unterstützt.

Vorschlag

Wenn für einen Enumerationstyp in .NET Framework 4.0 „Translate“ oder „ExecuteStoreQuery“ aufgerufen wurde, wurde „0“ zurückgegeben. Wenn dieses Verhalten erwünscht war, sollten die Aufrufe durch eine konstante 0 (oder das entsprechende Enum-Äquivalent) ersetzt werden.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• ObjectContext.Translate<TElement>(DbDataReader)
• ObjectContext.Translate<TEntity>(DbDataReader, String, MergeOption)
• ObjectContext.ExecuteStoreQuery<TElement>(String, Object[])
• ObjectContext.ExecuteStoreQuery<TEntity>(String, String, MergeOption, Object[])

LINQ

Enumerable.Empty<TResult> gibt immer die zwischengespeicherte Instanz zurück

Details

Ab .NET Framework 4.5 gibt Empty<TResult>() eine zwischengespeicherte interne Instanz von IEnumerable<T> zurück. Zuvor zwischenspeicherte Empty<TResult>() beim Aufruf der API eine leere IEnumerable<T>-Instanz, wodurch unter bestimmten Umständen, durch die Empty<TResult>() schnell und gleichzeitig aufgerufen wurde, verschiedene Instanzen des Typs für unterschiedliche Aufrufe der API zurückgegeben werden konnten.

Vorschlag

Da das vorherige Verhalten nicht deterministisch war, ist es unwahrscheinlich, dass der Code davon abhängig ist. Jedoch für den unwahrscheinlichen Fall, dass leere Enumerables verglichen werden und dabei erwartet wird, dass diese gelegentlich ungleich sind, sollten explizite leere Arrays erstellt werden (new T[0]), anstatt Empty<TResult>() zu verwenden.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• Enumerable.Empty<TResult>()

Managed Extensibility Framework (MEF)

MEF-Kataloge implementieren IEnumerable und können daher nicht mehr verwendet werden, um ein Serialisierungsmodul zu erstellen

Details

Ab .NET Framework 4.5 implementieren MEF-Kataloge IEnumerable und können daher nicht mehr verwendet werden, um ein Serialisierungsmodul (System.Xml.Serialization.XmlSerializer-Objekt) zu erstellen. Wenn Sie versuchen, einen MEF-Katalog zu serialisieren, wird eine Ausnahme ausgelöst.

Vorschlag

MEF kann nicht mehr zum Erstellen eines Serialisierungsprogramms verwendet werden.

name	Wert
Bereich	Hauptversion
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Netzwerk

Die Deserialisierung von MailMessage-Objekten, die unter .NET Framework 4.5 serialisiert wurden, kann möglicherweise fehlschlagen

Details

Ab .NET Framework 4.5 können MailMessage-Objekte keine Zeichen mehr enthalten, die keine ASCII-Zeichen sind. In .NET Framework 4 werden nur ASCII-Zeichen unterstützt. MailMessage-Objekte, die Zeichen enthalten, bei denen es sich nicht um ASCII-Zeichen handelt, und unter .NET Framework 4.5 oder höher serialisiert werden, können unter .NET Framework 4 nicht deserialisiert werden.

Vorschlag

Vergewissern Sie sich, dass Ihr Code die Behandlung von Ausnahmen umfasst, wenn Sie ein MailMessage-Objekt deserialisieren.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• System.Web.Mail.MailMessage

System.NET.PeerToPeer.Collaboration ist unter Windows 8 nicht verfügbar

Details

Der System.Net.PeerToPeer.Collaboration-Namespace ist unter Windows 8 oder höher nicht verfügbar.

Vorschlag

Apps, die Windows 8 oder höher unterstützen, müssen aktualisiert werden, damit sie von diesem Namespace oder seinen Membern nicht abhängig sind.

name	Wert
Bereich	Hauptversion
Version	4.5
Typ	Laufzeit

Betroffene APIs

• System.Net.PeerToPeer.Collaboration

Drucken

In PrintSystemJobInfo.JobStream geschriebene Daten müssen in XPS formatiert sein

Details

Die JobStream-Eigenschaft macht den Stream eines Druckauftrags verfügbar. Der Benutzer kann Rohdaten an das zugrunde liegende Betriebssystem senden, das Komponenten druckt, indem es in diesen Stream schreibt. Ab .NET Framework 4.5 unter Windows 8 und höheren Windows-Betriebssystemversionen müssen in diesen Stream geschriebene Daten als Paketstream im XPS-Format vorliegen.

Vorschlag

Zum Ausgeben der Druckinhalte können Sie einen der folgenden Schritte ausführen:

• Verwenden Sie die XpsDocumentWriter-Klasse, um Druckinhalte auszugeben. Dies ist die empfohlene Alternative.
• Stellen Sie sicher, dass die Daten, die an den von der JobStream-Eigenschaft zurückgegebenen Stream gesendet werden, im XPS-Format als Paketstream vorliegen.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• PrintSystemJobInfo.JobStream

Serialisierung

„BinaryFormatter“ findet den Typ im LoadFrom-Kontext möglicherweise nicht

Details

Ab .NET Framework 4.5 führen diverse System.Xml.Serialization.XmlSerializer-Änderungen zu Unterschieden in der Deserialisierung, wenn System.Runtime.Serialization.Formatters.Binary.BinaryFormatter verwendet wird, um Typen zu deserialisieren, die im LoadFrom-Kontext geladen wurden. Diese Änderungen werden durch die neuen Arten hervorgerufen, auf die System.Xml.Serialization.XmlSerializer nun Typen lädt. Dies führt zu einem abweichenden Verhalten, wenn System.Runtime.Serialization.Formatters.Binary.BinaryFormatter versucht, diese Typen später zu deserialisieren. Der Standardbinder für die Serialisierung durchsucht den LoadFrom-Kontext nicht automatisch, obwohl dies in einigen Fällen funktioniert haben kann, die auf dem früheren Verhalten von „XmlSerializer“ basieren. Wegen der Änderung kann eine System.IO.FileNotFoundException-Ausnahme ausgelöst werden, wenn ein Typ aus einer Assembly geladen wird, die in einem anderen Kontext geladen wurde.

Warnung

Die binäre Serialisierung mit BinaryFormatter kann gefährlich sein. Weitere Informationen finden Sie im BinaryFormatter-Sicherheitsleitfaden.

Vorschlag

Wenn diese Ausnahme angezeigt wird, kann die Binder-Eigenschaft von System.Runtime.Serialization.Formatters.Binary.BinaryFormatter auf einen benutzerdefinierten Binder festgelegt werden, der den richtigen Typ

var formatter = new BinaryFormatter { Binder = new TypeFinderBinder() }

und anschließend den benutzerdefinierten Binder sucht:

public class TypeFinderBinder : SerializationBinder
{
    private static readonly string s_assemblyName = Assembly.GetExecutingAssembly().FullName;

    public override Type BindToType(string assemblyName, string typeName)
    {
        return Type.GetType(String.Format(CultureInfo.InvariantCulture, "{0}, {1}", typeName, s_assemblyName));
    }
}

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
• BinaryFormatter.Deserialize(Stream)
• BinaryFormatter.Deserialize(Stream, HeaderHandler)

Hashtable und ähnlich sortierte Auflistungsobjekte können von SoapFormatter nicht deserialisiert werden

Details

System.Runtime.Serialization.Formatters.Soap.SoapFormatter garantiert nicht dafür, dass unter einer .NET Framework-Version serialisierte Objekte erfolgreich unter einer anderen Version deserialisiert werden können. Insbesondere einige sortierte Auflistungen (z.B. System.Collections.Hashtable) haben Member zwischen 4.0 und 4.5 hinzugefügt, sodass Objekte dieser Typen nicht mit .NET Framework 4.0 deserialisiert werden können, wenn sie mit .NET Framework 4.5 serialisiert wurden. Beachten Sie, dass kein Problem auftritt, wenn die serialisierten Daten mit derselben Version von .NET Framework sowohl serialisiert als auch deserialisiert werden.

Vorschlag

Die System.Runtime.Serialization.Formatters.Soap.SoapFormatter-Serialisierung sollte durch die System.Runtime.Serialization.Formatters.Binary.BinaryFormatter-Serialisierung oder durch System.Runtime.Serialization.NetDataContractSerializer ersetzt werden, um .NET Framework-Änderungen verarbeiten zu können.

Warnung

Die binäre Serialisierung mit BinaryFormatter kann gefährlich sein. Weitere Informationen finden Sie im BinaryFormatter-Sicherheitsleitfaden.

Name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• SoapFormatter.Serialize(Stream, Object)
• SoapFormatter.Serialize(Stream, Object, Header[])
• SoapFormatter.Deserialize(Stream)
• SoapFormatter.Deserialize(Stream, HeaderHandler)

„XmlSerializer“ schlägt während der Serialisierung eines Typs fehl, der einen verfügbaren Member mit einem nicht verfügbaren überdeckt

Details

Bei der Serialisierung eines abgeleiteten Typs kann System.Xml.Serialization.XmlSerializer fehlschlagen, wenn der Typ einen verfügbaren Member oder eine Eigenschaft enthält, die ein Feld oder eine Eigenschaft mit dem gleichen Namen ausblendet (durch das Schlüsselwort „new“), das bzw. die zuvor im Basistyp verfügbar (z.B. „public“) war.

Vorschlag

Dieses Problem kann gelöst werden, indem das neue, ausgeblendete Mitglied zugänglich für die System.Xml.Serialization.XmlSerializer (z. B. durch Markierung öffentlich) wird. Alternativ wird die folgende Konfigurationseinstellung auf das 4.0-Verhalten System.Xml.Serialization.XmlSerializer zurückgesetzt, wodurch das Problem behoben wird:

<system.xml.serialization>
<xmlSerializer useLegacySerializerGeneration="true" />
</system.xml.serialization>

Name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• XmlSerializer.Serialize(Stream, Object)
• XmlSerializer.Serialize(TextWriter, Object)
• XmlSerializer.Serialize(Object, XmlSerializationWriter)
• XmlSerializer.Serialize(XmlWriter, Object)
• XmlSerializer.Serialize(Stream, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(TextWriter, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces, String)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces, String, String)

Webanwendungen

Verwaltete Browser-Hoststeuerelemente von .NET Framework 1.1 und 2.0 werden blockiert

Details

Das Hosting dieser Steuerelemente wird in Internet Explorer blockiert.

Vorschlag

Internet Explorer kann eine Anwendung, die verwaltete Browserhostingsteuerelemente verwendet, nicht starten. Das vorherige Verhalten kann wiederhergestellt werden, indem der EnableIEHosting-Wert des Registrierungsunterschlüssels HKLM/SOFTWARE/MICROSOFT/.NETFramework für x86-Systeme und für 32-Bit-Prozesse auf x64-Systeme auf 1 festgelegt wird und indem der EnableIEHosting-Wert des Registrierungsunterschlüssels HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFramework für 64-Bit-Prozesse auf x64-Systemen auf 1 festgelegt wird.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Windows Communication Foundation (WCF)

Die Fehlercodes für maxRequestLength oder maxReceivedMessageSize sind unterschiedlich

Details

Meldung in WCF-Webdiensten, die in Internetinformationsdiensten (Internet Information Services, IIS) oder in ASP.NET Development Server gehostet werden und maxRequestLength (in ASP.NET) oder maxReceivedMessageSize (in WCF) überschreiten, haben verschiedene Fehlercodes. Der HTTP-Statuscode hat sich von 400 (Ungültige Anforderung) in 413 (Anforderungseinheit zu groß) geändert, und entweder die maxRequestLength- oder die maxReceivedMessageSize-Einstellung löst eine System.ServiceModel.ProtocolException-Ausnahme aus. Dies gilt auch für Fälle, in denen der Übergangsmodus „Streamed“ ist.

Vorschlag

Diese Änderung erleichtert das Debuggen in Fällen, in denen die Länge der Meldung die von ASP.NET oder WCF zulässigen Limits überschreiten. Sie müssen sämtlichen Code ändern, der Verarbeitungen auf Grundlage des HTTP-Statuscodes „400“ durchführt.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Das System.ServiceModel.Web.WebServiceHost-Objekt fügt keinen Standardendpunkt mehr hinzu

Details

Das WebServiceHost-Objekt fügt keinen standardmäßigen Endpunkt mehr hinzu, wenn ein expliziter Endpunkt vom Anwendungscode hinzugefügt wurde.

Vorschlag

Wenn Benutzer erwarten, dass sie eine Verbindung mit einem Standardendpunkt herstellen können und andere explizite Endpunkte zu System.ServiceModel.Web.WebServiceHost hinzugefügt wurden, sollten (über System.ServiceModel.ServiceHostBase.AddDefaultEndpoints()) auch die Standardendpunkte explizit hinzugefügt werden.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• ServiceHost.AddServiceEndpoint(Type, Binding, String)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, String, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri, Uri)
• ServiceHostBase.AddServiceEndpoint(ServiceEndpoint)
• ServiceHostBase.AddServiceEndpoint(String, Binding, String)
• ServiceHostBase.AddServiceEndpoint(String, Binding, Uri)
• ServiceHostBase.AddServiceEndpoint(String, Binding, String, Uri)
• ServiceHostBase.AddServiceEndpoint(String, Binding, Uri, Uri)

Die Replace-Methode in OData-URLs ist standardmäßig deaktiviert

Details

Ab .NET Framework 4.5 ist die Replace-Methode in OData-URLs standardmäßig deaktiviert. Wenn „Replace“ für OData (jetzt standardmäßig) deaktiviert ist, schlagen alle Benutzeranforderungen fehl, einschließlich der Ersetzungsfunktionen (die nicht üblich sind).

Vorschlag

Wenn die Replace-Methode erforderlich ist (was nicht üblich ist), kann sie über die Konfigurationseinstellung System.Data.Services.Configuration.DataServicesFeaturesSection.ReplaceFunction erneut aktiviert werden. Eine aktivierte Replace-Methode kann jedoch Sicherheitslücken öffnen und sollte nur nach sorgfältiger Prüfung verwendet werden.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• System.Data.Services.DataService<T>

Windows Forms

PreviewLostKeyboardFocus wird wiederholt aufgerufen, wenn der Handler ein Windows Forms-Meldungsfeld anzeigt

Details

Ab .NET Framework 4.5 führt der Aufruf von MessageBox.Show über einen PreviewLostKeyboardFocus-Handler dazu, dass der Handler erneut auslöst, wenn das Meldungsfeld geschlossen wird, was ggf. zu einer Endlosschleife von Meldungsfeldern führt.

Vorschlag

Es gibt zwei Optionen, um dieses Problem zu umgehen:

• Es kann durch Aufrufen von MessageBox.Show anstelle von MessageBox.Show vermieden werden.
• Es kann durch Anzeigen des Meldungsfelds über einen LostKeyboardFocus-Ereignishandler (im Gegensatz zu einem System.Windows.UIElement.PreviewLostKeyboardFocus-Ereignishandler) vermieden werden.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• ContentElement.PreviewLostKeyboardFocus
• IInputElement.PreviewLostKeyboardFocus
• UIElement.PreviewLostKeyboardFocus
• UIElement3D.PreviewLostKeyboardFocus

Die CheckForOverflowUnderflow-Eigenschaft von WinForm ist jetzt für System.Drawing auf TRUE festgelegt

Details

Die CheckForOverflowUnderflow-Eigenschaft für die Assembly „System.Drawing.dll“ ist auf TRUE festgelegt.

Vorschlag

Zuvor wurde das Ergebnis im Fall von Überläufen automatisch abgeschnitten. Nun wird eine System.OverflowException-Ausnahme ausgelöst.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Windows Presentation Foundation (WPF)

Der Zugriff auf die ausgewählten Elemente eines WPF-DataGrid-Steuerelements über einen Handler des UnloadingRow-Ereignisses kann eine NullReferenceException auslösen

Details

Aufgrund eines Fehlers in .NET Framework 4.5 können Ereignishandler für DataGrid-Ereignisse, die das Entfernen einer Zeile umfassen, eine System.NullReferenceException auslösen, die ausgelöst werden soll, wenn auf die System.Windows.Controls.Primitives.Selector.SelectedItem- oder System.Windows.Controls.Primitives.MultiSelector.SelectedItems-Eigenschaft von DataGrid zugegriffen wird.

Vorschlag

Dieses Problem wurde in .NET Framework 4.6 behoben und kann durch ein Upgrade auf diese Version von .NET Framework vermieden werden.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• DataGrid.UnloadingRow
• DataGrid.UnloadingRowDetails

Der Aufruf von DataGrid.CommitEdit über einen CellEditEnding-Handler verliert den Fokus

Details

Wenn das CommitEdit()-Element von einem der System.Windows.Controls.DataGrid.CellEditEnding-Ereignishandler von System.Windows.Controls.DataGrid aufgerufen, verliert System.Windows.Controls.DataGrid den Fokus.

Vorschlag

Dieses Problem wurde in .NET Framework 4.5.2 behoben, daher kann es durch ein Upgrade von .NET Framework vermieden werden. Alternativ kann dies vermieden werden, indem das System.Windows.Controls.DataGrid-Element nach dem Aufruf von System.Windows.Controls.DataGrid.CommitEdit() explizit neu ausgewählt wird.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• DataGrid.CommitEdit()
• DataGrid.CommitEdit(DataGridEditingUnit, Boolean)

Das Aufrufen von Items.Refresh für die WPF-Steuerelemente ListBox, ListView oder DataGrid mit ausgewählten Einträgen kann dazu führen, dass im Element doppelte Einträge angezeigt werden.

Details

In .NET Framework 4.5 kann der Aufruf von „ListBox.Items.Refresh“ mit ausgewählten Einträgen über Code dazu führen, dass die in System.Windows.Controls.ListBox ausgewählten Einträge in der Liste doppelt vorkommen. Bei System.Windows.Controls.ListView und System.Windows.Controls.DataGrid tritt ein ähnliches Problem auf. Dieses Problem wurde in .NET Framework 4.6 behoben.

Vorschlag

Dieses Problem kann dadurch umgangen werden, dass die Auswahl der Einträge programmgesteuert aufgehoben wird, bevor System.Windows.Data.CollectionView.Refresh() aufgerufen wird. Nachdem der Aufruf abgeschlossen ist, werden die Einträge erneut ausgewählt. Dieses Problem wurde alternativ in .NET Framework 4.6 behoben und kann durch ein Upgrade auf diese Version von .NET Framework vermieden werden.

	Wert
Umfang	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• CollectionView.Refresh()

„FlowDocument“ zeigt möglicherweise eine zusätzliche Textzeile an

Details

In einigen Fälle zeigt ein FlowDocument-Element, das unter .NET Framework 4.5 ausgeführt wird, im Gegensatz zu .NET Framework 4.0 eine zusätzliche Textzeile an. Es gibt keine bekannten Fälle, dass durch die Änderung ein Text schlecht oder unleserlich dargestellt wird. Es kann jedoch vorkommen, dass Text angezeigt wird, der zuvor aus der Anzeige von FlowDocument entfernt wurde.

Vorschlag

In einigen Fällen kann das Verringern der PageHeight-Eigenschaft des Anzeigeelements um 1 (eins) die Anzahl der zuvor angezeigten Zeilen wiederherstellen.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• FlowDocument()
• FlowDocument(Block)
• FlowDocumentReader()
• FlowDocumentPageViewer()
• DocumentPageView()

„GlyphRun.ComputeInkBoundingBox()“ und „FormattedText.Extent“ geben ab .NET Framework 4.5 verschiedene Werte zurück

Details

Es wurden in .NET Framework 4.5 Verbesserungen an ComputeInkBoundingBox() und Extent vorgenommen, um Probleme zu beheben, bei denen Felder für die darin enthaltenen Glyphen in .NET Framework 4.0 zu klein waren. Aus diesem Grund sind einige Begrenzungsrahmen in .NET Framework 4.5 größer, sodass sich geringfügige Unterschiede beim Layout der Benutzeroberfläche ergeben.

Vorschlag

Beachten Sie, dass einige Begrenzungsrahmen für Glyphen vergrößert wurden. Diese Änderungen verbessert in der Regel die Darstellung und das Testen von Feldtreffern, aber wenn das ältere Verhalten (vor .NET 4.5) gewünscht wird, kann es durch Hinzufügen des folgenden Eintrags zur Datei „app.config“ aktiviert werden:

<appsettings>
<add key="IncludeAllInkInBoundingBox" value="false">
</appsettings>

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• GlyphRun.ComputeInkBoundingBox()
• FormattedText.Extent

Das Scrollen zum untersten Eintrag in ItemsControl-Steuerelementen (z.B. ListBox und DataGrid) war bei Verwendung von benutzerdefinierten DataTemplates zeitweilig nicht möglich.

Details

In einigen Fällen verursacht ein Fehler in .NET Framework 4.5, dass ItemsControl-Steuerelemente (z.B. System.Windows.Controls.ListBox, System.Windows.Controls.ComboBox und System.Windows.Controls.DataGrid) nicht zum untersten Eintrag scrollen, wenn benutzerdefinierte DataTemplates verwendet werden. Wenn der Vorgang ein zweites Mal versucht wird (nachdem wieder nach oben gescrollt wurde), funktioniert es entsprechend.

Vorschlag

Dieses Problem wurde in .NET Framework 4.5.2 behoben und kann durch ein Upgrade auf diese (oder eine höhere) Version von .NET Framework vermieden werden. Alternativ können Benutzer weiterhin Scrolleisten in diesen Auflistungen ziehen, wobei sie es möglicherweise zweimal versuchen müssen, bis der Vorgang erfolgreich ausgeführt wird.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Items.Clear entfernt keine Duplikate aus SelectedItems

Details

Angenommen, ein Selektor (mit aktivierter Mehrfachauswahl) verfügt in seiner System.Windows.Controls.Primitives.MultiSelector.SelectedItems-Sammlung über Duplikate, sodass das gleiche Element mehrmals angezeigt wird. Beim Entfernen dieser Elemente aus der Datenquelle (z.B. durch Aufrufen von Items.Clear) werden sie dann nicht aus System.Windows.Controls.Primitives.MultiSelector.SelectedItems entfernt. Es wird nur die erste Instanz entfernt. Darüber hinaus kann die anschließende Verwendung von System.Windows.Controls.Primitives.MultiSelector.SelectedItems (z.B. SelectedItems.Clear()) Probleme wie System.ArgumentException verursachen, da System.Windows.Controls.Primitives.MultiSelector.SelectedItems Elemente enthält, die sich nicht mehr in der Datenquelle befinden.

Vorschlag

Führen Sie nach Möglichkeit ein Upgrade auf .NET 4.6.2 durch.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• MultiSelector.SelectedItems

IsSelected-Bindungsfehler für ListBoxItem mit ObservableCollection<T>.Move

Details

Wenn Move(Int32, Int32) oder MoveItem(Int32, Int32) für eine Auflistung aufgerufen werden, die über aktivierte Elemente an ein System.Windows.Controls.ListBox-Element gebunden ist, können bei der (De-)Aktivierung von System.Windows.Controls.ListBox-Elementen Fehler auftreten.

Vorschlag

Wenn Sie anstelle von Move(Int32, Int32)System.Collections.ObjectModel.Collection<T>.Remove(T) und System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) aufrufen, kann dieser Fehler umgangen werden. Dieses Problem wurde alternativ in .NET Framework 4.6 behoben und kann durch ein Upgrade auf diese Version von .NET Framework vermieden werden.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• ObservableCollection<T>.Move(Int32, Int32)
• ObservableCollection<T>.MoveItem(Int32, Int32)

Neue Enumerationswerte in der PageRangeSelection-Enumeration für WPF

Details

Es wurden zwei neue Member (System.Windows.Controls.PageRangeSelection.CurrentPage und System.Windows.Controls.PageRangeSelection.SelectedPages) zur System.Windows.Controls.PageRangeSelection-Enumeration hinzugefügt.

Vorschlag

In den meisten Fällen wirken sich diese Änderungen nicht auf Benutzercode aus. Code, der von einer bestimmten Anzahl von Elementen abhängig ist, die in GetNames(Type)- oder GetValues(Type)-Aufrufen für den System.Windows.Controls.PageRangeSelection-Typ vorhanden sind, sollte jedoch geändert werden.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• System.Windows.Controls.PageRangeSelection

PreviewLostKeyboardFocus wird wiederholt aufgerufen, wenn der Handler ein Windows Forms-Meldungsfeld anzeigt

Details

Ab .NET Framework 4.5 führt der Aufruf von MessageBox.Show über einen PreviewLostKeyboardFocus-Handler dazu, dass der Handler erneut auslöst, wenn das Meldungsfeld geschlossen wird, was ggf. zu einer Endlosschleife von Meldungsfeldern führt.

Vorschlag

Es gibt zwei Optionen, um dieses Problem zu umgehen:

• Es kann durch Aufrufen von MessageBox.Show anstelle von MessageBox.Show vermieden werden.
• Es kann durch Anzeigen des Meldungsfelds über einen LostKeyboardFocus-Ereignishandler (im Gegensatz zu einem System.Windows.UIElement.PreviewLostKeyboardFocus-Ereignishandler) vermieden werden.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• ContentElement.PreviewLostKeyboardFocus
• IInputElement.PreviewLostKeyboardFocus
• UIElement.PreviewLostKeyboardFocus
• UIElement3D.PreviewLostKeyboardFocus

Bei einem Rechtsklick auf einen Zeilenheader des WPF-DataGrid-Steuerelements wird die DataGrid-Auswahl geändert

Details

Bei einem Rechtsklick auf einen ausgewählten System.Windows.Controls.DataGrid-Zeilenheader, wird nur diese ausgewählte Zeile geändert, wenn in System.Windows.Controls.DataGrid mehrere Zeilen ausgewählt sind.

Vorschlag

Dieses Problem wurde in .NET Framework 4.6 behoben und kann durch ein Upgrade auf diese Version von .NET Framework vermieden werden.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• DataGrid()

Scrollvorgänge in einem WPF-TreeView-Element oder in einem gruppierten ListBox-Element in „VirtualizingStackPanel“ können dazu führen, dass eine Anwendung nicht mehr reagiert.

Details

Das Scrollen für ein WPF-System.Windows.Controls.TreeView-Element in .NET Framework 4.5 in einem virtualisierten StackPanel-Element kann dazu führen, dass die Anwendung nicht mehr reagiert, wenn im Anzeigebereich Ränder vorhanden sind (z. B. zwischen den Elementen in System.Windows.Controls.TreeView oder für ein ItemsPresenter-Element). Darüber hinaus können in einigen Fällen Elemente unterschiedlicher Größe in der Ansicht zur Instabilität führen, auch wenn keine Ränder vorhanden sind.

Vorschlag

Dieser Fehler kann durch ein Upgrade auf .NET Framework 4.5.1 vermieden werden. Alternativ können Ränder aus Ansichtsauflistungen (z.B. mehreren System.Windows.Controls.TreeView-Elementen) in virtualisierten StackPanel-Elementen entfernt werden, wenn alle enthaltenen Elemente dieselbe Größe aufweisen.

name	Wert
Bereich	Hauptversion
Version	4.5
Typ	Laufzeit

Betroffene APIs

• VirtualizingStackPanel.SetIsVirtualizing(DependencyObject, Boolean)

WPF DataTemplate-Elemente sind jetzt für die UIA sichtbar

Details

In der Vergangenheit waren System.Windows.DataTemplate-Elemente für die Benutzeroberflächenautomatisierung nicht sichtbar. Ab Version 4.5 erkennt die Benutzeroberflächenautomatisierung diese Elemente. Dies ist zwar in vielen Fällen hilfreich, kann aber bei Tests zu Problemen führen, die von UIA-Strukturen abhängen, die keine System.Windows.DataTemplate-Elemente enthalten.

Vorschlag

Tests für die Benutzeroberflächenautomatisierung für diese App müssen möglicherweise aktualisiert werden, um die UIA-Struktur zu berücksichtigen, die jetzt zuvor unsichtbare System.Windows.DataTemplate-Elemente enthält. Beispielsweise müssen Tests, die erwarten, dass einige Elemente nebeneinander angeordnet sind, jetzt möglicherweise davon ausgehen, dass sich zwischen diesen Elementen zuvor unsichtbare UIA-Elemente befinden. Möglicherweise müssen auch Tests mit neuen Werten aktualisiert werden, die auf bestimmte Werte oder Indizes für UIA-Elemente angewiesen sind.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• DataTemplate()
• DataTemplate(Object)

WPF DispatcherSynchronizationContext.CreateCopy gibt jetzt anstelle der aktuellen Instanz eine neue Kopie zurück

Details

In .NET Framework 4 hat CreateCopy() in erster Linie einen Verweis auf die aktuelle Instanz zurückgegeben, um die Leistung zu optimieren. In .NET Framework 4.5 wird eine neue Instanz zurückgegeben, wodurch es erstmalig möglich ist zu Schlussfolgern, dass gleiche Verweise angeben, dass sich der ausführende Thread im richtigen Synchronisierungskontext befindet. Es ist unwahrscheinlich, dass Code, der die Identität dieser Verweise prüft, betroffen ist. Aber aufgrund der Änderung sollte Code, der CreateCopy() aufruft, im Rahmen der Migration zu .NET Framework 4.5 oder einer höheren Version getestet werden.

Vorschlag

Beachten Sie, dass CreateCopy() jetzt ein neues System.Threading.SynchronizationContext-Objekt zurückgibt. Zuvor wurde Code, der die Gleichheit von Verweisen verwendete, die auf diese Weise generiert wurden, tatsächlich nicht dahingehend überprüft, ob er sich im richtigen Kontext befunden hat. Dies wird jetzt jedoch durchgeführt, wenn bei der Erstellung .NET Framework 4.5 oder höher verwendet wird. Obwohl es unwahrscheinlich ist, dass dies zu Problemen führt, sollte das Anwenden der betroffenen Codepfade ausreichend sein, um zu ermitteln, ob dies zu Problemen führen kann.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• DispatcherSynchronizationContext.CreateCopy()

WPF TextBox verwendet standardmäßig 100 als Grenzwert für die Aktion „Rückgängig machen“

Details

In .NET Framework 4.5 beträgt der Standardgrenzwert für ein WPF-Textfeld 100 (im Gegensatz zu .NET Framework 4.0, bei dem der Wert unbegrenzt ist).

Vorschlag

Wenn der Grenzwert von 100 für die Aktion „Rückgängig machen“ zu niedrig ist, kann er explizit mit UndoLimit festgelegt werden.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• System.Windows.Controls.TextBox

In einem WPF-TextBox-Element markierter Text wird in einer anderen Farbe angezeigt, wenn das Textfeld inaktiv ist

Details

Wenn in .NET Framework 4.5 ein WPF-Textfeldsteuerelement inaktiv ist (nicht den Eingabefokus hat), wird der im Feld markierte Text in einer anderen Farbe als bei einem aktiven Steuerelement angezeigt.

Vorschlag

Das vorherige Verhalten (.NET Framework 4.0) kann wiederhergestellt werden, indem Sie die AreInactiveSelectionHighlightBrushKeysSupported-Eigenschaft auf false festlegen.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• System.Windows.Controls.TextBox

WPF TreeViewItem muss in einem TreeView-Steuerelement verwendet werden

Details

In .NET Framework 4.5 wurde eine Änderung eingeführt, die die Verwendung von System.Windows.Controls.TreeViewItem-Elementen außerhalb eines System.Windows.Controls.TreeView-Steuerelements einschränkt. Dieser Fall kann unter den folgenden Bedingungen eintreten:

• Das visuelle übergeordnete Element von System.Windows.Controls.TreeViewItem ist kein Panel. (Ein für System.Windows.Controls.TreeViewItem generiertes System.Windows.Controls.TreeView-Steuerelement weist einen Panel als dessen übergeordnetes Element auf.)
• Das System.Windows.Controls.TreeViewItem-Element ist ein Nachfolgeelement von System.Windows.Controls.VirtualizingStackPanel, das als „Elementhost“ für ein Listensteuerelement (ListBox, DataGrid, ListView usw.) fungiert. Die Virtualisierung muss nicht aktiviert werden.
• Das System.Windows.Controls.VirtualizingStackPanel-Element wird zum Elementscrolling (ScrollUnit="Item") verwendet.
• Jemand ruft VirtualizingStackPanel.MakeVisible(v) auf, um ein Element v in eine Ansicht zu scrollen. Dies kann auf verschiedene Arten explizit oder implizit erfolgen. Die am häufigsten verwendeten Methode ist möglicherweise einfach das Klicken auf v, damit es den Tastaturfokus erhält.
• Die visuelle Kette des übergeordneten v-Elements zu System.Windows.Controls.VirtualizingStackPanel wird über das System.Windows.Controls.TreeViewItem-Element übergeben.

Das bedeutet, dies wird angezeigt, wenn ein System.Windows.Controls.TreeViewItem außerhalb von System.Windows.Controls.TreeView verwendet wird und der Benutzer auf ein Nachfolgeelement von System.Windows.Controls.TreeViewItem klickt, um ihn anzuzeigen. Wenn System.Windows.Controls.TreeViewItem keine Nachfolgeelemente besitzt, die den Fokus erhalten können, tritt dieses Problem nicht auf. Ein Beispiel für eine entsprechende Situation liegt vor, wenn System.Windows.Controls.TreeViewItem der Stamm von DataTemplate ist. Wenn dieses Problem erreicht wird, tritt „InvalidCastException“ innerhalb des WPF-Frameworks auf.

Vorschlag

Hierfür wird ein Hotfix zur Verfügung gestellt.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Windows Workflow Foundation (WF)

System.Activities ist jetzt APTCA

Details

Die Assembly ist mit dem System.Security.AllowPartiallyTrustedCallersAttribute-Attribut gekennzeichnet.

Vorschlag

Abgeleitete Klassen können nicht mit System.Security.SecurityCriticalAttribute gekennzeichnet werden. Zuvor mussten abgeleitete Typen mit System.Security.SecurityCriticalAttribute gekennzeichnet werden. Diese Änderung sollte jedoch keine tatsächlichen Auswirkungen haben.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

WF serialisiert Expressions.Literal<T> DateTimes jetzt anders (unterbricht benutzerdefinierte XAML-Parser)

Details

Das zugeordnete ValueSerializer-Objekt konvertiert ein System.DateTime- oder System.DateTimeOffset-Objekt, dessen Second- und System.DateTime.Millisecond-Komponenten (Sekunden und Millisekunden) ungleich 0 (null) sind und (für einen System.DateTime-Wert) dessen Kind-Eigenschaft nicht angegeben ist, in eine Eigenschaftenelementsyntax anstatt in eine Zeichenfolge. Durch diese Änderung kann bei System.DateTime- und System.DateTimeOffset-Werten ein Roundtrip ausgeführt werden. Benutzerdefinierte XAML-Parser, die davon ausgehen, dass sich Eingabe-XAML in der Attributsyntax befindet, funktionieren nicht ordnungsgemäß.

Vorschlag

Durch diese Änderung kann bei System.DateTime- und System.DateTimeOffset-Werten ein Roundtrip ausgeführt werden. Benutzerdefinierte XAML-Parser, die davon ausgehen, dass sich Eingabe-XAML in der Attributsyntax befindet, funktionieren nicht ordnungsgemäß.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

XML, XSLT

XmlSchemaException legt Zeilenpositionen jetzt ordnungsgemäß fest

Details

Wenn der SetLineInfo-Wert an die Load-Methode übergeben wird und ein Validierungsfehler auftritt, enthalten die Eigenschaften LineNumber und LinePosition jetzt Zeileninformationen.

Vorschlag

Ausnahmebehandlungscode, der davon ausgeht, dass LineNumber und LinePosition nicht festgelegt werden, sollte aktualisiert werden, da diese Eigenschaften jetzt ordnungsgemäß festgelegt werden kann, wenn „SetLineInfo“ beim Laden von XML verwendet wird.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• LoadOptions.SetLineInfo

Die DTD-Entitätserweiterung „XmlTextReader“ ist auf 10.000.000 Zeichen beschränkt

Details

Die DTD-Entitätserweiterung ist jetzt auf 10.000.000 Zeichen beschränkt. Das Laden von XML-Dateien ohne DTD-Entitätserweiterung oder mit eingeschränkter DTD-Entitätserweiterung ist davon nicht betroffen. Dateien mit DTD-Entitäten, die auf mehr als 10.000.000 Zeichen erweitert werden, können nicht geladen werden und lösen nun eine Ausnahme aus.

Vorschlag

Wenn das Limit der DTD-Entitätserweiterung von 10.000.000 zu niedrig ist, kann der Wert mit der MaxCharactersFromEntities-Eigenschaft außer Kraft gesetzt werden. Eine System.Xml.XmlReaderSettings-Klasse mit dem richtigen System.Xml.XmlReaderSettings.MaxCharactersFromEntities-Wert kann an eine XmlReader.Create-Klasse übergeben werden, die System.Xml.XmlReaderSettings akzeptiert (d. h. Create(String, XmlReaderSettings))

Name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• System.Xml.XmlTextReader
• XmlTextReader()
• XmlTextReader(Stream)
• XmlTextReader(Stream, XmlNameTable)
• XmlTextReader(Stream, XmlNodeType, XmlParserContext)
• XmlTextReader(TextReader)
• XmlTextReader(TextReader, XmlNameTable)
• XmlTextReader(String)
• XmlTextReader(String, Stream)
• XmlTextReader(String, Stream, XmlNameTable)
• XmlTextReader(String, TextReader)
• XmlTextReader(String, TextReader, XmlNameTable)
• XmlTextReader(String, XmlNameTable)
• XmlTextReader(String, XmlNodeType, XmlParserContext)
• XmlTextReader(XmlNameTable)

Die Vorwärtskompatibilität für XSLT funktioniert jetzt

Details

In .NET Framework 4 verursachte die XSLT 1.0-Vorwärtskompatibilität die folgenden Probleme:

• Beim Laden eines Stylesheets trat ein Fehler auf, wenn die Version auf 2.0 festgelegt war und der Parser ein unbekanntes XSLT 1.0-Konstrukt feststellte.
• Das xsl:sort-Konstrukt konnte keine Daten sortieren, wenn die Stylesheetversion in .NET Framework 4.5 auf 1.1. festgelegt wurde, diese Probleme behoben wurden und der XSLT 1.0-Aufwärtskompatibilitätsmodus ordnungsgemäß funktioniert.

Vorschlag

Die meisten Apps sollten zwar davon nicht betroffen sind, aber die Daten werden teilweise unterschiedlich sortiert, da das xsl:sort-Element jetzt berücksichtigt wird. Wenn xsl:sort in 1.1-Stylesheets verwendet wird, sollten Sie sicherstellen, dass die Apps nicht von der unsortierten Reihenfolge von Daten abhängig sind. Wenn Apps von dem in Version 4.0 enthaltenen Sortierverhalten abhängig ist, sollten Sie xsl:sort aus dem Stylesheet entfernen.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• System.Xml.Xsl.XslCompiledTransform

Ausnahmemeldung für XSLT-Stylesheet wurde geändert

Details

In .NET Framework 4.5 lautet die Fehlermeldung bei einer zu komplexen XSLT-Datei wie folgt: „Das Stylesheet ist zu komplex.“ In früheren Versionen lautete die Fehlermeldung „XSLT-Compilerfehler“. Anwendungscode, der vom Text der Fehlermeldung abhängt, funktioniert nicht mehr. Die Ausnahmetypen sind jedoch nach wie vor identisch, daher sollte diese Änderung keine tatsächlichen Auswirkungen haben.

Vorschlag

Aktualisieren Sie jeglichen App-Code so, dass er von der Ausnahmemeldung dieser Fehlerbedingung abhängig ist, um die neue Meldung zu erwarten, oder (noch besser) aktualisieren Sie den Code so, dass er nur vom Ausnahmetyp (System.Xml.Xsl.XsltException) abhängig ist, der nicht geändert wurde.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• XslCompiledTransform.Load(String)
• XslCompiledTransform.Load(Type)
• XslCompiledTransform.Load(XmlReader)
• XslCompiledTransform.Load(IXPathNavigable)
• XslCompiledTransform.Load(MethodInfo, Byte[], Type[])
• XslCompiledTransform.Load(String, XsltSettings, XmlResolver)
• XslCompiledTransform.Load(XmlReader, XsltSettings, XmlResolver)
• XslCompiledTransform.Load(IXPathNavigable, XsltSettings, XmlResolver)

.NET Framework 4.5.1

ADO.NET

ADO.NET versucht nun, unterbrochene SQL-Verbindungen automatisch wiederherzustellen

Details

Ab .NET Framework 4.5.1 versucht .NET Framework, unterbrochene SQL-Verbindungen automatisch wiederherzustellen. Obwohl dies in der Regel dazu führt, dass Apps zuverlässiger werden, gibt es Grenzfälle, in denen eine App wissen muss, dass die Verbindung getrennt wurde, sodass sie bei der Wiederherstellung der Verbindung bestimmte Aktionen ausführen kann.

Vorschlag

Wenn dieses Feature aus Kompatibilitätsgründen nicht erwünscht ist, kann es durch Festlegen der System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount-Eigenschaft einer Verbindungszeichenfolge (oder System.Data.SqlClient.SqlConnectionStringBuilder) auf 0 (null) deaktiviert werden.

name	Wert
Bereich	Microsoft Edge
Version	4.5.1
Typ	Laufzeit

Betroffene APIs

• IDbConnection.ConnectionString
• SqlConnection.ConnectionString
• ConnectionStringSettings.ConnectionString
• DbConnection.ConnectionString
• DbConnectionStringBuilder.ConnectionString
• SqlConnectionStringBuilder()
• SqlConnectionStringBuilder(String)
• DbConnectionStringBuilder()
• DbConnectionStringBuilder(Boolean)

Core

Ein in .NET Framework 4.5 mit NetDataContractSerializer serialisiertes ConcurrentDictionary-Element kann nicht von .NET Framework 4.5.1 oder 4.5.2 deserialisiert werden

Details

Aufgrund von Typänderungen können ConcurrentDictionary<TKey,TValue>-Objekte, die unter Verwendung von System.Runtime.Serialization.NetDataContractSerializer mit .NET Framework 4.5 serialisiert werden, nicht in .NET Framework 4.5.1 oder 4.5.2 deserialisiert werden. Beachten Sie jedoch, dass die Serialisierung mit .NET Framework 4.5.x und die Deserialisierung mit .NET Framework 4.5 funktionieren. Genauso funktioniert die versionsübergreifende Serialisierung in .NET Framework 4.x mit .NET Framework 4.6. Dies hat keine Auswirkungen auf die (De-)Serialisierung einer einzelnen Version von .NET Framework.

Vorschlag

Wenn ein Element vom Typ System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> zwischen .NET Framework 4.5 und .NET Framework 4.5.1/4.5.2 serialisiert und deserialisiert werden muss, muss anstelle von System.Runtime.Serialization.NetDataContractSerializer ein anderes Serialisierungsmodul (beispielsweise System.Runtime.Serialization.DataContractSerializer) verwendet werden. Da dieses Problem in .NET Framework 4.6 behandelt wurde, kann es möglicherweise durch ein Upgrade auf diese Version von .NET Framework gelöst werden.

Name	Wert
Bereich	Gering
Version	4.5.1
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

ConcurrentQueue<T>.TryPeek kann über einen out-Parameter einen fehlerhaften NULL-Wert zurückgeben

Details

In einigen Multithreaded-Szenarien kann System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) „true“ zurückgeben, aber den Out-Parameter mit einem Nullwert füllen (anstelle des richtigen Werts).

Vorschlag

Dieses Problem wurde in .NET Framework 4.5.1 behoben. Dieses Problem wird durch ein Upgrade auf diese .NET Framework-Version behoben.

name	Wert
Bereich	Hauptversion
Version	4.5
Typ	Laufzeit

Betroffene APIs

• ConcurrentQueue<T>.TryPeek(T)

COR_PRF_GC_ROOT_HANDLE-Elemente werden nicht vom Profiler aufgezählt

Details

In .NET Framework 4.5.1 gibt die Profilerstellungs-API RootReferences2() fälschlicherweise nie COR_PRF_GC_ROOT_HANDLE zurück (stattdessen wird COR_PRF_GC_ROOT_OTHER zurückgegeben). Dieses Problem ist seit .NET Framework 4.6 behoben.

Vorschlag

Dieses Problem wurde in .NET Framework 4.6 behoben und kann durch ein Upgrade auf diese Version von .NET Framework vermieden werden.

name	Wert
Bereich	Gering
Version	4.5.1
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Deserialisierung von Objekten für mehrere Anwendungsdomänen kann einen Fehler auslösen

Details

In einigen Fällen, in denen eine App zwei oder mehr App-Domänen mit unterschiedlichen Anwendungsbasen verwendet, löst der Versuch, Objekte im logischen Aufrufkontext über App-Domänen hinweg zu deserialisieren, eine Ausnahme aus.

Vorschlag

Siehe Entschärfung: Deserialisierung von Objekten über App-Domänen

name	Wert
Bereich	Microsoft Edge
Version	4.5.1
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

EventListener schneidet Zeichenfolgen mit eingebetteten NULL-Werten ab

Details

System.Diagnostics.Tracing.EventListener schneidet Zeichenfolgen mit eingebetteten NULL-Werten ab. NULL-Zeichen werden nicht von der System.Diagnostics.Tracing.EventSource-Klasse unterstützt. Die Änderung betrifft nur Apps, die System.Diagnostics.Tracing.EventListener verwenden, um System.Diagnostics.Tracing.EventSource-Daten im Prozess zu lesen, und die NULL-Zeichen als Trennzeichen verwenden.

Vorschlag

System.Diagnostics.Tracing.EventSource-Daten sollten nach Möglichkeit aktualisiert werden, damit sie keine eingebetteten NULL-Zeichen verwenden.

name	Wert
Bereich	Microsoft Edge
Version	4.5.1
Typ	Laufzeit

Betroffene APIs

• EventListener()
• EventListener.EnableEvents(EventSource, EventLevel)
• EventListener.EnableEvents(EventSource, EventLevel, EventKeywords)
• EventListener.EnableEvents(EventSource, EventLevel, EventKeywords, IDictionary<String,String>)

„EventSource.WriteEvent impls“ muss denselben Parameter (inklusive einer ID) an WriteEvent übergeben, den es erhalten hat

Details

Die Runtime erzwingt jetzt den Vertrag, der Folgendes angibt: Eine Klasse, die von System.Diagnostics.Tracing.EventSource abgeleitet wird und eine ETW-Ereignismethode definiert, muss die EventSource.WriteEvent-Methode der Basisklasse mit der Ereignis-ID, gefolgt von den gleichen Argumenten, die an die ETW-Ereignismethode übergeben wurden, aufrufen.

Vorschlag

Eine System.IndexOutOfRangeException-Ausnahme wird ausgelöst, wenn System.Diagnostics.Tracing.EventListenerSystem.Diagnostics.Tracing.EventSource-Daten im Prozess für eine Ereignisquelle liest, die gegen diesen Vertrag verstößt.

name	Wert
Bereich	Gering
Version	4.5.1
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Marshal.SizeOf- und Marshal.PtrToStructure-Überladungen führen bei dynamischem Code zu Fehlern

Details

Ab .NET Framework 4.5.1 kann das dynamische Binden an die Methoden SizeOf<T>(), SizeOf<T>(T), PtrToStructure(IntPtr, Object),PtrToStructure(IntPtr, Type), PtrToStructure<T>(IntPtr) oder PtrToStructure<T>(IntPtr, T) (z.B. über Windows PowerShell, IronPython oder das C#-Schlüsselwort „dynamic“) zu MethodInvocationExceptions führen, da neue Überladungen dieser Methoden hinzugefügt wurden, die für die Skript-Engines möglicherweise mehrdeutig sind.

Vorschlag

Aktualisieren Sie die Skripts, um eindeutig anzugeben, welche Überladung verwendet werden muss. Dies kann in der Regel dadurch erreicht werden, dass die Typparameter der Methoden explizit zu Type umgewandelt werden. Weitere Informationen und Beispiele zur Problemumgehung finden Sie über diesen Link.

name	Wert
Bereich	Gering
Version	4.5.1
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Einige .NET-APIs führen zu erstmaligen (behandelten) EntryPointNotFoundExceptions

Details

In .NET Framework 4.5 hat eine geringe Anzahl von .NET-Methoden damit begonnen, erstmalige System.EntryPointNotFoundException auszulösen. Diese Ausnahmen wurden in .NET Framework behandelt, konnten aber die Testautomatisierung unterbrechen, die keine erstmaligen Ausnahmen erwartete. Dieselben APIs stören einige ApiVerifier-Szenarien, wenn „HighVersionLie“ aktiviert ist.

Vorschlag

Dieser Fehler kann durch ein Upgrade auf .NET Framework 4.5.1 vermieden werden. Alternativ kann die Testautomatisierung aktualisiert werden, damit keine Störung durch erstmalige System.EntryPointNotFoundException-Ausnahmen erfolgt.

	Wert
Umfang	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• Debug.Assert(Boolean)
• Debug.Assert(Boolean, String)
• Debug.Assert(Boolean, String, String)
• Debug.Assert(Boolean, String, String, Object[])
• XmlSerializer(Type)

WinRT-Streamadapter rufen nicht mehr automatisch FlushAsync auf, wenn sie geschlossen werden

Details

In Windows Store-Apps rufen Windows Runtime-Streamadapter nicht mehr über die Dispose-Methode die FlushAsync-Methode auf.

Vorschlag

Diese Änderung sollte transparent sein. Entwickler können das vorherige Verhalten wiederherstellen, indem sie Code wie den folgenden schreiben:

using (var stream = GetWindowsRuntimeStream() as Stream)
{
// do something
await stream.FlushAsync();
}

name	Wert
Bereich	Transparent
Version	4.5.1
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Daten

ADO.NET versucht nun, unterbrochene SQL-Verbindungen automatisch wiederherzustellen

Details

Ab .NET Framework 4.5.1 versucht .NET Framework, unterbrochene SQL-Verbindungen automatisch wiederherzustellen. Obwohl dies in der Regel dazu führt, dass Apps zuverlässiger werden, gibt es Grenzfälle, in denen eine App wissen muss, dass die Verbindung getrennt wurde, sodass sie bei der Wiederherstellung der Verbindung bestimmte Aktionen ausführen kann.

Vorschlag

Wenn dieses Feature aus Kompatibilitätsgründen nicht erwünscht ist, kann es durch Festlegen der System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount-Eigenschaft einer Verbindungszeichenfolge (oder System.Data.SqlClient.SqlConnectionStringBuilder) auf 0 (null) deaktiviert werden.

name	Wert
Bereich	Microsoft Edge
Version	4.5.1
Typ	Laufzeit

Betroffene APIs

• IDbConnection.ConnectionString
• SqlConnection.ConnectionString
• ConnectionStringSettings.ConnectionString
• DbConnection.ConnectionString
• DbConnectionStringBuilder.ConnectionString
• SqlConnectionStringBuilder()
• SqlConnectionStringBuilder(String)
• DbConnectionStringBuilder()
• DbConnectionStringBuilder(Boolean)

Serialisierung

„NetDataContractSerializer“ kann eine ConcurrentDictionary-Klasse nicht deserialisieren, die mit einer anderen Version von .NET serialisiert wurde

Details

Programmbedingt kann System.Runtime.Serialization.NetDataContractSerializer daher nur verwendet werden, wenn sowohl der Endpunkt für die Serialisierung als auch der Endpunkt für die Deserialisierung den gleichen CLR-Typ aufweisen. Aus diesem Grund wird nicht garantiert, dass ein mit einer Version von .NET Framework serialisiertes Objekt von einer anderen Version deserialisiert werden kann. System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> ist ein Typ, der dafür bekannt ist, nicht korrekt zu deserialisieren, wenn die Objekte mit .NET Framework 4.5 oder niedriger serialisiert und mit .NET Framework 4.5.1 oder höher deserialisiert werden.

Vorschlag

Es gibt einige Möglichkeiten, dieses Problem zu umgehen:

• Führen Sie ein Upgrade durch, sodass der serialisierende Computer ebenfalls .NET Framework 4.5.1 verwendet.
• Verwenden Sie System.Runtime.Serialization.DataContractSerializer statt System.Runtime.Serialization.NetDataContractSerializer, da dadurch nicht genau die gleichen CLR-Typen bei den Endpunkten für die Serialisierung und Deserialisierung erwartet werden.
• Verwenden Sie System.Collections.Generic.Dictionary<TKey,TValue> statt System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue>, da dieses Element nicht die Unterbrechung zwischen 4.5 und 4.5.1 aufweist.

name	Wert
Bereich	Gering
Version	4.5.1
Typ	Laufzeit

Betroffene APIs

• NetDataContractSerializer.Deserialize(Stream)

Windows Communication Foundation (WCF)

MinFreeMemoryPercentageToActiveService wird jetzt eingehalten

Details

Diese Einstellung gibt den minimalen Arbeitsspeicher an, der auf dem Server verfügbar sein muss, bevor ein WCF-Dienst aktiviert werden kann. Sie dient dazu, System.OutOfMemoryException-Ausnahmen zu verhindern. In .NET Framework 4.5 hatte diese Einstellung keine Auswirkung. In .NET Framework 4.5.1 wird die Einstellung beobachtet.

Vorschlag

Eine Ausnahme tritt auf, wenn der auf dem Webserver verfügbare freie Arbeitsspeicher kleiner ist als der Prozentsatz, der in der Konfigurationseinstellung definiert ist. Einige WCF-Dienste, die zuvor erfolgreich in Umgebungen mit eingeschränktem Arbeitsspeicher gestartet und ausgeführt wurden, schlagen jetzt möglicherweise fehl.

name	Wert
Bereich	Gering
Version	4.5.1
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Windows Presentation Foundation (WPF)

Scrollvorgänge in einem WPF-TreeView-Element oder in einem gruppierten ListBox-Element in „VirtualizingStackPanel“ können dazu führen, dass eine Anwendung nicht mehr reagiert.

Details

Das Scrollen für ein WPF-System.Windows.Controls.TreeView-Element in .NET Framework 4.5 in einem virtualisierten StackPanel-Element kann dazu führen, dass die Anwendung nicht mehr reagiert, wenn im Anzeigebereich Ränder vorhanden sind (z. B. zwischen den Elementen in System.Windows.Controls.TreeView oder für ein ItemsPresenter-Element). Darüber hinaus können in einigen Fällen Elemente unterschiedlicher Größe in der Ansicht zur Instabilität führen, auch wenn keine Ränder vorhanden sind.

Vorschlag

Dieser Fehler kann durch ein Upgrade auf .NET Framework 4.5.1 vermieden werden. Alternativ können Ränder aus Ansichtsauflistungen (z.B. mehreren System.Windows.Controls.TreeView-Elementen) in virtualisierten StackPanel-Elementen entfernt werden, wenn alle enthaltenen Elemente dieselbe Größe aufweisen.

name	Wert
Bereich	Hauptversion
Version	4.5
Typ	Laufzeit

Betroffene APIs

• VirtualizingStackPanel.SetIsVirtualizing(DependencyObject, Boolean)

.NET Framework 4.5.2

ASP.NET

ASP.NET MVC versieht jetzt Leerzeichen in Zeichenfolgen, die über Routenparameter übergeben werden, mit Escapezeichen

Details

Um RFC 2396 zu entsprechen, werden Leerzeichen in Routenpfaden jetzt beim Auffüllen der Aktionsparameter von einer Route mit Escapezeichen versehen. Während /controller/action/some data zuvor mit der Route /controller/action/{data} übereinstimmte und some data als Datenparameter bereitgestellt wurde, wird jetzt stattdessen some%20data bereitgestellt.

Vorschlag

Der Code sollte aktualisiert werden, um die Escapezeichen der Zeichenfolgenparameter von einer Route zu entfernen. Wenn der ursprüngliche URI erforderlich ist, kann mithilfe der RequestUri.OriginalString-API darauf zugegriffen werden.

name	Wert
Bereich	Gering
Version	4.5.2
Typ	Laufzeit

Betroffene APIs

• RouteAttribute(String)

EnableViewStateMac kann nicht mehr auf FALSE festgelegt werden

Details

In ASP.NET sind die folgenden Angaben nicht mehr erlaubt: <pages enableViewStateMac=&quot;false&quot;/> oder <@Page EnableViewStateMac=&quot;false&quot; %>. Der Nachrichtenauthentifizierungscode (MAC) des Ansichtszustands wird nun für alle Anfragen mit eingebettetem Ansichtszustand erzwungen. Es sind nur Apps betroffen, die die EnableViewStateMac-Eigenschaft explizit auf false festlegen.

Vorschlag

Für EnableViewStateMac muss TRUE angenommen werden. Zudem müssen alle sich ergebenden MAC-Fehler aufgelöst werden (wie in dieser Anleitung erläutert, die in Abhängigkeit zu den Besonderheiten, die zu den MAC-Fehlern führen, mehrere Lösungen enthält).

name	Wert
Bereich	Hauptversion
Version	4.5.2
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Profilerstellung für ASP.NET MVC4-Apps kann zu schwerwiegendem Fehler der Ausführungs-Engine führen

Details

Profiler, die NGEN- bzw. Profilassemblys verwenden, lösen möglicherweise beim Start von ASP.NET MVC4-Anwendungen mit Profilen einen „schwerwiegenden Fehler der Ausführungs-Engine“ aus

Vorschlag

Dieses Problem wurde in .NET Framework 4.5.2 behoben. Der Profiler kann das Problem jedoch umgehen, indem er COR_PRF_DISABLE_ALL_NGEN_IMAGES in der Ereignismaske angibt.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Daten

SqlConnection.Open schlägt unter Windows 7 mit vorhandenem Nicht-IFS-Winsock-BSP oder -LSP fehl

Details

Auf einem Windows 7-Computer mit einem Nicht-IFS-Winsock-BSP oder -LSP schlagen Open() und OpenAsync(CancellationToken) in .NET Framework 4.5 fehl. Verwenden Sie den Befehl netsh WinSock Show Catalog, und untersuchen Sie alle Winsock Catalog Provider Entry-Elemente, die zurückgegeben werden, um zu erkennen, ob ein Nicht-IFS-Winsock-BSP oder -LSP installiert ist. Wenn für den Servicekennzeichenwert das 0x20000-Bit gesetzt ist, verwendet der Anbieter IFS-Handle und funktioniert daher ordnungsgemäß. Wenn das 0x20000-Bit leer (nicht festgelegt) ist, handelt es sich um ein Nicht-IFS-BSP oder -LSP.

Vorschlag

Dieses Problem wurde in .NET Framework 4.5.2 behoben, daher kann es durch ein Upgrade von .NET Framework vermieden werden. Alternativ kann es durch Entfernen aller installierten Nicht-IFS-Winsock-LSPs vermieden werden.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

• SqlConnection.Open()
• SqlConnection.OpenAsync(CancellationToken)

Entity Framework

Entity Framework löst für QueryViews bei bestimmten Zeichen keine Ausnahmen mehr aus

Details

Entity Framework löst keine System.StackOverflowException-Ausnahme mehr aus, wenn eine App eine Abfrage ausführt, die ein QueryView-Element mit einer 0..1-Navigationseigenschaft umfasst und versucht, die verwandten Entitäten als Teil der Abfrage zu verwenden. (Z.B. durch Aufrufen von .Include(e => e.RelatedNavProp).)

Vorschlag

Diese Änderung betrifft nur Code, der QueryViews mit 1-0..1-Beziehungen verwendet, wenn Abfragen ausgeführt werden, die .Include aufrufen. Diese Änderung verbessert die Zuverlässigkeit und sollte für beinahe alle Apps transparent sein. Falls jedoch ein unerwünschtes Verhalten auftritt, können Sie dieses Feature deaktivieren, indem Sie den folgenden Eintrag im <appSettings>-Bereich der Anwendungskonfigurationsdatei einfügen:

<add key="EntityFramework_SimplifyUserSpecifiedViews" value="false" />

name	Wert
Bereich	Microsoft Edge
Version	4.5.2
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Aktivierte Unterbrechung zur Wiederherstellung der SQL-Generationen 4.0 oder 4.5

Details

Abfragen, die JOIN-Anweisungen erzeugen und einen Aufruf an eine Einschränkungsoperation enthalten, ohne zuvor OrderBy zu verwenden, generieren nun einfacheres SQL. Nach dem Upgrade auf .NET Framework 4.5 generieren diese Abfragen komplizierteres SQL als vorherige Versionen.

Vorschlag

Dieses Feature ist standardmäßig deaktiviert. Wenn Entity Framework zusätzliche JOIN-Anweisungen generiert, die Leistungseinbußen verursachen, können Sie dieses Feature aktivieren, indem Sie den folgenden Eintrag zum <appSettings>-Bereich der Anwendungskonfigurationsdatei (app.config) hinzufügen:

<add key="EntityFramework_SimplifyLimitOperations" value="true" />

name	Wert
Bereich	Transparent
Version	4.5.2
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Windows Presentation Foundation (WPF)

Der Aufruf von DataGrid.CommitEdit über einen CellEditEnding-Handler verliert den Fokus

Details

Wenn das CommitEdit()-Element von einem der System.Windows.Controls.DataGrid.CellEditEnding-Ereignishandler von System.Windows.Controls.DataGrid aufgerufen, verliert System.Windows.Controls.DataGrid den Fokus.

Vorschlag

Dieses Problem wurde in .NET Framework 4.5.2 behoben, daher kann es durch ein Upgrade von .NET Framework vermieden werden. Alternativ kann dies vermieden werden, indem das System.Windows.Controls.DataGrid-Element nach dem Aufruf von System.Windows.Controls.DataGrid.CommitEdit() explizit neu ausgewählt wird.

name	Wert
Bereich	Microsoft Edge
Version	4.5
Typ	Laufzeit

Betroffene APIs

• DataGrid.CommitEdit()
• DataGrid.CommitEdit(DataGridEditingUnit, Boolean)

Das Scrollen zum untersten Eintrag in ItemsControl-Steuerelementen (z.B. ListBox und DataGrid) war bei Verwendung von benutzerdefinierten DataTemplates zeitweilig nicht möglich.

Details

In einigen Fällen verursacht ein Fehler in .NET Framework 4.5, dass ItemsControl-Steuerelemente (z.B. System.Windows.Controls.ListBox, System.Windows.Controls.ComboBox und System.Windows.Controls.DataGrid) nicht zum untersten Eintrag scrollen, wenn benutzerdefinierte DataTemplates verwendet werden. Wenn der Vorgang ein zweites Mal versucht wird (nachdem wieder nach oben gescrollt wurde), funktioniert es entsprechend.

Vorschlag

Dieses Problem wurde in .NET Framework 4.5.2 behoben und kann durch ein Upgrade auf diese (oder eine höhere) Version von .NET Framework vermieden werden. Alternativ können Benutzer weiterhin Scrolleisten in diesen Auflistungen ziehen, wobei sie es möglicherweise zweimal versuchen müssen, bis der Vorgang erfolgreich ausgeführt wird.

name	Wert
Bereich	Gering
Version	4.5
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

WPF erzeugt einen „wiptis.exe“-Prozess, der die Maus sperren kann

Details

Mit Version 4.5.2 wurde ein Problem eingeführt, durch das wisptis.exe erzeugt wird. Hierdurch kann die Mauseingabe gesperrt werden.

Vorschlag

Eine Problembehebung steht in einem Service Release von .NET Framework 4.5.2 (Hotfixrollup 3026376) oder durch ein Upgrade auf .NET Framework 4.6 zur Verfügung.

name	Wert
Bereich	Hauptversion
Version	4.5.2
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

XML

Änderungen an der XML-Analyse

Name	Wert
Bereich	Gering
Version	4.5.2
Typ	Laufzeit

Details

Aus Sicherheitsgründen wurden die folgenden Änderungen in den XML-Analyse-APIs eingeführt:

• XmlReaderSettings.MaxCharactersFromEntities wird auf 10 Millionen festgelegt, wenn XmlReaderSettings initialisiert wird.
• XmlReaderSettings.XmlResolver ist standardmäßig auf null festgelegt.

Hinweis

XmlReaderSettings wird von allen XML-Analysen verwendet. Diese Änderung unterstützt den XmlReader-Fall, wirkt sich aber auch auf andere Szenarios aus.

Vorschlag

Sie können einen Wert in der Registrierung festlegen, um das vorherige Verhalten wiederherzustellen. Fügen Sie einen DWORD-Wert namens EnableLegacyXmlSettings zum Registrierungsschlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\XML hinzu, und legen Sie den Wert auf 1 fest. Sie können den Registrierungswert stattdessen auch im HKEY_CURRENT_USER-Hive hinzufügen.

Betroffene APIs

• System.Xml.XmlReaderSettings.MaxCharactersFromEntities
• System.Xml.XmlReaderSettings.XmlResolver

Darüber hinaus ist jede direkt oder indirekt von XmlResolver abhängige XML-API betroffen.