Neuzuweisung von Änderungen für die Migration von .NET Framework 4.6.2 zu 4.7

Wenn Sie von .NET Framework 4.6.2 zu 4.7 migrieren, finden Sie in folgenden Themen weitere Informationen zu den Anwendungskompatibilitätsproblemen, die sich möglicherweise auf Ihre App auswirken können:

ASP.NET

HttpRuntime.AppDomainAppPath löst NullReferenceException aus

Details

In .NET Framework 4.6.2 löst die Laufzeit T:System.NullReferenceException aus, wenn ein P:System.Web.HttpRuntime.AppDomainAppPath-Wert abgerufen wird, der NULL-Zeichen enthält. In .NET Framework 4.6.1 und früheren Versionen löst die Laufzeit eine T:System.ArgumentNullException aus.

Vorschlag

Sie können mit einer der folgenden Möglichkeiten auf diese Änderung reagieren:

  • Behandeln Sie die T:System.NullReferenceException, wenn Ihre Anwendung in .NET Framework 4.6.2 ausgeführt wird.
  • Führen Sie ein Upgrade auf .NET Framework 4.7 durch, sodass das vorherige Verhalten wiederhergestellt und eine T:System.ArgumentNullException ausgelöst wird.
name Wert
Bereich Microsoft Edge
Version 4.6.2
Typ Neuzuweisung

Betroffene APIs

Einschränken von gleichzeitigen Anforderungen pro Sitzung

Details

In .NET Framework 4.6.2 und früheren Versionen führt ASP.NET Anforderungen mit der gleichen SessionID sequentiell durch, und ASP.NET stellt die SessionID standardmäßig über Cookies aus. Wenn eine Seite zum Reagieren viel Zeit in Anspruch nimmt, wird die Serverleistung allein durch Drücken von F5 im Browser erheblich eingeschränkt. Mit der Fehlerbehebung verfolgt ein Zähler die in die Warteschlange eingestellten Anforderungen nach und beendet die Anforderungen, wenn sie einen angegebenen Grenzwert überschreiten. Der Standardwert ist 50. Wenn der Grenzwert erreicht wird, wird eine Warnung in das Ereignisprotokoll geschrieben, und möglicherweise wird eine HTTP 500-Antwort im IIS-Protokoll aufgezeichnet.

Vorschlag

Um das alte Verhalten wiederherzustellen, können Sie Ihrer web.config-Datei die folgende Einstellung hinzufügen, um sich gegen das neue Verhalten zu entscheiden.

<appSettings>
    <add key="aspnet:RequestQueueLimitPerSession" value="2147483647"/>
</appSettings>
name Wert
Bereich Microsoft Edge
Version 4.7
Typ Neuzuweisung

Netzwerk

Der Standardwert von ServicePointManager.SecurityProtocol ist SecurityProtocolType.System.Default

Details

Bei Apps mit der Zielplattform .NET Framework 4.7 und höher ist der Standardwert der ServicePointManager.SecurityProtocol-Eigenschaft SecurityProtocolType.SystemDefault. Diese Änderungen ermöglicht den Netzwerk-APIs von .NET Framework, die auf SslStream (z.B. FTP, HTTPS und SMTP) basieren, die Standardsicherheitsprotokolle des Betriebssystems zu erben, anstatt hartcodierte Werte zu verwenden, die von .NET Framework definiert werden. Der Standard variiert je nach Betriebssystem und sämtlichen benutzerdefinierten Konfigurationen, die vom Systemadministrator vorgenommen werden. Informationen zum standardmäßigen SChannel-Protokoll in der jeweiligen Version des Windows-Betriebssystems finden Sie unter Protokolle in TLS/SSL (SChannel SSP).

Bei Anwendungen, die auf eine frühere Version des .NET-Frameworks ausgelegt sind, hängt der Standardwert der ServicePointManager.SecurityProtocol-Eigenschaft von der .NET Framework-Zielversion ab. Weitere Informationen finden Sie im Abschnitt „Netzwerk“ des Artikels „Neuzuweisung von Änderungen für die Migration von .NET Framework 4.5.2 zu 4.6“.

Vorschlag

