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

In diesem Artikel werden App-Kompatibilitätsprobleme aufgeführt, die in .NET Framework 4.6, 4.6.1 und 4.6.2 auftreten.

.NET Framework 4.6

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

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.

AppDomainSetup.DynamicBase wird mithilfe von UseRandomizedStringHashAlgorithm nicht mehr zufällig festgelegt

Details

Vor .NET Framework 4.6 wurde der Wert von DynamicBase für Anwendungsdomänen oder Prozesse zufällig festgelegt, wenn UseRandomizedStringHashAlgorithm in der Konfigurationsdatei der App aktiviert war. Ab .NET Framework 4.6 gibt DynamicBase ein stabiles Ergebnis zurück, das zwischen verschiedenen Instanzen einer ausgeführten App und zwischen verschiedenen App-Domänen besteht. Verschiedene Apps haben auch unterschiedliche dynamische Basen. Diese Änderung entfernt nur die Elemente von verschiedenen Instanzen einer App, die zufällig benannt werden.

Vorschlag

Beachten Sie, dass bei der Aktivierung von UseRandomizedStringHashAlgorithmDynamicBase nicht zufällig festgelegt wird. Wenn eine zufällige Basis benötigt wird, muss diese im Code Ihrer App anstelle einer API erstellt werden.

name	Wert
Bereich	Microsoft Edge
Version	4.6
Typ	Laufzeit

Betroffene APIs

• AppDomainSetup.DynamicBase

Der Aufruf von Attribute.GetCustomAttributes für eine Indexereigenschaft löst keine AmbiguousMatchException-Ausnahme mehr aus, wenn die Mehrdeutigkeit durch den Typ des Indexes aufgelöst werden kann

Details

Vor .NET Framework 4.6 führte der Aufruf von GetCustomAttribute(s) für eine Indexereigenschaft, die sich nur durch den Indextyp von einer anderen Eigenschaft unterschied, zu einer System.Reflection.AmbiguousMatchException. Ab .NET Framework 4.6 werden die Attribute der Eigenschaft ordnungsgemäß zurückgegeben.

Vorschlag

Beachten Sie, dass „GetCustomAttribute(s)“ jetzt häufiger funktioniert. Wenn sich eine App zuvor auf System.Reflection.AmbiguousMatchException verlassen hat, sollte jetzt die Reflektion verwendet werden, um stattdessen explizit nach mehreren Indexern zu suchen.

name	Wert
Bereich	Microsoft Edge
Version	4.6
Typ	Laufzeit

Betroffene APIs

• Attribute.GetCustomAttribute(MemberInfo, Type)
• Attribute.GetCustomAttribute(MemberInfo, Type, Boolean)
• Attribute.GetCustomAttributes(MemberInfo)
• Attribute.GetCustomAttributes(MemberInfo, Boolean)
• Attribute.GetCustomAttributes(MemberInfo, Type)
• Attribute.GetCustomAttributes(MemberInfo, Type, Boolean)
• CustomAttributeExtensions.GetCustomAttribute(MemberInfo, Type)
• CustomAttributeExtensions.GetCustomAttribute(MemberInfo, Type, Boolean)
• CustomAttributeExtensions.GetCustomAttribute<T>(MemberInfo)
• CustomAttributeExtensions.GetCustomAttribute<T>(MemberInfo, Boolean)
• CustomAttributeExtensions.GetCustomAttributes(MemberInfo)
• CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Boolean)
• CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Type)
• CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Type, Boolean)
• CustomAttributeExtensions.GetCustomAttributes<T>(MemberInfo)
• CustomAttributeExtensions.GetCustomAttributes<T>(MemberInfo, Boolean)

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.

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)

Der persische Kalender verwendet jetzt den Hijri-Solaralgorithmus

Details

Ab .NET Framework 4.6 verwendet die System.Globalization.PersianCalendar-Klasse den Hijri-Solaralgorithmus. Das Konvertieren von Datumsangaben zwischen System.Globalization.PersianCalendar und anderen Kalendern erzeugt ab .NET Framework 4.6 für Datumsangaben vor 1800 oder nach 2023 (gregorianisch) möglicherweise ein etwas anderes Ergebnis. Darüber hinaus entspricht PersianCalendar.MinSupportedDateTime nun March 22, 0622 anstatt March 21, 0622.

Vorschlag

Beachten Sie, dass einige frühe oder späte Datumsangaben bei der Verwendung des persischen Kalenders in .NET Framework 4.6 möglicherweise etwas anders aussehen. Speichern Sie zudem beim Serialisieren von Daten zwischen Prozessen, die möglicherweise unter verschiedenen Versionen von .NET Framework ausgeführt werden, die Daten nicht als PersionCalendar-Datumszeichenfolgen (da diese Werte abweichen können).

name	Wert
Bereich	Gering
Version	4.6
Typ	Laufzeit

Betroffene APIs

• System.Globalization.PersianCalendar

Reflection-Objekte können nicht mehr von verwaltetem Code an prozessexterne DCOM-Clients übergeben werden

Details

Reflection-Objekte können nicht mehr von verwaltetem Code an prozessexterne DCOM-Clients übergeben werden. Die folgenden Typen sind betroffen:

• System.Reflection.Assembly
• System.Reflection.MemberInfo (und die abgeleiteten Typen, einschließlich System.Reflection.FieldInfo, System.Reflection.MethodInfo, System.Type und System.Reflection.TypeInfo)
• System.Reflection.MethodBody
• System.Reflection.Module
• System.Reflection.ParameterInfo

Aufrufe von IMarshal für das Objekt geben E_NOINTERFACE zurück.

Vorschlag

Aktualisieren Sie den Marshallingcode, sodass dieser auch mit Nichtreflexionsobjekten funktioniert.

Name	Wert
Bereich	Gering
Version	4.6
Typ	Laufzeit

Betroffene APIs

• System.Reflection.Assembly
• System.Reflection.FieldInfo
• System.Reflection.MemberInfo
• System.Reflection.MethodBody
• System.Reflection.MethodInfo
• System.Reflection.Module
• System.Reflection.ParameterInfo
• System.Reflection.TypeInfo
• System.Type

TargetFrameworkName für die Standardanwendungsdomäne erhält nicht mehr standardmäßig den Wert NULL, wenn kein Wert festgelegt wurde

Details

