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
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
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
„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
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
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
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
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
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.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
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 siefalse
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.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
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.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
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
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
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
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
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
„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
„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
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
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
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
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
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
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
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
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
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
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 Elementv
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 aufv
, 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
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
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
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
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
.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
EnableViewStateMac kann nicht mehr auf FALSE festgelegt werden
Details
In ASP.NET sind die folgenden Angaben nicht mehr erlaubt: <pages enableViewStateMac="false"/>
oder <@Page EnableViewStateMac="false" %>
. 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
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
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
Darüber hinaus ist jede direkt oder indirekt von XmlResolver abhängige XML-API betroffen.
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für