Diese Änderung betrifft nur Anwendungen, die auf .NET Framework 4.7 oder höher ausgelegt sind. Wenn Sie lieber ein definiertes Protokoll anstelle des Systemstandards verwenden möchten, können Sie den Wert der ServicePointManager.SecurityProtocol-Eigenschaft explizit festlegen. Wenn diese Änderung nicht erwünscht ist, können Sie sie deaktivieren, indem Sie dem <Laufzeitabschnitt> Ihrer Anwendungskonfigurationsdatei eine Konfigurationseinstellung hinzufügen. Im folgenden Beispiel sind sowohl der Abschnitt <runtime> als auch die Ablehnungsoption Switch.System.Net.DontEnableSystemDefaultTlsVersions dargestellt:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=true" />
</runtime>
name Wert
Bereich Gering
Version 4.7
Typ Neuzuweisung

Betroffene APIs

SslStream unterstützt TLS-Warnungen

Details

Nach einem fehlgeschlagenen TLS-Handshake wird eine System.IO.IOException mit einer inneren System.ComponentModel.Win32Exception von dem ersten E/A-Lese-/Schreibvorgang ausgelöst. Der System.ComponentModel.Win32Exception.NativeErrorCode-Code für die System.ComponentModel.Win32Exception kann der TLS-Warnung von der Remotepartei mit den Schannel-Fehlercodes für TLS- und SSL-Warnungen zugeordnet werden. Weitere Informationen finden Sie unter RFC 2246: Abschnitt 7.2.2, Fehlerwarnungen.
Das Verhalten in .NET Framework 4.6.2 und früheren Versionen besteht darin, dass für den Transportkanal (in der Regel eine TCP-Verbindung) ein Timeout während des Schreib- oder Lesevorgangs auftritt, wenn beim Handshake bei der anderen Partei ein Fehler aufgetreten ist und die Verbindung unmittelbar danach zurückgewiesen wurde.

Vorschlag

Anwendungen, die Netzwerk-E/A-APIs aufrufen (z.B. Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32)) sollten IOException oder System.TimeoutException verarbeiten.
Die TLS-Warnfunktion ist ab .NET Framework 4.7 standardmäßig aktiviert. Für Anwendungen für Versionen von .NET Framework von 4.0 bis 4.6.2, die auf einem System mit .NET Framework 4.7 oder höher ausgeführt werden, ist diese Funktion deaktiviert, um die Kompatibilität zu erhalten.
Die folgende Konfigurations-API ist zum Aktivieren oder Deaktivieren des Features für .NET Framework 4.6- oder höhere Anwendungen, die unter .NET Framework 4.7 oder höher ausgeführt werden, verfügbar.

  • Programmgesteuert: Muss das erste sein, was die Anwendung tut, da ServicePointManager nur einmal initialisiert wird:

    AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true);
    
    // Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2.
    AppContext.SetSwitch("Switch.System.Net.DontEnableTlsAlerts", true);
    
  • AppConfig:

    <runtime>
      <AppContextSwitchOverrides value="Switch.System.Net.DontEnableTlsAlerts=true"/>
      <!-- Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. -->
    </runtime>
    
  • Registrierungsschlüssel (computer global): Legen Sie den Wert auf festfalse, um das Feature in .NET Framework 4.6 bis 4.6.2 zu aktivieren.

    Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts
    - Type: String
    - Value: "true"
    
name Wert
Bereich Microsoft Edge
Version 4.7
Typ Neuzuweisung

Betroffene APIs

Sicherheit

CspParameters.ParentWindowHandle erwartet nun einen HWND-Wert

Details

Der ParentWindowHandle-Wert, der in .NET Framework 2.0 eingeführt wurde, ermöglicht einer Anwendung die Registrierung eines Handlewerts für das übergeordnete Fenster, sodass jedes Benutzeroberflächenelement, das auf den Schlüssel zugreifen muss (wie etwa eine PIN-Eingabeaufforderung oder ein Zustimmungsdialogfeld), als untergeordnetes modales Fenster des angegebenen Fensters geöffnet wird. Für eine Windows Forms-App, deren Zielplattform .NET Framework 4.7 oder höher ist, kann die Eigenschaft ParentWindowHandle beispielsweise mit dem folgenden Code festgelegt werden:

cspParameters.ParentWindowHandle = form.Handle;

In früheren Versionen von .NET Framework wurde erwartet, dass der Wert ein System.IntPtr-Objekt ist, das einen Speicherort im Arbeitsspeicher darstellt, an dem sich der HWND-Wert befindet. Festlegen der -Eigenschaft auf form. Handle für Windows 7 und frühere Versionen hatte keine Auswirkungen, aber auf Windows 8 und höhere Versionen führt dies zu einem "System.Security.Cryptography.CryptographicException: Der Parameter ist falsch."