System.AppDomainSetup.TargetFrameworkName erhielt bereits in der Standardanwendungsdomäne den Wert NULL, sofern kein Wert explizit festgelegt wurde. Ab Version 4.6 weist die System.AppDomainSetup.TargetFrameworkName-Eigenschaft für die Standardanwendungsdomäne einen Standardwert auf, der von TargetFrameworkAttribute (sofern vorhanden) abgeleitet wird. Nicht standardmäßige Anwendungsdomänen erben ihr System.AppDomainSetup.TargetFrameworkName weiterhin von der Standardanwendungsdomäne (die in Version 4.6 nicht standardmäßig auf NULL festgelegt ist), sofern sie nicht explizit außer Kraft gesetzt wird.

Vorschlag

Der Code sollte aktualisiert werden, um nicht davon abhängig zu sein, dass TargetFrameworkName standardmäßig NULL verwendet. Wenn es erforderlich ist, dass diese Eigenschaft weiterhin zu NULL ausgewertet wird, kann dieser Wert explizit festgelegt werden.

name	Wert
Bereich	Microsoft Edge
Version	4.6
Typ	Laufzeit

Betroffene APIs

• AppDomainSetup.TargetFrameworkName

„X509Certificate2.ToString(Boolean)“ wird jetzt nicht mehr ausgelöst, wenn .NET das Zertifikat nicht verarbeiten kann

Details

Zuvor wurde diese Methode in .NET Framework 4.5.2 ausgelöst, wenn true für den ausführlichen Parameter übergeben wurde und Zertifikate installiert waren, die von .NET Framework nicht unterstützt wurden. Nun wird die Methode erfolgreich ausgeführt und gibt eine gültige Zeichenfolge zurück, die die Teile des Zertifikats auslässt, auf die nicht zugegriffen werden kann.

Vorschlag

Jeder von X509Certificate2.ToString(Boolean) abhängige Code sollte aktualisiert werden, um zu erwarten, dass die zurückgegebene Zeichenfolge einige Zertifikatsdaten in einigen Fällen ausschließt (z.B. den öffentlichen Schlüssel, den privaten Schlüssel und die Erweiterungen), in denen zuvor die API ausgelöst worden wäre.

name	Wert
Bereich	Microsoft Edge
Version	4.6
Typ	Laufzeit

Betroffene APIs

• X509Certificate2.ToString(Boolean)

Daten

Der Versuch, eine TCP/IP-Verbindung mit einer SQL Server-Datenbank herzustellen, die zu localhost aufgelöst wird, schlägt fehl

Details

In .NET Framework 4.6 und 4.6.1 tritt beim Versuch, eine TCP/IP-Verbindung mit einer SQL Server-Datenbank herzustellen, die zu localhost aufgelöst wird, der folgende Fehler auf: „Beim Herstellen einer Verbindung mit SQL Server ist ein netzwerkbezogener oder instanzspezifischer Fehler aufgetreten. Der Server wurde nicht gefunden, oder auf ihn kann nicht zugegriffen werden. Stellen Sie sicher, dass der Instanzname richtig und SQL Server so konfiguriert ist, das Remoteverbindungen zulässig sind. (Anbieter: SQL-Netzwerkschnittstellen, Fehler: 26 – Fehler beim Suchen des angegebenen Servers/der angegebenen Instanz.)“

Vorschlag

Dieses Problem wurde behoben und das vorherige Verhalten in .NET Framework 4.6.2 wiederhergestellt. Führen Sie ein Upgrade auf .NET Framework 4.6.2 durch, um eine Verbindung mit einer SQL Server-Datenbank herzustellen, die zu localhost aufgelöst wird.

name	Wert
Bereich	Gering
Version	4.6
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

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.

Netzwerk

Die DateTime-Elemente von „ContentDisposition“ geben eine etwas andere Zeichenfolge zurück

Details

Zeichenfolgendarstellungen von System.Net.Mime.ContentDisposition wurden ab Version 4.6 aktualisiert, um die Stundenkomponente von System.DateTime immer durch zwei Ziffern darzustellen. Dies dient zur Einhaltung von RFC822 und RFC2822. Dies bewirkt, dass ToString() in Version 4.6 eine etwas andere Zeichenfolge in Szenarien zurückgibt, bei denen eines der Zeitelemente der Anordnung vor 10:00 Uhr liegt. Beachten Sie, dass ContentDisposition-Klassen manchmal durch Konvertierung in Zeichenfolgen serialisiert werden, daher sollten alle ToString()-Vorgänge, Serialisierungen oder GetHashCode-Aufrufe überprüft werden.

Vorschlag

Erwarten Sie nicht, dass die Zeichenfolgendarstellungen von „ContentDispositions“ aus verschiedenen Versionen von .NET Framework ordnungsgemäß miteinander verglichen werden können. Konvertieren Sie die Zeichenfolgen wieder in „ContentDispositions“, sofern möglich, bevor Sie einen Vergleich durchführen.

name	Wert
Bereich	Gering
Version	4.6
Typ	Laufzeit

Betroffene APIs

• ContentDisposition.ToString()
• ContentDisposition.GetHashCode()

Serialisierung

Die Ausnahmemeldung für fehlgeschlagene DataContract-Serialisierungen im Fall eines unbekannten Typs hat sich geändert

Details

Ab .NET Framework 4.6 wurde die Fehlermeldung klarer formuliert, die ausgelöst wurde, wenn die Serialisierung oder Deserialisierung von System.Runtime.Serialization.DataContractSerializer oder System.Runtime.Serialization.Json.DataContractJsonSerializer wegen fehlender „bekannter Typen“ fehlschlägt.

Vorschlag

Apps sollten nicht von bestimmten Ausnahmemeldungen abhängig sein. Wenn eine App von dieser Meldung abhängt, aktualisieren Sie diese, damit die neue Meldung erwartet wird. Im besten Fall ändern Sie die App so, dass sie nur vom Ausnahmetyp abhängt.

name	Wert
Bereich	Microsoft Edge
Version	4.6
Typ	Laufzeit

Betroffene APIs