Vorschlag

Für Apps mit der Zielplattform .NET Framework 4.7 oder höher, die eine übergeordnete Fensterbeziehung registrieren sollen, wird die Verwendung eines vereinfachten Formulars wie dem folgenden empfohlen:

cspParameters.ParentWindowHandle = form.Handle;

Einige Benutzer haben erkannt, dass der richtige zu übergebende Wert die Adresse eines Speicherorts im Arbeitsspeicher war, der den Wert form.Handle enthielt. Benutzer können sich gegen dieses geänderte Verhalten entscheiden, indem sie die AppContext-Option Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle auf true festlegen. Dies kann

  • durch programmgesteuertes Festlegen von Kompatibilitätsoptionen für AppContext, wie hier beschrieben wird,
  • Durch Hinzufügen der folgenden Zeile zum Abschnitt <runtime> der app.config-Datei:
<runtime>
 <AppContextSwitchOverrides value="Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle=true"/>
</runtime>

Benutzer, die sich umgekehrt für das neue Verhalten der Laufzeit von .NET Framework 4.7 entscheiden, können die AppContext-Option auf false festlegen, wenn die Anwendung in älteren Versionen von .NET Framework geladen wird.

name Wert
Bereich Gering
Version 4.7
Typ Neuzuweisung

Betroffene APIs

SslStream unterstützt TLS-Warnungen

Details

Nach einem fehlgeschlagenen TLS-Handshake wird eine System.IO.IOException mit einer inneren System.ComponentModel.Win32Exception von dem ersten E/A-Lese-/Schreibvorgang ausgelöst. Der System.ComponentModel.Win32Exception.NativeErrorCode-Code für die System.ComponentModel.Win32Exception kann der TLS-Warnung von der Remotepartei mit den Schannel-Fehlercodes für TLS- und SSL-Warnungen zugeordnet werden. Weitere Informationen finden Sie unter RFC 2246: Abschnitt 7.2.2, Fehlerwarnungen.
Das Verhalten in .NET Framework 4.6.2 und früheren Versionen besteht darin, dass für den Transportkanal (in der Regel eine TCP-Verbindung) ein Timeout während des Schreib- oder Lesevorgangs auftritt, wenn beim Handshake bei der anderen Partei ein Fehler aufgetreten ist und die Verbindung unmittelbar danach zurückgewiesen wurde.

Vorschlag

Anwendungen, die Netzwerk-E/A-APIs aufrufen (z.B. Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32)) sollten IOException oder System.TimeoutException verarbeiten.
Die TLS-Warnfunktion ist ab .NET Framework 4.7 standardmäßig aktiviert. Für Anwendungen für Versionen von .NET Framework von 4.0 bis 4.6.2, die auf einem System mit .NET Framework 4.7 oder höher ausgeführt werden, ist diese Funktion deaktiviert, um die Kompatibilität zu erhalten.
Die folgende Konfigurations-API ist zum Aktivieren oder Deaktivieren des Features für .NET Framework 4.6- oder höhere Anwendungen, die unter .NET Framework 4.7 oder höher ausgeführt werden, verfügbar.

  • Programmgesteuert: Muss das erste sein, was die Anwendung tut, da ServicePointManager nur einmal initialisiert wird:

    AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true);
    
    // Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2.
    AppContext.SetSwitch("Switch.System.Net.DontEnableTlsAlerts", true);
    
  • AppConfig:

    <runtime>
      <AppContextSwitchOverrides value="Switch.System.Net.DontEnableTlsAlerts=true"/>
      <!-- Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. -->
    </runtime>
    
  • Registrierungsschlüssel (computer global): Legen Sie den Wert auf festfalse, um das Feature in .NET Framework 4.6 bis 4.6.2 zu aktivieren.

    Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts
    - Type: String
    - Value: "true"
    
name Wert
Bereich Microsoft Edge
Version 4.7
Typ Neuzuweisung

Betroffene APIs

Windows Communication Foundation (WCF)

Die Serialisierung von Steuerzeichen in DataContractJsonSerializer ist jetzt konform mit ECMAScript V6 und V8

Details

In .NET Framework 4.6.2 und früheren Versionen serialisierte System.Runtime.Serialization.Json.DataContractJsonSerializer einige besondere Steuerzeichen, wie etwa \b, \f und \t nicht in einer Weise, die mit den Standards ECMAScript V6 und V8 kompatibel ist. Ab .NET Framework 4.7 ist die Serialisierung dieser Steuerzeichen mit ECMAScript V6 und V8 kompatibel.

Vorschlag

Standardmäßig wird dieses neue Feature nur für Apps aktiviert, die für .NET Framework 4.7 konzipiert sind. Wenn dieses Verhalten unerwünscht ist, können Sie sich gegen diese Funktion entscheiden, indem Sie dem Abschnitt <runtime> der app.config- oder web.config-Datei die folgende Zeile hinzufügen:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseECMAScriptV6EscapeControlCharacter=false" />
</runtime>
name Wert
Bereich Microsoft Edge
Version 4.7
Typ Neuzuweisung

Betroffene APIs

WCF-Nachrichtensicherheit kann jetzt TLS1.1 und TLS1.2 verwenden

Details

Ab .NET Framework 4.7 können Kunden über die Anwendungskonfigurationseinstellungen neben SSL3.0 und TLS1.0 entweder TLS1.1 oder TLS1.2 in WCF-Nachrichtensicherheit konfigurieren.

Vorschlag

In .NET Framework 4.7 werden TLS1.1 und TLS1.2 in WCF-Nachrichtensicherheit standardmäßig nicht unterstützt. Sie können die Unterstützung aktivieren, indem Sie die folgende Zeile zum Abschnitt <runtime> der app.config- oder der web.config-Datei hinzufügen:

<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>
name Wert
Bereich Microsoft Edge
Version 4.7
Typ Neuzuweisung

Windows Presentation Foundation (WPF)

Aufrufe von System.Windows.Input.PenContext.Disable auf touchfähigen Systemen können eine ArgumentException auslösen

Details

Unter bestimmten Umständen können Aufrufe der internen Methode System.Windows.Intput.PenContext.Disable auf touchfähigen Systemen eine nicht behandelte T:System.ArgumentException aufgrund von Eintrittsinvarianz auslösen.

Vorschlag

Dieses Problem wurde in .NET Framework 4.7 behoben. Führen Sie ein Upgrade auf .NET Framework 4.7 oder höher aus, um diese Ausnahme zu vermeiden.

name Wert
Bereich Microsoft Edge
Version 4.6.1
Typ Neuzuweisung

NullReferenceException im Ausnahmebehandlungscode von ImageSourceConverter.ConvertFrom

Details

Ein Fehler im Ausnahmebehandlungscode für ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) löste einen inkorrekten System.NullReferenceException anstelle der beabsichtigten Ausnahme (System.IO.DirectoryNotFoundException oder System.IO.FileNotFoundException) aus. Diese Änderung korrigiert diesen Fehler, damit die Methode nun die richtige Ausnahme auslöst.

Standardmäßig werden alle Anwendungen, die .NET Framework 4.6.2 und früheren Versionen ausgerichtet sind, weiterhin aus Kompatibilitätsgründen ausgelöstSystem.NullReferenceException. Entwickler, die .NET Framework 4.7 und höher anzielen, sollten die richtigen Ausnahmen angezeigt bekommen.

Vorschlag

Entwickler, die wieder System.NullReferenceException erhalten möchten, wenn Sie .NET Framework 4.7 oder höher als Zielplattform verwenden, können der Datei „app.config“ ihrer Anwendung Folgendes hinzufügen oder die entsprechenden Angaben zusammenführen:

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Media.ImageSourceConverter.OverrideExceptionWithNullReferenceException=true"/>
</runtime>
</configuration>
name Wert
Bereich Microsoft Edge
Version 4.7
Typ Neuzuweisung

Betroffene APIs

Platzvergabe im Raster für -Spalten

Details