• DataContractJsonSerializer(Type)
• DataContractJsonSerializer(Type, IEnumerable<Type>)
• DataContractJsonSerializer(Type, DataContractJsonSerializerSettings)
• DataContractJsonSerializer(Type, String)
• DataContractJsonSerializer(Type, String, IEnumerable<Type>)
• DataContractJsonSerializer(Type, XmlDictionaryString)
• DataContractJsonSerializer(Type, XmlDictionaryString, IEnumerable<Type>)
• DataContractJsonSerializer(Type, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
• DataContractJsonSerializer(Type, String, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
• DataContractJsonSerializer(Type, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
• DataContractSerializer(Type)
• DataContractSerializer(Type, DataContractSerializerSettings)
• DataContractSerializer(Type, IEnumerable<Type>)
• DataContractSerializer(Type, String, String)
• DataContractSerializer(Type, String, String, IEnumerable<Type>)
• DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString)
• DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>)
• DataContractSerializer(Type, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
• DataContractSerializer(Type, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
• DataContractSerializer(Type, String, String, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
• DataContractSerializer(Type, String, String, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
• DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
• DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)

Setup und Bereitstellung

Änderungen der Produktversionsverwaltung in .NET Framework 4.6 und höher

Details

Die Produktversionsverwaltung wurde gegenüber früheren Releases von .NET Framework geändert, insbesondere gegenüber .NET Framework 4, 4.5, 4.5.1 und 4.5.2. Im Folgenden finden Sie die detaillierten Änderungen:

• Der Wert des Version-Eintrags im HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full-Schlüssel wurde für .NET Framework 4.6 und dessen Punktreleases in 4.6.xxxxx und für .NET Framework 4.7 in und 4.7.1 in 4.7.xxxxx geändert. In .NET Framework 4.5, 4.5.1 und 4.5.2 lautete das Format 4.5.xxxxx.
• Die Datei- und Produktversionsverwaltung für .NET Framework-Dateien wurde vom früheren Schema der Versionsverwaltung von 4.0.30319.x in 4.6.X.0 (für .NET Framework 4.6 und dessen Punktreleases) sowie in 4.7.X.0 (für .NET Framework 4.7 und 4.7.1) geändert. Sie können diese neuen Werte anzeigen, wenn Sie die Eigenschaften der Datei anzeigen, indem Sie mit der rechten Maustaste auf eine Datei klicken.
• Die Attribute AssemblyFileVersionAttribute und AssemblyInformationalVersionAttribute für verwaltete Assemblys verfügen über Versionswerte im Format 4.6.X.0 für .NET Framework 4.6 und die zugehörigen Punktreleases sowie 4.7.X.0 für .NET Framework 4.7 und 4.7.1.
• In .NET Framework 4.6, 4.6.1, 4.6.2, 4.7 und 4.7.1, gibt die Environment.Version-Eigenschaft die korrigierte Versionszeichenfolge 4.0.30319.42000 zurück. In .NET Framework 4, 4.5, 4.5.1 und 4.5.2 hat die Eigenschaft Versionszeichenfolgen im Format 4.0.30319.xxxxx zurückgegeben (z. B. „4.0.30319.18010“). Es wird nicht empfohlen, eine neue Abhängigkeit von der Eigenschaft „Environment.Version“ im Anwendungscode zu verwenden.

Weitere Informationen finden Sie unter Vorgehensweise: Bestimmen der installierten .NET Framework-Versionen.

Vorschlag

Im Allgemeinen sollten Anwendungen von den empfohlenen Verfahren zum Erkennen solcher Faktoren, wie beispielsweise die Laufzeitversion von .NET Framework und das Installationsverzeichnis, abhängen:

• Wie Sie die Laufzeitversion von .NET Framework ermitteln, erfahren Sie unter Gewusst wie: Determine Which .NET Framework Versions Are Installed (Bestimmen der installierten .NET Framework-Versionen).
• Um den Installationspfad für .NET Framework zu ermitteln, verwenden Sie den Wert des InstallPath-Eintrags im HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full Schlüssel.

Wichtig

Der Name des Unterschlüssels ist NET Framework Setup und nicht .NET Framework Setup.

• Um den Verzeichnispfad für die .NET Framework Common Language Runtime zu bestimmen, rufen Sie die RuntimeEnvironment.GetRuntimeDirectory()-Methode auf.
• Um die CLR-Version zu erhalten, rufen Sie die RuntimeEnvironment.GetSystemVersion()-Methode auf. Für .NET Framework 4 und die dazugehörigen Punktreleases (.NET Framework 4.5, 4.5.1, 4.5.2 sowie .NET Framework 4.6, 4.6.1, 4.6.2, 4.7 und 4.7.1) wird die Zeichenfolge „v4.0.30319“ zurückgegeben.

name	Wert
Bereich	Gering
Version	4.6
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

.NET Framework 4.6 verwendet keine 4.5.x.x-Version bei der Registrierung

Details

Der Versionsschlüssel in der Registrierung (unter HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full) für .NET Framework 4.6 beginnt also mit „4.6“. Apps, die von diesen Registrierungsschlüsseln abhängig sind, damit sie wissen, welche .NET Framework-Versionen auf dem Computer installiert sind, sollten aktualisiert werden, sodass sie Version 4.6 als mögliche Version anerkennen, die mit den 4.5.x-Vorgängerversionen kompatibel ist.

Vorschlag

Aktualisieren Sie Apps, die über 4.5-Registrierungsschlüssel nach einer .NET Framework 4.5-Installation suchen, sodass diese auch Version 4.6 akzeptieren.

name	Wert
Bereich	Microsoft Edge
Version	4.6
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Windows Communication Foundation (WCF)

WCF-Dienste, die NETTCP mit SSL-Sicherheit und MD5-Zertifikatauthentifizierung verwenden

Details

.NET Framework 4.6 fügt TLS 1.1 und TLS 1.2 zur WCF-SSL-Standardprotokolliste hinzu. Wenn sowohl auf dem Client- als auch auf dem Servercomputer .NET Framework 4.6 oder höher installiert ist, wird TLS 1.2 für die Aushandlung verwendet. TLS 1.2 unterstützt die MD5-Zertifikatauthentifizierung nicht. Wenn ein Kunde daher ein MD5-Zertifikat verwendet, kann der WCF-Client keine Verbindung mit dem WCF-Dienst herstellen.

Vorschlag

Sie können dieses Problem umgehen, sodass ein WCF-Client eine Verbindung mit einem WCF-Server herstellen kann, indem Sie eine der folgenden Aktionen ausführen:

• Aktualisieren Sie das Zertifikat so, dass der MD5-Algorithmus nicht verwendet wird. Dies ist die empfohlene Lösung.
• Wenn die Bindung im Quellcode nicht dynamisch konfiguriert ist, aktualisieren Sie die Konfigurationsdatei der Anwendung für die Verwendung von TLS 1.1 oder einer früheren Version des Protokolls. Dadurch können Sie weiterhin ein Zertifikat mit MD5-Hashalgorithmus verwenden.

Warnung

Diese Problemumgehung wird nicht empfohlen, da ein Zertifikat mit MD5-Hashalgorithmus als unsicher angesehen wird.

In der folgenden Konfigurationsdatei wird so vorgegangen:

<configuration>
  <system.serviceModel>
    <bindings>
      <netTcpBinding>
        <binding>
          <security mode= "None/Transport/Message/TransportWithMessageCredential" >
            <transport clientCredentialType="None/Windows/Certificate"
                       protectionLevel="None/Sign/EncryptAndSign"
                       sslProtocols="Ssl3/Tls1/Tls11">
            </transport>
          </security>
        </binding>
      </netTcpBinding>
    </bindings>
  </system.ServiceModel>
</configuration>

• Wenn die Bindung im Quellcode dynamisch konfiguriert ist, aktualisieren Sie die TcpTransportSecurity.SslProtocols-Eigenschaft für die Verwendung von TLS 1.1 (SslProtocols.Tls11) oder einer früheren Version des Protokolls im Quellcode.

Warnung

Diese Problemumgehung wird nicht empfohlen, da ein Zertifikat mit MD5-Hashalgorithmus als unsicher angesehen wird.

name	Wert
Bereich	Gering
Version	4.6
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

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()

CoerceIsSelectionBoxHighlighted

Details

Einige Sequenzen von Aktionen, die ein System.Windows.Controls.ComboBox-Element und dessen Datenquelle umfassen, können eine System.NullReferenceException auslösen.

Vorschlag

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

name	Wert
Bereich	Gering
Version	4.6
Typ	Laufzeit

Betroffene APIs

• ComboBox.IsSelectionBoxHighlighted

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)

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()

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.

Die Rechtschreibüberprüfung in textfähigen WPF-Steuerelementen funktioniert unter Windows 10 nicht für die Sprachen, die nicht in der Liste der Eingabesprachen in dem Betriebssystem aufgeführt sind

Details

Bei einem Windows 10-Betriebssystem kann es sein, dass die Rechtschreibüberprüfung für textfähige WPF-Steuerelemente nicht funktioniert, da die plattformspezifischen Funktionen zur Rechtsschreibüberprüfung nur für die Sprachen verfügbar sind, die in der Liste mit den Eingabesprachen aufgeführt sind. Wenn in Windows 10 eine Sprache zu der Liste mit verfügbaren Tastaturen hinzugefügt wird, lädt Windows automatisch ein passendes Feature-On-Demand-Paket herunter, das Funktion zur Rechtschreibüberprüfung enthält, und installiert dieses. Durch das Hinzufügen der Sprache zur Eingabesprachenliste wird die Rechtschreibprüfung unterstützt.

Vorschlag

Beachten Sie, das die Sprache oder der Text, deren bzw. dessen Rechtschreibung überprüft werden muss, als Eingabesprache hinzugefügt werden muss, damit die Rechtschreibüberprüfung in Windows 10 funktioniert.

name	Wert
Bereich	Microsoft Edge
Version	4.6
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

WPF-Fenster werden ohne Clipping gerendert, wenn diese die Größe eines einzelnen Monitors überschreiten

Details

In .NET Framework 4.6, das auf Windows 8 und höher ausgeführt wird, wird das gesamte Fenster ohne Clipping gerendert, wenn es in einem Szenario mit mehreren Monitoren außerhalb einer einzelnen Anzeige liegt. Dies unterscheidet sich von früheren Versionen von .NET Framework, bei denen WPF-Fenster beschnitten werden, die eine einzelne Anzeige überschreiten.

Vorschlag

Dieses Verhalten (ob ein Clipping angewendet wird oder nicht) kann explizit festgelegt werden, indem Sie das <EnableMultiMonitorDisplayClipping>-Element von <appSettings> in der Konfigurationsdatei einer Anwendung verwenden oder indem Sie die EnableMultiMonitorDisplayClipping-Eigenschaft beim Starten der App festlegen.

name	Wert
Bereich	Gering
Version	4.6
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

.NET Framework 4.6.1

Tools

Contract.Invariant oder Contract.Requires<TException> erkennt „String.IsNullOrEmpty“ nicht als reinen Wert an.

Details

Apps für .NET Framework 4.6.1: Wenn der Invariantvertrag für Contract.Invariant oder der Vorbedingungsvertrag für Requires die Methode String.IsNullOrEmpty aufruft, gibt der Rewriter die Compilerwarnung CC1036 aus: „Detected call to method 'System.String.IsNullOrWhteSpace(System.String)' without [Pure] in method“ (Erkannter Aufruf von Methode 'System.String.IsNullOrWhteSpace(System.String)' ohne [Pure] in der Methode). Dies ist eher eine Compilerwarnung als ein Compilerfehler.

Vorschlag

Dieses Verhalten wurde in GitHub-Problem Nr. 339 behandelt. Um diese Warnung zu vermeiden, können Sie eine aktualisierte Version des Quellcodes für das Codevertragstool auf GitHub herunterladen und kompilieren. Informationen zum Herunterladen befinden sich am unteren Rand der Seite.

name	Wert
Bereich	Gering
Version	4.6.1
Typ	Laufzeit

Betroffene APIs

• Contract.Invariant(Boolean)
• Contract.Requires(Boolean)

Windows Presentation Foundation (WPF)

Elementscrolling durch eine flache Liste mit Elementen mit unterschiedlicher Pixelhöhe

Details

Wenn ein System.Windows.Controls.ItemsControl-Element eine Sammlung mithilfe von Virtualisierung (IsVirtualizing=true) und Elementscrolling (ScrollUnit=Item) anzeigt, und wenn das Steuerelement gescrollt wird, um ein Element anzuzeigen, dessen Größe in Pixeln sich von dessen Nachbarn unterscheidet, durchläuft System.Windows.Controls.VirtualizingStackPanel alle Elemente in der Sammlung. Die Benutzeroberfläche reagiert während dieser Iteration nicht. Die Iteration tritt auch in anderen Fällen und selbst in früheren .NET Framework-Releases auf. Sie tritt z.B. beim Scrollen von Pixeln (ScrollUnit=Pixel) auf, nachdem ein Element mit einer anderen Pixelhöhe erkannt wurde sowie beim Elementscrolling für hierarchische Daten (wie beim System.Windows.Controls.TreeView-Steuerelement oder einem System.Windows.Controls.ItemsControl-Element mit aktivierter Gruppierung), nachdem bei einem Element eine andere Anzahl von Nachfolgerelementen als bei seinen Nachbarn erkannt wurde. Im Fall des Elementscrollings bei unterschiedlicher Pixelhöhe wurde die Iteration in .NET Framework 4.6.1 eingeführt, um Fehler im Layout der hierarchischen Daten zu beheben. Dies ist für flache Datenstrukturen (ohne Hierarchie) nicht erforderlich, und .NET Framework 4.6.2 führt die Iteration in diesem Fall nicht aus.

Vorschlag

Wenn die Iteration in .NET Framework 4.6.1, aber nicht in früheren Releases auftritt, also wenn System.Windows.Controls.ItemsControl das Elementscrolling in einer flachen Liste von Elementen mit unterschiedlicher Pixelhöhe durchführt, gibt es zwei Lösungen:

• .NET Framework 4.6.2 installieren
• Hotfix HR 1605 für .NET Framework 4.6.1 installieren

name	Wert
Bereich	Gering
Version	4.6.1
Typ	Laufzeit

Betroffene APIs

• System.Windows.Controls.VirtualizingStackPanel

Von der WPF-Rechtschreibprüfung ausgelöste ObjectDisposedException-Ausnahme

Details

WPF-Anwendungen stürzen beim Beenden der Anwendung gelegentlich ab. Dabei löst die Rechtschreibprüfung die Ausnahme System.ObjectDisposedException aus. Dies wurde in WPF für .NET Framework 4.7 behoben, indem die Ausnahme ordnungsgemäß verarbeitet wird. Dadurch wird sichergestellt, dass die Anwendungen nicht mehr beeinträchtigt werden. Es ist zu beachten, dass auch weiterhin gelegentlich nicht abgefangene Ausnahmen bei Anwendungen auftreten, die unter einem Debugger ausgeführt werden.

Vorschlag

Upgrade auf .NET Framework 4.7

name	Wert
Bereich	Microsoft Edge
Version	4.6.1
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Die WPF-Rechtschreibprüfungs-API schlägt auf unerwartete Weise fehl

Details

Dies umfasst eine Reihe von Problemen mit der WPF-Rechtschreibprüfungs-API:

• Die WPF-Rechtschreibprüfungs-API löst manchmal System.Runtime.InteropServices.COMException aus
• Die WPF-Rechtschreibprüfungs-API schlägt mit der Ausnahme UnauthorizedAccessException fehl, wenn Anwendungen mit der Einstellung „Als anderer Benutzer ausführen“ gestartet werden.
• Die WPF-Rechtschreibprüfungs-API erkennt fälschlicherweise Rechtschreibfehler in zusammengesetzten deutschen Wörtern wie „Hausnummer“.

Vorschlag

Problem 1: wurde in .NET Framework 4.6.2 behoben. Problem 2: Die WPF-Rechtschreibprüfungs-API wird nicht mehr unterstützt, wenn Anwendungen mit der Einstellung „Als anderer Benutzer ausführen“ gestartet werden. Ab .NET Framework 4.6.2 stürzen Anwendungen, die auf diese Weise gestartet werden, nicht mehr unerwartet ab. Stattdessen wird nur die Rechtschreibprüfungs-API im Hintergrund deaktiviert. Problem 3: wurde in .NET Framework 4.6.2 behoben.

name	Wert
Bereich	Microsoft Edge
Version	4.6.1
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

.NET Framework 4.6.2

Daten

Der Versuch, eine TCP/IP-Verbindung mit einer SQL Server-Datenbank herzustellen, die zu localhost aufgelöst wird, schlägt fehl

Details

In .NET Framework 4.6 und 4.6.1 tritt beim Versuch, eine TCP/IP-Verbindung mit einer SQL Server-Datenbank herzustellen, die zu localhost aufgelöst wird, der folgende Fehler auf: „Beim Herstellen einer Verbindung mit SQL Server ist ein netzwerkbezogener oder instanzspezifischer Fehler aufgetreten. Der Server wurde nicht gefunden, oder auf ihn kann nicht zugegriffen werden. Stellen Sie sicher, dass der Instanzname richtig und SQL Server so konfiguriert ist, das Remoteverbindungen zulässig sind. (Anbieter: SQL-Netzwerkschnittstellen, Fehler: 26 – Fehler beim Suchen des angegebenen Servers/der angegebenen Instanz.)“

Vorschlag

Dieses Problem wurde behoben und das vorherige Verhalten in .NET Framework 4.6.2 wiederhergestellt. Führen Sie ein Upgrade auf .NET Framework 4.6.2 durch, um eine Verbindung mit einer SQL Server-Datenbank herzustellen, die zu localhost aufgelöst wird.

name	Wert
Bereich	Gering
Version	4.6
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Die Sperrfrist des Verbindungspools für Azure SQL-Datenbanken wurde entfernt

Details

Ab .NET Framework 4.6.2 werden Fehler bei Anforderungen zum Öffnen von Verbindungen mit bekannten Azure SQL-Datenbanken (*.database.Windows.NET, *.database.chinacloudapi.cn, *.database.usgovcloudapi.net, *.database.cloudapi.de) nicht zwischengespeichert, und die Sperrfrist des Verbindungspools wird entfernt. Wiederholungsversuche von Anforderungen zum Öffnen von Verbindungen erfolgen nahezu unmittelbar nach vorübergehenden Verbindungsfehlern. Diese Änderung ermöglicht die sofortige Wiederholung eines Versuchs zum Öffnen einer Verbindung mit Azure SQL-Datenbanken. Dadurch wird die Leistung von cloudfähigen Apps verbessert. Für alle anderen Verbindungsversuche wird die Sperrfrist für den Verbindungspool weiterhin erzwungen.

Wenn in .NET Framework 4.6.1 und früherer Versionen eine App einen vorübergehender Verbindungsfehler beim Herstellen der Verbindung mit der Datenbank erkennt, kann der Verbindungsversuch nicht schnell wiederholt werden, da der Fehler vom Verbindungspool im Cache gespeichert und 5 Sekunden bis 1 Minute erneut ausgelöst wird. Weitere Informationen finden Sie unter SQL Server-Verbindungspooling (ADO.NET). Dieses Verhalten ist für Verbindungen mit Azure SQL-Datenbanken problematisch, die häufig aufgrund vorübergehender Fehler fehlschlagen, die in der Regel innerhalb weniger Sekunden behoben sind. Das Sperrfeature des Verbindungspools bedeutet, dass die App für einen längeren Zeitraum keine Verbindung mit der Datenbank herstellen kann, obwohl die Datenbank verfügbar ist und die App innerhalb weniger Sekunden rendern muss.

Vorschlag

Wenn dieses Verhalten nicht erwünscht ist, kann die Sperrfrist des Verbindungspools konfiguriert werden, indem die System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod-Eigenschaft festgelegt wird, die in .NET Framework 4.6.2 eingeführt wurde. Der Wert der Eigenschaft ist ein Mitglied der System.Data.SqlClient.PoolBlockingPeriod-Enumeration, die einen von drei Werten annehmen kann:

• AlwaysBlock
• Auto
• NeverBlock

Das vorherige Verhalten kann wiederhergestellt werden, indem Sie die System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod-Eigenschaft auf AlwaysBlock festlegen.

Name	Wert
Bereich	Gering
Version	4.6.2
Typ	Laufzeit

Betroffene APIs

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

Globalisierung

Kategorien der Unicode-Standardversion 8.0 werden jetzt unterstützt

Details

In .NET Framework 4.6.2 ist für Unicode-Daten ein Upgrade von der Unicode-Standardversion 6.3 auf Version 8.0 erfolgt. Wenn Sie Unicode-Zeichenkategorien in .NET Framework 4.6.2 abfragen, entsprechen einige Ergebnisse möglicherweise nicht den Ergebnissen der Vorgängerversionen von .NET Framework. Diese Änderung betrifft hauptsächlich Cherokee-Silben und Neu-Tai-Lue-Vokalzeichen sowie Tonmarkierungen.

Vorschlag

Überprüfen Sie Code, und entfernen oder ändern Sie Logik, die von hartcodierten Unicode-Zeichenkategorien abhängt.

Name	Wert
Bereich	Gering
Version	4.6.2
Typ	Laufzeit

Betroffene APIs

• Char.GetUnicodeCategory(Char)
• CharUnicodeInfo.GetUnicodeCategory(Char)
• CharUnicodeInfo.GetUnicodeCategory(String, Int32)

Sicherheit

„RSACng“ und „DSACng“ sind in Szenarios mit teilweiser Vertrauenswürdigkeit wieder verwendbar

Details

CngLightup (das in einigen Krypto-APIs auf höherer Ebene verwendet wird, z.B. System.Security.Cryptography.Xml.EncryptedXml) und System.Security.Cryptography.RSACng erfordern in einigen Fällen volles Vertrauen. Dazu zählen P/Invoke-Aufrufe ohne gewährte SecurityPermissionFlag.UnmanagedCode-Berechtigungen sowie Codepfade, bei denen System.Security.Cryptography.CngKey eine Berechtigungsanforderung für SecurityPermissionFlag.UnmanagedCode aufweist. Ab .NET Framework 4.6.2 wurde „CngLightup“ verwendet, um nach Möglichkeit zu System.Security.Cryptography.RSACng zu wechseln. In Folge schlugen teilweise vertrauenswürdige Apps fehl, die System.Security.Cryptography.Xml.EncryptedXml erfolgreich verwendeten, und lösten SecurityException-Ausnahmen aus. Durch diese Änderungen werden die erforderlichen Berechtigungen hinzugefügt, sodass alle Funktionen, die „CngLightup“ verwenden, über die erforderlichen Berechtigungen verfügen.

Vorschlag

Wenn diese Änderung in .NET Framework 4.6.2 sich negativ auf Ihre teilweise vertrauenswürdigen Apps ausgewirkt hat, führen Sie ein Upgrade auf .NET Framework 4.7.1 durch.

Name	Wert
Bereich	Microsoft Edge
Version	4.6.2
Typ	Laufzeit

Betroffene APIs

• DSACng(CngKey)
• DSACng.Key
• DSACng.LegalKeySizes
• DSACng.CreateSignature(Byte[])
• DSACng.VerifySignature(Byte[], Byte[])
• RSACng(CngKey)
• RSACng.Key
• RSACng.Decrypt(Byte[], RSAEncryptionPadding)
• RSACng.SignHash(Byte[], HashAlgorithmName, RSASignaturePadding)

RSACng.VerifyHash gibt nun FALSE für alle Überprüfungsfehler zurück

Details

Ab .NET Framework 4.6.2 gibt diese Methode FALSE zurück, wenn die Signatur selbst ein ungültiges Format aufweist. Sie gibt nun für jeden Überprüfungsfehler FALSE zurück. In .NET Framework 4.6 und 4.6.1 löst diese Methode die Ausnahme System.Security.Cryptography.CryptographicException aus, wenn die Signatur selbst falsch formatiert ist.

Vorschlag

Jeder Code, dessen Ausführung von der Behandlung der System.Security.Cryptography.CryptographicException-Ausnahme abhängt, sollte stattdessen ausgeführt werden, wenn ein Validierungsfehler auftritt und die Methode FALSE zurückgibt.

Name	Wert
Bereich	Gering
Version	4.6.2
Typ	Laufzeit

Betroffene APIs

• RSACng.VerifyHash(Byte[], Byte[], HashAlgorithmName, RSASignaturePadding)

Breaking Changes bei SignedXml und EncryptedXml

Details

In .NET Framework 4.6.2 führen geschlossene Sicherheitslücken in System.Security.Cryptography.Xml.SignedXml und System.Security.Cryptography.Xml.EncryptedXml zu Änderungen des Laufzeitverhaltens. Beispiel:

• Wenn ein Dokument mehrere Elemente mit demselben id-Attribut enthält und eine Signatur auf eins dieser Elemente als Signaturstamm ausgerichtet ist, wird das Dokument als gültig markiert.
• Dokumente, die nicht kanonische Transformationsalgorithmen für XPath in Verweisen verwenden, gelten jetzt als gültig.
• Dokumente, die nicht kanonische Transformationsalgorithmen für XSLT in Verweisen verwenden, gelten jetzt als ungültig.
• Programme können keine externen von Ressourcen getrennte Signaturen verwenden.

Vorschlag

Entwickler sollten die Verwendung von XmlDsigXsltTransform und XmlDsigXsltTransform sowie von von Transform abgeleiteten Typen prüfen, da ein Dokumentempfänger sie möglicherweise nicht verarbeiten kann.

Name	Wert
Bereich	Gering
Version	4.6.2
Typ	Laufzeit

Betroffene APIs

• System.Security.Cryptography.Xml.Transform
• System.Security.Cryptography.Xml.XmlDsigXPathTransform
• System.Security.Cryptography.Xml.XmlDsigXsltTransform

Windows Communication Foundation (WCF)

Entfernen von „Ssl3“ aus der WCF-Klasse „TransportDefaults“

Details

Bei der Verwendung von NetTcp im Transportsicherheitsmodus und der Einstellung „Zertifikat“ wird das SSL3-Protokoll nicht mehr als eins der Standardprotokolle für das Aushandeln einer sicheren Verbindung verwendet. In den meisten Fällen sollte es keine Auswirkungen auf vorhandene Apps geben, da TLS 1.0 schon immer in der Protokollliste für „NetTcp“ enthalten ist. Alle vorhandenen Clients sollten in der Lage sein, eine Verbindung mit mindestens TLS 1.0 auszuhandeln.

Vorschlag

Wenn Ssl3 erforderlich ist, verwenden Sie eine der folgenden Konfigurationsmechanismen, um Ssl3 der Liste der ausgehandelten Protokolle hinzuzufügen.

• SslProtocols
• SslProtocols
• <transport> von <netTcpBinding>
• <sslStreamSecurity>

Name	Wert
Bereich	Microsoft Edge
Version	4.6.2
Typ	Laufzeit

Betroffene APIs

• SslStreamSecurityBindingElement.SslProtocols
• TcpTransportSecurity.SslProtocols

Windows Presentation Foundation (WPF)

Das Ändern der IsEnabled-Eigenschaft des übergeordneten Elements eines TextBlock-Steuerelements wirkt sich auf alle untergeordneten Steuerelemente aus

Details

Ab .NET Framework 4.6.2 wirkt sich das Ändern der System.Windows.UIElement.IsEnabled-Eigenschaft eines übergeordneten Elements eines System.Windows.Controls.TextBlock-Steuerelements auf alle untergeordneten Steuerelemente (z.B. Links und Schaltflächen) des System.Windows.Controls.TextBlock-Steuerelements aus. In .NET Framework 4.6.1 und früher zeigten Steuerelemente innerhalb von System.Windows.Controls.TextBlock nicht immer den Status der System.Windows.UIElement.IsEnabled-Eigenschaft des übergeordneten System.Windows.Controls.TextBlock-Elements an.

Vorschlag

Keine. Diese Änderung entspricht dem erwarteten Verhalten für Steuerelemente innerhalb eines System.Windows.Controls.TextBlock-Steuerelements.

Name	Wert
Bereich	Gering
Version	4.6.2
Typ	Laufzeit

Betroffene APIs

• UIElement.IsEnabled

CoerceIsSelectionBoxHighlighted

Details

Einige Sequenzen von Aktionen, die ein System.Windows.Controls.ComboBox-Element und dessen Datenquelle umfassen, können eine System.NullReferenceException auslösen.

Vorschlag

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

name	Wert
Bereich	Gering
Version	4.6
Typ	Laufzeit

Betroffene APIs

• ComboBox.IsSelectionBoxHighlighted

DataGridCellsPanel.BringIndexIntoView löst ArgumentOutOfRangeException aus

Details

ScrollIntoView(Object) wird asynchron ausgeführt, wenn die Spaltenvirtualisierung zwar aktiviert ist, die Spaltenbreiten aber noch nicht festgelegt wurden. Wenn Spalten entfernt werden, bevor der asynchrone Vorgang abgeschlossen ist, kann eine System.ArgumentOutOfRangeException-Ausnahme auftreten.

Vorschlag

Führen Sie eine der folgenden Aktionen aus:

• Upgrade auf .NET Framework 4.7
• Den neuesten Wartungspatch für .NET Framework 4.6.2 installieren
• Entfernen Sie Spalten erst, wenn die asynchrone Antwort auf die ScrollIntoView(Object) abgeschlossen wurde.

Name	Wert
Bereich	Microsoft Edge
Version	4.6.2
Typ	Laufzeit

Betroffene APIs

• DataGrid.ScrollIntoView(Object)
• DataGrid.ScrollIntoView(Object, DataGridColumn)

Horizontales Scrollen und Virtualisierung

Details

Diese Änderung betrifft System.Windows.Controls.ItemsControl-Objekte mit eigener Virtualisierung in der senkrecht zur Hauptscrollrichtung stehenden Richtung (z. B. System.Windows.Controls.DataGrid mit EnableColumnVirtualization="True"). Das Ergebnis bestimmter horizontaler Scrollvorgänge wurde geändert, um Ergebnisse zu erzeugen, die intuitiver und in höheren Maß analog zu den Ergebnissen vergleichbarer vertikaler Vorgänge sind.

Zu den Vorgängen gehören „Bildlauf hierhin durchführen“ und „Rechter Rand“, um die Namen aus dem Menü zu verwenden, das durch Klicken mit der rechten Maustaste auf eine horizontale Scrollleiste angezeigt wird. Beide berechnen einen Kandidatenoffset und rufen SetHorizontalOffset(Double) auf.

Nach dem Scrollen zum neuen Offset hat sich die Definition von „Hier“ oder „Rechter Rand“ möglicherweise geändert, da die neuen entvirtualisierten Inhalte den Wert von System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth geändert haben.

Vor .NET Framework 4.6.2 verwendet der Scrollvorgang einfach den Kandidatenoffset, obwohl er möglicherweise nicht mehr „Hier“ oder „Rechter Rand“ entspricht. Dies führt zu Effekten wie einem „Springen“ des Leistenziehpunkts, die sich am besten durch ein Beispiel veranschaulichen lassen. Nehmen Sie an, dass System.Windows.Controls.DataGrid über die Eigenschaften „ExtentWidth=1000“ und „Width=200“ verfügt. Ein Scrollen zu „Rechter Rand“ verwendet den Kandidatenoffset 1000 - 200 = 800. Beim Scrollen zu diesem Offset werden neue Spalten entvirtualisiert. Nehmen Sie an, dass diese sehr breit sind, sodass sich System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth in 2000 ändert. Das Scrollen endet bei HorizontalOffset=800, und der Ziehpunkt „springt“ annähernd zur Mitte der Bildlaufleiste zurück – genau bei 800:2000 = 40 %.

Die Änderung besteht darin, einen neuen Kandidatenoffset zu berechnen, wenn diese Situation eintritt, und es erneut zu versuchen. (Beim vertikalen Scrollen wurde dies bereits implementiert.)

Die Änderung ergibt ein besser vorhersehbares und intuitiveres Verhalten für den Endbenutzer, sie kann sich aber auf jede App auswirken, die auf den genauen Wert von System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset nach einem horizontalen Scrollvorgang angewiesen ist, ob vom Endbenutzer oder durch einen expliziten Aufruf von SetHorizontalOffset(Double) aufgerufen.

Vorschlag

Eine App, die einen vorhergesagten Wert für System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset verwendet, sollte so geändert werden, dass sie nach jedem horizontalen Scrollen, durch das System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth aufgrund der Entvirtualisierung geändert werden könnte, den tatsächlichen Wert (und den Wert von System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth) abruft.

Name	Wert
Bereich	Gering
Version	4.6.2
Typ	Laufzeit

Betroffene APIs

• System.Windows.Controls.Primitives.IScrollInfo

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

Elementscrolling durch eine flache Liste mit Elementen mit unterschiedlicher Pixelhöhe

Details

Wenn ein System.Windows.Controls.ItemsControl-Element eine Sammlung mithilfe von Virtualisierung (IsVirtualizing=true) und Elementscrolling (ScrollUnit=Item) anzeigt, und wenn das Steuerelement gescrollt wird, um ein Element anzuzeigen, dessen Größe in Pixeln sich von dessen Nachbarn unterscheidet, durchläuft System.Windows.Controls.VirtualizingStackPanel alle Elemente in der Sammlung. Die Benutzeroberfläche reagiert während dieser Iteration nicht. Die Iteration tritt auch in anderen Fällen und selbst in früheren .NET Framework-Releases auf. Sie tritt z.B. beim Scrollen von Pixeln (ScrollUnit=Pixel) auf, nachdem ein Element mit einer anderen Pixelhöhe erkannt wurde sowie beim Elementscrolling für hierarchische Daten (wie beim System.Windows.Controls.TreeView-Steuerelement oder einem System.Windows.Controls.ItemsControl-Element mit aktivierter Gruppierung), nachdem bei einem Element eine andere Anzahl von Nachfolgerelementen als bei seinen Nachbarn erkannt wurde. Im Fall des Elementscrollings bei unterschiedlicher Pixelhöhe wurde die Iteration in .NET Framework 4.6.1 eingeführt, um Fehler im Layout der hierarchischen Daten zu beheben. Dies ist für flache Datenstrukturen (ohne Hierarchie) nicht erforderlich, und .NET Framework 4.6.2 führt die Iteration in diesem Fall nicht aus.

Vorschlag

Wenn die Iteration in .NET Framework 4.6.1, aber nicht in früheren Releases auftritt, also wenn System.Windows.Controls.ItemsControl das Elementscrolling in einer flachen Liste von Elementen mit unterschiedlicher Pixelhöhe durchführt, gibt es zwei Lösungen:

• .NET Framework 4.6.2 installieren
• Hotfix HR 1605 für .NET Framework 4.6.1 installieren

name	Wert
Bereich	Gering
Version	4.6.1
Typ	Laufzeit

Betroffene APIs

• System.Windows.Controls.VirtualizingStackPanel

In lokalisierten Builds ist der RibbonGroup-Hintergrund auf transparent festgelegt

Details

Der System.Windows.Controls.Ribbon.RibbonGroup-Hintergrund wurde in lokalisierten Builds stets mit einem Pinsel für Transparenzeffekte gezeichnet, was zu einer wenig ansprechenden Benutzeroberfläche führte. Dieses Problem wurde in der .NET Framework 4.7 WPF-Fehlerbehebung behoben, indem die lokalisierten Ressourcen für System.Windows.Controls.Ribbon.RibbonGroup aktualisiert wurden, wodurch sichergestellt wird, dass der richtige Pinsel ausgewählt wird.

Vorschlag

Upgrade auf .NET Framework 4.7

name	Wert
Bereich	Microsoft Edge
Version	4.6.2
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.

Die WPF-Rechtschreibprüfungs-API schlägt auf unerwartete Weise fehl

Details

Dies umfasst eine Reihe von Problemen mit der WPF-Rechtschreibprüfungs-API:

• Die WPF-Rechtschreibprüfungs-API löst manchmal System.Runtime.InteropServices.COMException aus
• Die WPF-Rechtschreibprüfungs-API schlägt mit der Ausnahme UnauthorizedAccessException fehl, wenn Anwendungen mit der Einstellung „Als anderer Benutzer ausführen“ gestartet werden.
• Die WPF-Rechtschreibprüfungs-API erkennt fälschlicherweise Rechtschreibfehler in zusammengesetzten deutschen Wörtern wie „Hausnummer“.

Vorschlag

Problem 1: wurde in .NET Framework 4.6.2 behoben. Problem 2: Die WPF-Rechtschreibprüfungs-API wird nicht mehr unterstützt, wenn Anwendungen mit der Einstellung „Als anderer Benutzer ausführen“ gestartet werden. Ab .NET Framework 4.6.2 stürzen Anwendungen, die auf diese Weise gestartet werden, nicht mehr unerwartet ab. Stattdessen wird nur die Rechtschreibprüfungs-API im Hintergrund deaktiviert. Problem 3: wurde in .NET Framework 4.6.2 behoben.

name	Wert
Bereich	Microsoft Edge
Version	4.6.1
Typ	Laufzeit

Betroffene APIs

Nicht über API-Analyse erkennbar.