Ab .NET Framework 4.7 ersetzt WPF den Algorithmus, den Grid verwendet, um Platz für *-Spalten zuzuweisen. Dadurch wird die den *-Spalten zugewiesene tatsächliche Breite geändert,

  • wenn mindestens eine *-Spalte außerdem eine Minimal- oder Maximalbreite aufweisen, die die proportionale Zuweisung für die betreffende Spalte außer Kraft setzt. (Die Mindestbreite kann von einer expliziten MinWidth-Deklaration oder von einem impliziten Minimum abgeleitet werden, das aus dem Inhalt der Spalte abgerufen wird. Die maximale Breite kann nur explizit aus einer MaxWidth-Deklaration definiert werden.)

  • wenn mindestens eine *-Spalte eine extrem große *-Gewichtung deklarieren, die größer als 10^298 ist.

  • wenn die *-Gewichtungen ausreichend verschieden sind, um zu Gleitkommainstabilität zu führen (Überlauf, Unterlauf, Genauigkeitsverlust).

  • Wenn Layoutglättung aktiviert ist und der effektive DPI-Wert der Anzeige ausreichend hoch ist. In den ersten beiden Fällen können sich die vom neuen Algorithmus erzeugten Breiten erheblich von denen unterscheiden, die vom alten Algorithmus erzeugt werden. Im letzten Fall beträgt der Unterschied höchstens ein oder zwei Pixel.

    Der neue Algorithmus behebt mehrere Fehler, die im alten Algorithmus vorhanden sind:

  • Die Gesamtzuweisung an Spalten kann die Breite des Rasters überschreiten. Dies kann beim Zuweisen von Platz an eine Spalte geschehen, deren proportionaler Anteil geringer als ihre Mindestgröße ist. Der Algorithmus weist die Mindestgröße zu, wodurch der für andere Spalten verfügbare Platz verringert wird. Wenn keine zuzuweisenden *-Spalten mehr vorhanden sind, ist die Gesamtzuweisung zu groß.

  • Die Gesamtzuweisung kann die Breite des Rasters unterschreiten. Dieses Problem steht im Gegensatz zu Nr. 1 und entsteht, wenn eine Spalte zugewiesen wird, deren proportionaler Anteil größer als ihre Maximalgröße ist, wenn keine *-Spalten zum Ausgleich des Über- oder Untermaßes vorhanden sind.

  • Zwei *-Spalten können Zuweisungen erhalten, die nicht proportional zu ihren *-Gewichtungen sind. Dies ist eine mildere Version von Nr. 1/Nr. 2, die beim Zuweisen zu den *-Spalten A, B und C (in dieser Reihenfolge) auftritt, wobei der proportionale Anteil von B gegen deren Min- oder Max-Bedingung verstößt. Wie oben ändert sich dadurch der für Spalte C zur Verfügung stehende Platz, die proportional eine kleinere (oder größeren) Zuweisung als A erhält.

  • Spalten mit extrem hohen Gewichtungen (> 10^298) werden alle behandelt, als würden sie die Gewichtung 10^298 aufweisen. Proportionale Unterschiede zwischen ihnen (und zwischen Spalten mit erheblich kleineren Gewichtungen) werden nicht berücksichtigt.

  • Spalten mit der Gewichtung unendlich werden nicht ordnungsgemäß behandelt. [Tatsächlich lässt sich die Gewichtung nicht auf unendlich festlegen, aber das ist eine künstliche Einschränkung. Der Zuweisungscode hat versucht, das Problem zu behandeln, dabei aber versagt.]

  • Mehrere kleinere Probleme beim Vermeiden von Überlauf, Unterlauf, Genauigkeitsverlust und ähnlichen Gleitkommaproblemen.

  • Anpassungen für Layoutglättung sind bei ausreichend hohem DPI fehlerhaft. Der neue Algorithmus erzeugt Ergebnisse, die die folgenden Kriterien erfüllen:

    A. Die einer *-Spalte zugewiesene Breite ist niemals kleiner als ihre Mindestbreite oder größer als ihre Maximalbreite.
    B. Jede -Spalte, der nicht ihre Mindest- oder Maximalbreite zugewiesen wird, wird eine Breite zugewiesen, die proportional zu ihrer -Gewichtung ist. Genauer gesagt, wenn zwei Spalten die Breite x bzw. y zugewiesen werden und keine der beiden Spalten ihre Minimal- oder Maximalbreite erhält, stehen die den Spalten zugewiesenen tatsächlichen Breiten v und w im gleichen Verhältnis: v / w == x / y.
    C. Die Gesamtbreite, die "proportionalen" *-Spalten zugeordnet ist, entspricht dem verfügbaren Platz nach der Zuweisung zu den eingeschränkten Spalten (feste, automatische und *-Spalten, denen die Mindest- oder Maximalbreite zugeordnet wird). Diese kann Null sein, beispielsweise, wenn die Summe der Mindestbreiten die zur Verfügung stehende Breite des Rasters überschreitet.
    D: Alle diese Anweisungen müssen im Hinblick auf das „ideale“ Layout interpretiert werden. Wenn Layoutglättung aktiviert ist, können die tatsächlichen Breiten um bis zu ein Pixel von den idealen Breiten abweichen.
    Der alte Algorithmus hat (A) berücksichtigt, aber die anderen Kriterien in den oben beschriebenen Fällen nicht erfüllt.

    Alles, was in diesem Artikel zu Spalten und Breiten gesagt wird, gilt auch für Zeilen und Höhen.

Vorschlag

Standardmäßig wird für Apps, die auf Versionen der .NET Framework ab .NET Framework 4.7 ausgerichtet sind, der neue Algorithmus angezeigt, während Apps, die auf die .NET Framework 4.6.2 oder frühere Versionen abzielen, der alte Algorithmus angezeigt wird.

Verwenden Sie die folgende Konfigurationseinstellung, um die Standardeinstellung zu überschreiben:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>

Der Wert true legt den alten Algorithmus fest, false den neuen.

name Wert
Bereich Gering
Version 4.7
Typ Neuzuweisung

Zeigerbasierte Touch-Stapel in WPF

Details

Diese Änderung ermöglicht das Aktivieren eines optionalen WM_POINTER-basierten WPF-Touch-/Stift-Stapels. Entwickler, die diesen Stapel nicht explizit aktivieren, sollten keine Änderung im WPF-Touch/Stift-Verhalten feststellen. Folgende Probleme sind mit dem optionalen WM_POINTER-basierten Touch-/Stift-Stapel bekannt:

  • Keine Unterstützung für Freihand in Echtzeit.
  • Zwar funktionieren Freihand- und Stift-Plug-Ins nach wie vor, jedoch werden sie im Benutzeroberflächenthread verarbeitet, was zu schlechter Leistung führen kann.
  • Verhaltensänderungen aufgrund der Verlagerung von Touch/Stift-Ereignissen zu Mausereignissen.
  • Die Bearbeitung verhält sich möglicherweise anders.
  • Drag/Drop zeigt keine angemessene Rückmeldung bei Toucheingaben.
  • Dies betrifft keine Stifteingaben.
  • Drag/Drop kann für Touch/Stift-Ereignisse nicht mehr ausgelöst werden.
  • Dadurch kann es vorkommen, dass die Anwendung nicht mehr reagiert, bis die Mauseingabe erkannt wird.
  • Stattdessen sollten Entwickler Drag & Drop über Mausereignisse einleiten.

Vorschlag

Entwickler, die diesen Stapel aktivieren möchten, können der Datei „app.config“ ihrer Anwendung Folgendes hinzufügen:

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Input.Stylus.EnablePointerSupport=true"/>
</runtime>
</configuration>

Entfernen oder Festlegen des Werts auf FALSE deaktiviert diesen optionalen Stapel. Beachten Sie, dass dieser Stapel nur unter Windows 10 Creators Update und höher verfügbar ist.

name Wert
Bereich Microsoft Edge
Version 4.7
Typ Neuzuweisung

Windows Workflow Foundation (WF)

Änderung der Workflowprüfsummen von MD5 in SHA1

Details

Die Workflowlaufzeit generiert unter Verwendung eines Hashalgorithmus zur Unterstützung des Debuggens mit Visual Studio eine Prüfsumme für eine Workflowinstanz. In .NET Framework 4.6.2 und früheren Versionen wird beim Hashing der Workflowprüfsumme der MD5-Algorithmus verwendet, der auf Systemen, auf den FIPS aktiviert ist, Probleme verursacht hat. Ab .NET Framework 4.7 wird der SHA1-Algorithmus verwendet. Wenn Ihr Code diese Prüfsummen dauerhaft gespeichert hat, sind diese nicht kompatibel.

Vorschlag

Wenn Ihr Code aufgrund eines Prüfsummenfehlers keine Workflowinstanzen laden kann, versuchen Sie, AppContext den Schalter "Switch.System.Activities.UseMD5ForWFDebugger" auf TRUE zu setzen. Im Code:

System.AppContext.SetSwitch("Switch.System.Activities.UseMD5ForWFDebugger", true);

Stattdessen können Sie dies auch im Rahmen der Konfiguration vornehmen:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Activities.UseMD5ForWFDebugger=true" />
  </runtime>
</configuration>
name Wert
Bereich Gering
Version 4.7
Typ Neuzuweisung