Freigeben über


Neuerungen in .NET Framework

Hinweis

.NET Framework wird unabhängig von Windows-Updates mit Sicherheits- und Zuverlässigkeitsfehlerkorrekturen gewartet. Im Allgemeinen werden Sicherheitsupdates vierteljährlich veröffentlicht. .NET Framework wird weiterhin in Windows enthalten sein, ohne sie zu entfernen. Sie müssen Ihre .NET Framework-Apps nicht migrieren, aber für die neue Entwicklung verwenden Sie .NET anstelle von .NET Framework.

In diesem Artikel werden die wichtigsten neuen Features und Verbesserungen in den folgenden Versionen von .NET Framework zusammengefasst:

Dieser Artikel enthält keine umfassenden Informationen zu den einzelnen neuen Features und kann geändert werden. Allgemeine Informationen zu .NET Framework finden Sie unter "Erste Schritte". Informationen zu unterstützten Plattformen finden Sie unter "Systemanforderungen". Downloadlinks und Installationsanweisungen finden Sie im Installationshandbuch.

Hinweis

Das .NET Framework-Team veröffentlicht außerdem Features außerhalb des Bandes, indem NuGet verwendet wird, um die Plattformunterstützung zu erweitern und neue Funktionen wie unveränderliche Sammlungen und SIMD-fähige Vektortypen einzuführen. Weitere Informationen finden Sie unter zusätzliche Klassenbibliotheken und APIs sowie .NET Framework und Out-of-Band-Versionen. Eine vollständige Liste der NuGet-Pakete für .NET Framework finden Sie in einer vollständigen Liste.

Einführung in .NET Framework 4.8.1

.NET Framework 4.8.1 baut auf früheren Versionen von .NET Framework 4.x auf, indem viele neue Fixes und mehrere neue Features hinzugefügt werden, während ein sehr stabiles Produkt erhalten bleibt.

Herunterladen und Installieren von .NET Framework 4.8.1

Sie können .NET Framework 4.8.1 von den folgenden Speicherorten herunterladen:

.NET Framework 4.8 kann unter Windows 11, Windows 10, Version 21H2, Windows 10, Version 21H1, Windows 10, Version 20H2 und den entsprechenden Serverplattformen ab Windows Server 2022 installiert werden. Sie können .NET Framework 4.8.1 entweder mit dem Webinstallationsprogramm oder dem Offlineinstallationsprogramm installieren. Die empfohlene Methode für die meisten Benutzer ist die Verwendung des Webinstallationsprogramms.

Sie können .NET Framework 4.8.1 in Visual Studio 2022 17.3 oder höher als Ziel verwenden, indem Sie das .NET Framework 4.8.1 Developer Pack installieren.

Neuerungen in .NET Framework 4.8.1

.NET Framework 4.8.1 führt neue Features in den folgenden Bereichen ein:

Verbesserte Barrierefreiheit, die es einer Anwendung ermöglicht, benutzern der Hilfstechnologie eine geeignete Oberfläche zu bieten, ist ein wichtiger Schwerpunkt von .NET Framework 4.8.1. Informationen zu Verbesserungen der Barrierefreiheit in .NET Framework 4.8.1 finden Sie unter "Neuerungen in der Barrierefreiheit in .NET Framework".

.NET Framework 4.8.1 fügt der .NET Framework-Familie native Arm64-Unterstützung hinzu. Ihre Investitionen in das umfangreiche Ökosystem von .NET Framework-Apps und -Bibliotheken können nun die Vorteile der nativen Ausführung von Workloads auf Arm64 nutzen– nämlich eine bessere Leistung im Vergleich zur Ausführung von x64-Code, der auf Arm64 emuliert wird.

Microsoft verpflichtet sich, Produkte und Plattformen bereitzustellen, die für alle zugänglich sind. .NET Framework 4.8.1 bietet zwei Windows-Ui-Entwicklungsplattformen, die Entwicklern die Unterstützung bieten, die zum Erstellen barrierefreier Anwendungen erforderlich sind. In den vergangenen Versionen wurden sowohl Windows Forms als auch WPF neue Features hinzugefügt und zahlreiche Zuverlässigkeitsprobleme im Zusammenhang mit der Barrierefreiheit behoben. Weitere Informationen zu den Neuerungen in den Barrierefreiheitsarten in .NET Framework finden Sie unter "Neuerungen bei der Barrierefreiheit in .NET Framework".

In dieser Version haben sowohl Windows Forms als auch WPF Verbesserungen an der Behandlung von QuickInfos vorgenommen, um sie barrierefreier zu gestalten. In beiden Fällen entsprechen QuickInfos jetzt den Richtlinien im WCAG2.1-Inhalt für Hover- oder Fokusleitfaden . Die Anforderungen für QuickInfos sind:

  • QuickInfos müssen entweder per Mauszeiger oder durch Tastaturnavigation zum Steuerelement angezeigt werden.
  • QuickInfos sollten verworfen werden können. Das heißt, ein einfacher Tastaturbefehl wie Esc sollte die QuickInfo schließen.
  • QuickInfos sollten darauf zeigen können. Benutzer sollten in der Lage sein, den Mauszeiger über die QuickInfo zu setzen. Dies ermöglicht Szenarien wie die Verwendung der Bildschirmlupe, um die QuickInfo für Sehbefinderbenutzer zu lesen.
  • QuickInfos sollten dauerhaft sein. QuickInfos sollten nicht automatisch ausgeblendet werden, nachdem eine bestimmte Zeitspanne verstrichen ist. Stattdessen sollten QuickInfos vom Benutzer geschlossen werden, der die Maus auf ein anderes Steuerelement oder einen Tastaturbefehl bewegt.

In Windows Forms ist diese Unterstützung nur unter Windows 11 oder höher verfügbar. Windows Forms ist ein dünner verwalteter Wrapper um die Windows-API, und das neue QuickInfo-Verhalten wurde nur in Windows 11 verfügbar. WPF verfügt über keine Versionsabhängigkeiten des Betriebssystems für die zugehörigen QuickInfos.

WPF hatte die meisten Anforderungen für WCAG2.1-kompatible QuickInfos in .NET Framework 4.8 implementiert. In dieser Version hat WPF die Benutzererfahrung verbessert, indem sichergestellt wird, dass eine QuickInfo im aktuellen Fenster mithilfe der ESC-TASTE , der STRG-TASTE (selbst) oder der Kombination STRG+UMSCHALT+F10 leicht geschlossen werden kann. Der Bereich der Escapetaste wurde in dieser Version reduziert, um nur auf das aktuelle Fenster anzuwenden. Zuvor wurde sie auf alle geöffneten QuickInfos in der Anwendung angewendet.

Windows Forms war der erste Windows-UI-Stapel, der für .NET Framework erstellt wurde. Daher wurde sie ursprünglich erstellt, um ältere Barrierefreiheitstechnologie zu nutzen, die nicht den aktuellen Anforderungen an die Barrierefreiheit entspricht. In dieser Version hat Windows Forms eine Reihe von Problemen behoben. Eine vollständige Liste der änderungen im Zusammenhang mit der Barrierefreiheit finden Sie unter What's new in accessibility in .NET Framework.

Die Highlights der Verbesserungen von Windows Forms in .NET Framework 4.8.1 sind:

  • Unterstützung für Textmuster– Windows Forms hat Unterstützung für das UIA-Textmuster hinzugefügt. Mit diesem Muster können Hilfstechnologien den Inhalt eines TextBox-Steuerelements oder eines ähnlichen textbasierten Steuerelementbuchstabens nach Buchstaben durchlaufen. Es ermöglicht die Auswahl von Text innerhalb des Steuerelements und der Änderung sowie des neuen Texts, der am Cursor eingefügt werden kann. Windows Forms hat diese Unterstützung für TextBox, DataGridView-Zellen, ComboBox-Steuerelemente und vieles mehr hinzugefügt.

  • Beheben von Kontrastproblemen – In mehreren Steuerelementen hat Windows Forms das Kontrastverhältnis von Auswahlrechtecks so geändert, dass sie dunkler und sichtbarer ist.

  • Es wurden mehrere DataGridView-Probleme behoben:

    • Die Bildlaufleistennamen wurden so aktualisiert, dass sie konsistent sind.
    • Die Sprachausgabe kann sich jetzt auf leere DataGridView-Zellen konzentrieren.
    • Entwickler können die lokalisierte Steuerelementtypeigenschaft für benutzerdefinierte DataGridView-Zellen festlegen.
    • Die Linkfarbe für DataGridViewLink-Zellen wurde aktualisiert, um einen besseren Kontrast zum Hintergrund zu erzielen.

Einführung in .NET Framework 4.8

.NET Framework 4.8 baut auf früheren Versionen von .NET Framework 4.x auf, indem viele neue Fixes und mehrere neue Features hinzugefügt werden, während ein sehr stabiles Produkt erhalten bleibt.

Herunterladen und Installieren von .NET Framework 4.8

Sie können .NET Framework 4.8 von den folgenden Speicherorten herunterladen:

.NET Framework 4.8 kann unter Windows 10, Windows 8.1, Windows 7 SP1 und den entsprechenden Serverplattformen ab Windows Server 2008 R2 SP1 installiert werden. Sie können .NET Framework 4.8 mithilfe des Webinstallationsprogramms oder des Offlineinstallationsprogramms installieren. Die empfohlene Methode für die meisten Benutzer ist die Verwendung des Webinstallationsprogramms.

Sie können .NET Framework 4.8 in Visual Studio 2012 oder höher als Ziel verwenden, indem Sie das .NET Framework 4.8 Developer Pack installieren.

Neuerungen in .NET Framework 4.8

.NET Framework 4.8 führt neue Features in den folgenden Bereichen ein:

Verbesserte Barrierefreiheit, die es einer Anwendung ermöglicht, benutzern der Hilfstechnologie eine geeignete Oberfläche zu bieten, ist weiterhin ein wichtiger Schwerpunkt von .NET Framework 4.8. Informationen zu Verbesserungen der Barrierefreiheit in .NET Framework 4.8 finden Sie unter "Neuerungen in der Barrierefreiheit in .NET Framework".

Basisklassen

Reduzierte FIPS-Auswirkungen auf Kryptografie. In früheren Versionen von .NET Framework werden von verwalteten Kryptografieanbieterklassen wie SHA256Managed z. B. ausgelöst CryptographicException , wenn die Kryptografiebibliotheken des Systems im "FIPS-Modus" konfiguriert sind. Diese Ausnahmen werden ausgelöst, da die verwalteten Versionen der Kryptografieanbieterklassen im Gegensatz zu den Systemgrafiebibliotheken keine FIPS-Zertifizierung (Federal Information Processing Standards) 140-2 durchlaufen haben. Da nur wenige Entwickler ihre Entwicklungsmaschinen im FIPS-Modus haben, werden die Ausnahmen häufig in Produktionssystemen ausgelöst.

In Anwendungen, die auf .NET Framework 4.8 abzielen, lösen die folgenden verwalteten Kryptografieklassen in diesem Fall keinen Fehler CryptographicException mehr aus:

Stattdessen leiten diese Klassen kryptografische Vorgänge zu einer Systemkryptografiebibliothek um. Diese Änderung entfernt effektiv einen potenziell verwirrenden Unterschied zwischen Entwicklerumgebungen und Produktionsumgebungen und macht systemeigene Komponenten und verwaltete Komponenten unter derselben kryptografischen Richtlinie ausgeführt. Anwendungen, die von diesen Ausnahmen abhängig sind, können das vorherige Verhalten wiederherstellen, indem Sie die Option "AppContext" Switch.System.Security.Cryptography.UseLegacyFipsThrow auf " true. Weitere Informationen finden Sie unter Verwaltete Kryptografieklassen lösen keine CryptographyException im FIPS-Modus aus.

Verwendung der aktualisierten Version von ZLib

Ab .NET Framework 4.5 verwendet die clrcompression.dll assembly ZLib, eine systemeigene externe Bibliothek für die Datenkomprimierung, um eine Implementierung für den Verzögerungsalgorithmus bereitzustellen. Die .NET Framework 4.8-Version von clrcompression.dll wird aktualisiert, um ZLib Version 1.2.11 zu verwenden, die mehrere wichtige Verbesserungen und Fixes enthält.

Windows Communication Foundation (WCF)

Einführung von ServiceHealthBehavior

Integritätsendpunkte werden häufig von Orchestrierungstools verwendet, um Dienste basierend auf ihrem Integritätsstatus zu verwalten. Integritätsprüfungen können auch von Überwachungstools verwendet werden, um Benachrichtigungen über die Verfügbarkeit und Leistung eines Diensts nachzuverfolgen und bereitzustellen.

ServiceHealthBehavior ist ein WCF-Dienstverhalten, das erweitert wird IServiceBehavior. Wenn sie der ServiceDescription.Behaviors Auflistung hinzugefügt werden, führt ein Dienstverhalten die folgenden Aktionen aus:

  • Gibt den Dienststatus mit HTTP-Antwortcodes zurück. Sie können in einer Abfragezeichenfolge den HTTP-Statuscode für eine HTTP/GET-Integritätstestanforderung angeben.

  • Veröffentlicht Informationen zum Dienststatus. Dienstspezifische Details, einschließlich Dienststatus, Drosselungsanzahl und Kapazität können mithilfe einer HTTP/GET-Anforderung mit der ?health Abfragezeichenfolge angezeigt werden. Der erleichterte Zugriff auf solche Informationen ist wichtig, wenn ein falscher WCF-Dienst problembestehend ist.

Es gibt zwei Möglichkeiten, den Integritätsendpunkt verfügbar zu machen und WCF-Dienststatusinformationen zu veröffentlichen:

  • Über Code. Beispiel:

    ServiceHost host = new ServiceHost(typeof(Service1),
                       new Uri("http://contoso:81/Service1"));
    ServiceHealthBehavior healthBehavior =
        host.Description.Behaviors.Find<ServiceHealthBehavior>();
    healthBehavior ??= new ServiceHealthBehavior();
    host.Description.Behaviors.Add(healthBehavior);
    
    Dim host As New ServiceHost(GetType(Service1),
                New Uri("http://contoso:81/Service1"))
    Dim healthBehavior As ServiceHealthBehavior =
       host.Description.Behaviors.Find(Of ServiceHealthBehavior)()
    If healthBehavior Is Nothing Then
       healthBehavior = New ServiceHealthBehavior()
    End If
    host.Description.Behaviors.Add(healthBehavior)
    
  • Mithilfe einer Konfigurationsdatei. Beispiel:

    <behaviors>
      <serviceBehaviors>
        <behavior name="DefaultBehavior">
          <serviceHealth httpsGetEnabled="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    

Der Integritätsstatus eines Diensts kann mithilfe von Abfrageparametern wie OnServiceFailure, , OnDispatcherFailure, OnListenerFailureOnThrottlePercentExceeded), abgefragt werden, und für jeden Abfrageparameter kann ein HTTP-Antwortcode angegeben werden. Wenn der HTTP-Antwortcode für einen Abfrageparameter weggelassen wird, wird standardmäßig ein 503 HTTP-Antwortcode verwendet. Beispiel:

Abfrageparameter und Beispiele:

  • OnDispatcherFailure: https://contoso:81/Service1?health&OnDispatcherFailure=455

    Ein 455 HTTP-Antwortstatuscode wird zurückgegeben, wenn der Status eines der Kanalverteiler größer als CommunicationState.Openedist.

  • OnListenerFailure: https://contoso:81/Service1?health&OnListenerFailure=465

    Ein 465 HTTP-Antwortstatuscode wird zurückgegeben, wenn der Status eines der Kanallistener größer als CommunicationState.Openedist.

  • OnThrottlePercentExceeded: https://contoso:81/Service1?health&OnThrottlePercentExceeded= 70:350,95:500

    Gibt den Prozentsatz {1 – 100} an, der die Antwort und den HTTP-Antwortcode {200 – 599} auslöst. In diesem Beispiel:

    • Wenn der Prozentsatz größer als 95 ist, wird ein HTTP-Antwortcode von 500 zurückgegeben.

    • Wenn der Prozentsatz zwischen 70 und 95 liegt, wird 350 zurückgegeben.

    • Andernfalls wird 200 zurückgegeben.

Der Dienststatus kann entweder in HTML angezeigt werden, indem eine Abfragezeichenfolge wie https://contoso:81/Service1?health oder xml angegeben wird, indem eine Abfragezeichenfolge wie angegeben https://contoso:81/Service1?health&Xmlwird. Eine Abfragezeichenfolge wie https://contoso:81/Service1?health&NoContent gibt eine leere HTML-Seite zurück.

Windows Presentation Foundation (WPF)

Verbesserungen bei hohen DPI-Werten

In .NET Framework 4.8 bietet WPF Unterstützung für Per-Monitor V2 DPI-Sensibilisierung und Mixed-Mode DPI-Skalierung. Weitere Informationen zur Entwicklung von hohen DPI-Werten für Desktopanwendungen finden Sie unter Windows .

.NET Framework 4.8 verbessert die Unterstützung für gehostete HWNDs und Windows Forms-Interoperabilität in High-DPI WPF-Anwendungen auf Plattformen, die Mixed-Mode DPI-Skalierung unterstützen (ab Windows 10 April 2018 Update). Wenn gehostete HWNDs oder Windows Forms-Steuerelemente als Mixed-Mode DPI-skalierte Fenster erstellt werden, indem SetThreadDpiHostingBehavior und SetThreadDpiAwarenessContext aufgerufen werden, können sie in einer Per-Monitor V2-WPF-Anwendung gehostet und entsprechend skaliert und skaliert werden. Solche gehosteten Inhalte werden nicht bei der nativen DPI gerendert; Stattdessen skaliert das Betriebssystem den gehosteten Inhalt auf die entsprechende Größe. Die Unterstützung für Per-Monitor v2 DPI-Sensibilisierungsmodus ermöglicht auch das Hosten von WPF-Steuerelementen (d. h. übergeordnet) in einem systemeigenen Fenster in einer Anwendung mit hohem DPI-Wert.

Um die Unterstützung für Mixed-Mode Skalierung mit hohem DPI-Wert zu aktivieren, können Sie die Anwendungskonfigurationsdatei durch die folgenden AppContext-Switches festlegen:

<runtime>
   <AppContextSwitchOverrides value = "Switch.System.Windows.DoNotScaleForDpiChanges=false; Switch.System.Windows.DoNotUsePresentationDpiCapabilityTier2OrGreater=false"/>
</runtime>

Common Language Runtime

Die Laufzeit in .NET Framework 4.8 enthält die folgenden Änderungen und Verbesserungen:

Verbesserungen am JIT-Compiler. Der Just-in-Time-Compiler (JIT) in .NET Framework 4.8 basiert auf dem JIT-Compiler in .NET Core 2.1. Viele der Optimierungen und alle Fehlerkorrekturen, die an den JIT-Compiler .NET Core 2.1 vorgenommen wurden, sind im .NET Framework 4.8 JIT-Compiler enthalten.

NGEN Verbesserungen. Die Laufzeit hat die Speicherverwaltung für Native Image Generator (NGEN)-Bilder verbessert, sodass daten, die aus NGEN-Bildern zugeordnet sind, nicht speicherresident sind. Dadurch wird der verfügbare Oberflächenbereich für Angriffe reduziert, die versuchen, beliebigen Code auszuführen, indem der Arbeitsspeicher geändert wird, der ausgeführt wird.

Antischadsoftwareüberprüfung für alle Assemblys. In früheren Versionen von .NET Framework überprüft die Laufzeit alle Assemblys, die von einem Datenträger geladen wurden, entweder mit Windows Defender oder Antischadsoftware von Drittanbietern. Assemblys, die aus anderen Quellen geladen wurden, z. B. durch die Assembly.Load(Byte[]) Methode, werden jedoch nicht gescannt und können potenziell nicht erkannte Schadsoftware enthalten. Ab .NET Framework 4.8 unter Windows 10 löst die Laufzeit einen Scan durch Antischadsoftwarelösungen aus, die die Antimalware Scan Interface (AMSI) implementieren.

Neuerungen in .NET Framework 4.7.2

.NET Framework 4.7.2 enthält neue Features in den folgenden Bereichen:

Ein fortlaufender Fokus in .NET Framework 4.7.2 ist eine verbesserte Barrierefreiheit, die es einer Anwendung ermöglicht, eine geeignete Benutzeroberfläche für Benutzer der Hilfstechnologie bereitzustellen. Informationen zu Verbesserungen der Barrierefreiheit in .NET Framework 4.7.2 finden Sie unter "Neuerungen in der Barrierefreiheit in .NET Framework".

Basisklassen

.NET Framework 4.7.2 bietet eine große Anzahl kryptografischer Verbesserungen, eine bessere Dekomprimierungsunterstützung für ZIP-Archive und zusätzliche Sammlungs-APIs.

Neue Überladungen von RSA. Erstellen und DSA. Schaffen

Mit DSA.Create(DSAParameters) den Methoden RSA.Create(RSAParameters) können Sie beim Instanziieren eines neuen DSA Schlüssels RSA schlüsselparameter angeben. Sie ermöglichen es Ihnen, Code wie die folgenden zu ersetzen:

// Before .NET Framework 4.7.2
using (RSA rsa = RSA.Create())
{
   rsa.ImportParameters(rsaParameters);
   // Other code to execute using the RSA instance.
}
' Before .NET Framework 4.7.2
Using rsa = RSA.Create()
   rsa.ImportParameters(rsaParameters)
   ' Other code to execute using the rsa instance.
End Using

mit Code wie folgt:

// Starting with .NET Framework 4.7.2
using (RSA rsa = RSA.Create(rsaParameters))
{
   // Other code to execute using the rsa instance.
}
' Starting with .NET Framework 4.7.2
Using rsa = RSA.Create(rsaParameters)
   ' Other code to execute using the rsa instance.
End Using

Mit den DSA.Create(Int32) Methoden RSA.Create(Int32) können Sie neue DSA Schlüssel oder RSA Schlüssel mit einer bestimmten Schlüsselgröße generieren. Beispiel:

using (DSA dsa = DSA.Create(2048))
{
   // Other code to execute using the dsa instance.
}
Using dsa = DSA.Create(2048)
   ' Other code to execute using the dsa instance.
End Using

Rfc2898DeriveBytes-Konstruktoren akzeptieren einen Hashalgorithmusnamen

Die Rfc2898DeriveBytes Klasse verfügt über drei neue Konstruktoren mit einem HashAlgorithmName Parameter, der den HMAC-Algorithmus identifiziert, der beim Ableiten von Schlüsseln verwendet werden soll. Anstatt SHA-1 zu verwenden, sollten Entwickler einen SHA-2-basierten HMAC wie SHA-256 verwenden, wie im folgenden Beispiel gezeigt:

private static byte[] DeriveKey(string password, out int iterations, out byte[] salt,
                                out HashAlgorithmName algorithm)
{
   iterations = 100000;
   algorithm = HashAlgorithmName.SHA256;

   const int SaltSize = 32;
   const int DerivedValueSize = 32;

   using (Rfc2898DeriveBytes pbkdf2 = new Rfc2898DeriveBytes(password, SaltSize,
                                                             iterations, algorithm))
   {
      salt = pbkdf2.Salt;
      return pbkdf2.GetBytes(DerivedValueSize);
   }
}
Private Shared Function DeriveKey(password As String, ByRef iterations As Integer,
                                  ByRef salt AS Byte(), ByRef algorithm As HashAlgorithmName) As Byte()
   iterations = 100000
   algorithm = HashAlgorithmName.SHA256

   Const SaltSize As Integer = 32
   Const  DerivedValueSize As Integer = 32

   Using pbkdf2 = New Rfc2898DeriveBytes(password, SaltSize, iterations, algorithm)
      salt = pbkdf2.Salt
      Return pbkdf2.GetBytes(DerivedValueSize)
   End Using
End Function

Unterstützung für kurzlebige Schlüssel

Der PFX-Import kann optional private Schlüssel direkt aus dem Arbeitsspeicher laden und die Festplatte umgehen. Wenn das neue X509KeyStorageFlags.EphemeralKeySet Flag in einem X509Certificate2 Konstruktor oder einer der Überladungen der X509Certificate2.Import Methode angegeben wird, werden die privaten Schlüssel als kurzlebige Schlüssel geladen. Dadurch wird verhindert, dass die Schlüssel auf dem Datenträger sichtbar sind. Aber:

  • Da die Schlüssel nicht auf dem Datenträger gespeichert werden, sind Zertifikate, die mit diesem Flag geladen wurden, nicht geeignet, einem X509Store hinzuzufügen.

  • Auf diese Weise geladene Schlüssel werden fast immer über Windows CNG geladen. Daher müssen Aufrufer auf den privaten Schlüssel zugreifen, indem Erweiterungsmethoden wie z. B. Cert aufgerufen werden. GetRSAPrivateKey(). Die X509Certificate2.PrivateKey Eigenschaft funktioniert nicht.

  • Da die Legacyeigenschaft X509Certificate2.PrivateKey nicht mit Zertifikaten funktioniert, sollten Entwickler strenge Tests durchführen, bevor Sie zu kurzlebigen Schlüsseln wechseln.

Programmgesteuerte Erstellung von PKCS#10-Zertifizierungssignaturanforderungen und X.509-Zertifikaten für öffentliche Schlüssel

Ab .NET Framework 4.7.2 können Workloads Zertifikatsignaturanforderungen (Certificate Signing Requests, CSRs) generieren, wodurch die Zertifikatanforderungsgenerierung in vorhandene Tools unterteilt werden kann. Dies ist häufig bei Testszenarien hilfreich.

Weitere Informationen und Codebeispiele finden Sie unter "Programmgesteuerte Erstellung von PKCS#10-Zertifizierungssignaturanforderungen und X.509-Zertifikaten für öffentliche Schlüssel" im .NET-Blog.

Neue SignerInfo-Mitglieder

Ab .NET Framework 4.7.2 macht die SignerInfo Klasse weitere Informationen zur Signatur verfügbar. Sie können den Wert der System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm Eigenschaft abrufen, um den vom Signierer verwendeten Signaturalgorithmus zu bestimmen. SignerInfo.GetSignature kann aufgerufen werden, um eine Kopie der kryptografischen Signatur für diesen Signierer abzurufen.

Lassen Sie einen umgebrochenen Stream geöffnet, nachdem CryptoStream verworfen wurde

Ab .NET Framework 4.7.2 verfügt die CryptoStream Klasse über einen zusätzlichen Konstruktor, mit dem der eingeschlossene Datenstrom nicht geschlossen werden kann Dispose . Rufen Sie den neuen CryptoStream Konstruktor wie folgt auf, um den umbrochenen Datenstrom nach dem Verwerfen der CryptoStream Instanz geöffnet zu lassen:

var cStream = new CryptoStream(stream, transform, mode, leaveOpen: true);
Dim cStream = New CryptoStream(stream, transform, mode, leaveOpen:=true)

Dekomprimierungsänderungen in DeflateStream

Ab .NET Framework 4.7.2 wurde die Implementierung von Dekomprimierungsvorgängen in der DeflateStream Klasse standardmäßig geändert, um systemeigene Windows-APIs zu verwenden. In der Regel führt dies zu einer erheblichen Leistungsverbesserung.

Die Unterstützung für die Dekomprimierung mithilfe von Windows-APIs ist standardmäßig für Anwendungen aktiviert, die auf .NET Framework 4.7.2 abzielen. Anwendungen, die auf frühere Versionen von .NET Framework abzielen, aber unter .NET Framework 4.7.2 ausgeführt werden, können sich für dieses Verhalten entscheiden, indem Sie der Anwendungskonfigurationsdatei den folgenden AppContext-Switch hinzufügen:

<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=false" />

Zusätzliche Sammlungs-APIs

.NET Framework 4.7.2 fügt den und SortedSet<T> den HashSet<T> Typen eine Reihe neuer APIs hinzu. Dazu gehören:

Die ConcurrentDictionary<TKey,TValue> Klasse enthält neue Überladungen der AddOrUpdate Und GetOrAdd Methoden zum Abrufen eines Werts aus dem Wörterbuch oder zum Hinzufügen, wenn sie nicht gefunden wird, und zum Hinzufügen eines Werts zum Wörterbuch oder zum Aktualisieren, wenn er bereits vorhanden ist.

public TValue AddOrUpdate<TArg>(TKey key, Func<TKey, TArg, TValue> addValueFactory, Func<TKey, TValue, TArg, TValue> updateValueFactory, TArg factoryArgument)

public TValue GetOrAdd<TArg>(TKey key, Func<TKey, TArg, TValue> valueFactory, TArg factoryArgument)
Public AddOrUpdate(Of TArg)(key As TKey, addValueFactory As Func(Of TKey, TArg, TValue), updateValueFactory As Func(Of TKey, TValue, TArg, TValue), factoryArgument As TArg) As TValue

Public GetOrAdd(Of TArg)(key As TKey, valueFactory As Func(Of TKey, TArg, TValue), factoryArgument As TArg) As TValue

ASP.NET

Unterstützung für die Abhängigkeitsinjektion in Webformularen

Die Abhängigkeitsinjektion (Dependency Injection, DI) entkoppelt Objekte und deren Abhängigkeiten, sodass der Code eines Objekts nicht mehr geändert werden muss, nur weil sich eine Abhängigkeit geändert hat. Beim Entwickeln von ASP.NET Anwendungen, die auf .NET Framework 4.7.2 abzielen, können Sie folgende Aktionen ausführen:

Unterstützung für Cookies mit derselben Website

SameSite verhindert, dass ein Browser ein Cookie zusammen mit einer websiteübergreifenden Anforderung sendet. .NET Framework 4.7.2 fügt eine HttpCookie.SameSite Eigenschaft hinzu, deren Wert ein System.Web.SameSiteMode Enumerationselement ist. Ist der Wert SameSiteMode.Strict oder SameSiteMode.Lax, ASP.NET fügt das SameSite Attribut dem Set-Cookie-Header hinzu. Die SameSite-Unterstützung gilt sowohl für HttpCookie Objekte als auch für FormsAuthenticationSystem.Web.SessionState Cookies.

Sie können SameSite für ein HttpCookie Objekt wie folgt festlegen:

var c = new HttpCookie("secureCookie", "same origin");
c.SameSite = SameSiteMode.Lax;
Dim c As New HttpCookie("secureCookie", "same origin")
c.SameSite = SameSiteMode.Lax

Sie können sameSite-Cookies auch auf Anwendungsebene konfigurieren, indem Sie die web.config Datei ändern:

<system.web>
   <httpCookies sameSite="Strict" />
</system.web>

Sie können SameSite für FormsAuthentication und System.Web.SessionState Cookies hinzufügen, indem Sie die Webkonfigurationsdatei ändern:

<system.web>
   <authentication mode="Forms">
      <forms cookieSameSite="Lax">
         <!-- ...   -->
      </forms>
   </authentication>
   <sessionState cookieSameSite="Lax"></sessionState>
</system.web>

Vernetzung

Implementierung von HttpClientHandler-Eigenschaften

.NET Framework 4.7.1 hat der System.Net.Http.HttpClientHandler Klasse acht Eigenschaften hinzugefügt. Zwei haben jedoch einen PlatformNotSupportedException. .NET Framework 4.7.2 stellt jetzt eine Implementierung für diese Eigenschaften bereit. Die Eigenschaften sind:

SQLClient

Unterstützung für die universelle Azure Active Directory-Authentifizierung und die mehrstufige Authentifizierung

Die wachsenden Compliance- und Sicherheitsanforderungen erfordern, dass viele Kunden mehrstufige Authentifizierung (MFA) verwenden. Darüber hinaus wird empfohlen, die aktuellen bewährten Methoden davon abzuhalten, Benutzerwörter direkt in Verbindungszeichenfolgen einzugeben. Um diese Änderungen zu unterstützen, erweitert .NET Framework 4.7.2 SQLClient-Verbindungszeichenfolgen durch Hinzufügen eines neuen Werts, "Active Directory Interactive", für das vorhandene Schlüsselwort "Authentication" zur Unterstützung der MFA- und Azure AD-Authentifizierung. Die neue interaktive Methode unterstützt systemeigene und verbundene Azure AD-Benutzer sowie Azure AD-Gastbenutzer. Wenn diese Methode verwendet wird, wird die von Azure AD auferlegte MFA-Authentifizierung für SQL-Datenbanken unterstützt. Darüber hinaus fordert der Authentifizierungsprozess ein Benutzerkennwort an, die bewährten Methoden der Sicherheit einzuhalten.

In früheren Versionen von .NET Framework unterstützte die SQL-Konnektivität nur die und SqlAuthenticationMethod.ActiveDirectoryPassword die SqlAuthenticationMethod.ActiveDirectoryIntegrated Optionen. Beide sind Teil des nicht interaktiven ADAL-Protokolls, das MFA nicht unterstützt. Mit der neuen SqlAuthenticationMethod.ActiveDirectoryInteractive Option unterstützt die SQL-Konnektivität MFA sowie vorhandene Authentifizierungsmethoden (Kennwort und integrierte Authentifizierung), mit denen Benutzer Benutzerkennwörter interaktiv eingeben können, ohne Kennwörter in der Verbindungszeichenfolge beizubehalten.

Weitere Informationen und ein Beispiel finden Sie im .NET-Blog unter "SQL -- Azure AD Universal and Multifactor Authentication Support".

Unterstützung für Always Encrypted, Version 2

NET Framework 4.7.2 fügt Unterstützung für Enklaven-basierte Always Encrypted hinzu. Die ursprüngliche Version von Always Encrypted ist eine clientseitige Verschlüsselungstechnologie, bei der Verschlüsselungsschlüssel niemals den Client verlassen. In Enklave-based Always Encrypted kann der Client optional die Verschlüsselungsschlüssel an eine sichere Enklave senden, bei der es sich um eine sichere Rechenentität handelt, die als Teil von SQL Server betrachtet werden kann, der SQL Server-Code jedoch nicht manipuliert werden kann. Um enklave-based Always Encrypted zu unterstützen, fügt .NET Framework 4.7.2 die folgenden Typen und Member zum System.Data.SqlClient Namespace hinzu:

Die Anwendungskonfigurationsdatei gibt dann eine konkrete Implementierung der abstrakten Klasse an, die die Funktionalität für den Enklavenanbieter System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider bereitstellt. Beispiel:

<configuration>
  <configSections>
    <section name="SqlColumnEncryptionEnclaveProviders" type="System.Data.SqlClient.SqlColumnEncryptionEnclaveProviderConfigurationSection,System.Data,Version=4.0.0.0,Culture=neutral,PublicKeyToken=b77a5c561934e089"/>
  </configSections>
  <SqlColumnEncryptionEnclaveProviders>
    <providers>
      <add name="Azure" type="Microsoft.SqlServer.Management.AlwaysEncrypted.AzureEnclaveProvider,MyApp"/>
      <add name="HGS" type="Microsoft.SqlServer.Management.AlwaysEncrypted.HGSEnclaveProvider,MyApp" />
    </providers>
  </SqlColumnEncryptionEnclaveProviders >
</configuration>

Der grundlegende Fluss der Enklaven-basierten Always Encrypted lautet:

  1. Der Benutzer erstellt eine AlwaysEncrypted-Verbindung mit SQL Server, die Enklave-basierte Always Encrypted unterstützt. Der Fahrer kontaktiert den Nachweisdienst, um sicherzustellen, dass er eine Verbindung mit der rechten Enklave herstellt.

  2. Nachdem die Enklave nachgewiesen wurde, richtet der Treiber einen sicheren Kanal mit der sicheren Enklave ein, die auf SQL Server gehostet wird.

  3. Der Treiber teilt Verschlüsselungsschlüssel, die vom Client autorisiert wurden, mit der sicheren Enklave für die Dauer der SQL-Verbindung.

Windows Presentation Foundation

Suchen von ResourceDictionaries nach Quelle

Ab .NET Framework 4.7.2 kann ein Diagnose-Assistent das ResourceDictionaries aus einem bestimmten Quell-URI erstellte Suchen. (Dieses Feature dient zur Verwendung durch Diagnoseassistenten, nicht für Produktionsanwendungen.) Mit einem Diagnoseassistenten wie der Einrichtung "Edit-and-Continue" von Visual Studio kann der Benutzer ein ResourceDictionary mit der Absicht bearbeiten, dass die Änderungen auf die ausgeführte Anwendung angewendet werden. Ein Schritt zur Erreichung dieser Vorgehensweise besteht darin, alle ResourceDictionaries zu finden, die die ausgeführte Anwendung aus dem Wörterbuch erstellt hat, das bearbeitet wird. Beispielsweise kann eine Anwendung ein ResourceDictionary deklarieren, dessen Inhalt aus einem bestimmten Quell-URI kopiert wird:

<ResourceDictionary Source="MyRD.xaml" />

Ein Diagnose-Assistent, der das ursprüngliche Markup in MyRD.xaml bearbeitet, kann das neue Feature verwenden, um das Wörterbuch zu suchen. Das Feature wird durch eine neue statische Methode implementiert. ResourceDictionaryDiagnostics.GetResourceDictionariesForSource Der Diagnose-Assistent ruft die neue Methode mit einem absoluten URI auf, der das ursprüngliche Markup identifiziert, wie im folgenden Code veranschaulicht:

IEnumerable<ResourceDictionary> dictionaries = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(new Uri("pack://application:,,,/MyApp;component/MyRD.xaml"));
Dim dictionaries As IEnumerable(Of ResourceDictionary) = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(New Uri("pack://application:,,,/MyApp;component/MyRD.xaml"))

Die Methode gibt eine leere Enumeration zurück, es sei denn VisualDiagnostics , sie ist aktiviert, und die ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO Umgebungsvariable wird festgelegt.

Suchen von ResourceDictionary-Besitzern

Ab .NET Framework 4.7.2 kann ein Diagnose-Assistent die Besitzer eines bestimmten ResourceDictionaryTyps suchen. (Das Feature dient zur Verwendung durch Diagnoseassistenten und nicht für Produktionsanwendungen.) Wenn eine Änderung an einem ResourceDictionaryObjekt vorgenommen wird, findet WPF automatisch alle DynamicResource-Verweise , die möglicherweise von der Änderung betroffen sind.

Ein Diagnoseassistent, z. B. die Einrichtung "Edit-and-Continue" von Visual Studio, kann dies erweitern, um StatischeResource-Verweise zu behandeln. Der erste Schritt in diesem Prozess besteht darin, die Besitzer des Wörterbuchs zu finden; das heißt, alle Objekte zu finden, deren Resources Eigenschaft sich auf das Wörterbuch bezieht (entweder direkt oder indirekt über die ResourceDictionary.MergedDictionaries Eigenschaft). Drei neue statische Methoden, die für die System.Windows.Diagnostics.ResourceDictionaryDiagnostics Klasse implementiert sind, eine für jeden basistypen mit einer Resources Eigenschaft, unterstützen diesen Schritt:

Diese Methoden geben eine leere Aufzählung zurück, es sei denn VisualDiagnostics , sie ist aktiviert, und die ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO Umgebungsvariable wird festgelegt.

Suchen von StaticResource-Verweisen

Ein Diagnose-Assistent kann jetzt eine Benachrichtigung erhalten, wenn ein StaticResource-Verweis aufgelöst wird. (Das Feature dient zur Verwendung durch Diagnoseassistenten, nicht durch Produktionsanwendungen.) Ein Diagnoseassistent, z. B. die Einrichtung "Edit-and-Continue" von Visual Studio, kann alle Verwendungen einer Ressource aktualisieren, wenn sich der Wert in einer ResourceDictionary Änderung ändert. WPF führt dies automatisch für DynamicResource-Verweise aus, dies geschieht jedoch absichtlich nicht für StaticResource-Verweise . Ab .NET Framework 4.7.2 kann der Diagnose-Assistent diese Benachrichtigungen verwenden, um diese Verwendungen der statischen Ressource zu finden.

Die Benachrichtigung wird vom neuen ResourceDictionaryDiagnostics.StaticResourceResolved Ereignis implementiert:

public static event EventHandler<StaticResourceResolvedEventArgs> StaticResourceResolved;
Public Shared Event StaticResourceResolved As EventHandler(Of StaticResourceResolvedEventArgs)

Dieses Ereignis wird ausgelöst, wenn die Laufzeit einen StaticResource-Verweis aufgelöst. Die StaticResourceResolvedEventArgs Argumente beschreiben die Auflösung und geben das Objekt und die Eigenschaft an, das den StaticResource-Verweis und den ResourceDictionary für die Auflösung verwendeten Schlüssel hosten:

public class StaticResourceResolvedEventArgs : EventArgs
{
   public Object TargetObject { get; }

   public Object TargetProperty { get; }

   public ResourceDictionary ResourceDictionary { get; }

   public object ResourceKey { get; }
}
Public Class StaticResourceResolvedEventArgs : Inherits EventArgs
   Public ReadOnly Property TargetObject As Object
   Public ReadOnly Property TargetProperty As Object
   Public ReadOnly Property ResourceDictionary As ResourceDictionary
   Public ReadOnly Property ResourceKey As Object
End Class

Das Ereignis wird nicht ausgelöst (und sein add Accessor wird ignoriert), es sei denn VisualDiagnostics , es ist aktiviert und die ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO Umgebungsvariable festgelegt.

ClickOnce

HDPI-fähige Anwendungen für Windows Forms, Windows Presentation Foundation (WPF) und Visual Studio Tools for Office (VSTO) können mit ClickOnce bereitgestellt werden. Wenn der folgende Eintrag im Anwendungsmanifest gefunden wird, wird die Bereitstellung unter .NET Framework 4.7.2 erfolgreich ausgeführt:

<windowsSettings>
   <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>

Für die Windows Forms-Anwendung ist die vorherige Problemumgehung der Einstellung des DPI-Bewusstseins in der Anwendungskonfigurationsdatei anstelle des Anwendungsmanifests nicht mehr erforderlich, damit die ClickOnce-Bereitstellung erfolgreich ist.

Neuerungen in .NET Framework 4.7.1

.NET Framework 4.7.1 enthält neue Features in den folgenden Bereichen:

Darüber hinaus wird die Barrierefreiheit von .NET Framework 4.7.1 verbessert, sodass eine Anwendung eine geeignete Benutzeroberfläche für Benutzer der Hilfstechnologie bereitstellen kann. Informationen zu Verbesserungen der Barrierefreiheit in .NET Framework 4.7.1 finden Sie unter "Neuerungen in der Barrierefreiheit in .NET Framework".

Basisklassen

Unterstützung für .NET Standard 2.0

.NET Standard definiert einen Satz von APIs, die für jede .NET-Implementierung verfügbar sein müssen, die diese Version des Standards unterstützt. .NET Framework 4.7.1 unterstützt .NET Standard 2.0 vollständig und fügt ca. 200 APIs hinzu, die in .NET Standard 2.0 definiert sind und in .NET Framework 4.6.1, 4.6.2 und 4.7 fehlen. (Beachten Sie, dass diese Versionen von .NET Framework .NET Standard 2.0 nur unterstützen, wenn zusätzliche .NET Standard-Supportdateien auch auf dem Zielsystem bereitgestellt werden.) Weitere Informationen finden Sie im Blogbeitrag "BCL - .NET Standard 2.0 Support" im Blogbeitrag .NET Framework 4.7.1 Runtime and Compiler Features .

Unterstützung für Konfigurations-Generatoren

Mit Konfigurations-Generatoren können Entwickler Konfigurationseinstellungen für Anwendungen dynamisch zur Laufzeit einfügen und erstellen. Benutzerdefinierte Konfigurations-Generatoren können verwendet werden, um vorhandene Daten in einem Konfigurationsabschnitt zu ändern oder einen Konfigurationsabschnitt vollständig neu zu erstellen. Ohne Konfigurations-Generatoren sind .config Dateien statisch, und ihre Einstellungen werden einige Zeit vor dem Starten einer Anwendung definiert.

Um einen benutzerdefinierten Konfigurations-Generator zu erstellen, leiten Sie den Generator von der abstrakten ConfigurationBuilder Klasse ab und überschreiben seine ConfigurationBuilder.ProcessConfigurationSection und ConfigurationBuilder.ProcessRawXml. Außerdem definieren Sie Ihre Generatoren in Ihrer .config Datei. Weitere Informationen finden Sie im Blogbeitrag "Konfigurations-Generatoren" im Blogbeitrag .NET Framework 4.7.1 ASP.NET und Konfigurationsfeatures .

Erkennung von Laufzeitfunktionen

Die System.Runtime.CompilerServices.RuntimeFeature Klasse stellt einen Mechanismus bereit, um zu bestimmen, ob ein vordefiniertes Feature zur Kompilierungszeit oder Laufzeit für eine bestimmte .NET-Implementierung unterstützt wird. Zur Kompilierungszeit kann ein Compiler überprüfen, ob ein angegebenes Feld vorhanden ist, um festzustellen, ob das Feature unterstützt wird. wenn ja, kann code ausgegeben werden, der diese Funktion nutzt. Zur Laufzeit kann eine Anwendung die RuntimeFeature.IsSupported Methode aufrufen, bevor sie Code zur Laufzeit generiert. Weitere Informationen finden Sie unter "Hilfsmethode hinzufügen", um features zu beschreiben, die von der Laufzeit unterstützt werden.

Wert-Tupeltypen sind serialisierbar

Ab .NET Framework 4.7.1 System.ValueTuple sind die zugehörigen generischen Typen als serialisierbar gekennzeichnet, wodurch die binäre Serialisierung möglich ist. Dies sollte die Migration von Tupeltypen, z Tuple<T1,T2,T3> . B. und Tuple<T1,T2,T3,T4>, zu Wert tupeltypen vereinfachen. Weitere Informationen finden Sie im Blogbeitrag "Compiler - ValueTuple is Serializable" im Blogbeitrag .NET Framework 4.7.1 Runtime and Compiler Features .

Unterstützung für schreibgeschützte Verweise

.NET Framework 4.7.1 fügt die System.Runtime.CompilerServices.IsReadOnlyAttribute. Dieses Attribut wird von Sprachcompilern verwendet, um Member mit schreibgeschützten Verweisrücklauftypen oder -parametern zu markieren. Weitere Informationen finden Sie im Blogbeitrag "Compiler - Support for ReadOnlyReferences" im Blogbeitrag .NET Framework 4.7.1 Runtime and Compiler Features . Informationen zu Bezugsrücklaufwerten finden Sie unter Ref return values and ref locals and Ref return values (Visual Basic).

Common Language Runtime (CLR)

Leistungsverbesserungen bei der Garbage Collection

Änderungen an der Garbage Collection (GC) in .NET Framework 4.7.1 verbessern die Gesamtleistung, insbesondere für LOH-Zuordnungen (Large Object Heap). In .NET Framework 4.7.1 werden separate Sperren für kleine Objekt heap (SOH) und LOH-Zuordnungen verwendet, wodurch LOH-Zuordnungen auftreten können, wenn die Hintergrund-GC die SOH aufräumt. Daher sollten Anwendungen, die eine große Anzahl von LOH-Zuordnungen machen, eine Verringerung der Zuordnungssperre und eine verbesserte Leistung sehen. Weitere Informationen finden Sie im Blogbeitrag "Runtime -- GC Performance Improvements" im Blogbeitrag .NET Framework 4.7.1 Runtime and Compiler Features .

Vernetzung

SHA-2-Unterstützung für Message.HashAlgorithm

In .NET Framework 4.7 und früheren Versionen werden die Message.HashAlgorithm Eigenschaftswerte von HashAlgorithm.Md5 und HashAlgorithm.Sha nur unterstützt. Ab .NET Framework 4.7.1, HashAlgorithm.Sha256, HashAlgorithm.Sha384, und HashAlgorithm.Sha512 werden ebenfalls unterstützt. Ob dieser Wert tatsächlich verwendet wird, hängt von MSMQ ab, da die Message Instanz selbst kein Hashing ausführt, sondern einfach Werte an MSMQ weitergibt. Weitere Informationen finden Sie im Blogbeitrag "SHA-2-Unterstützung für Message.HashAlgorithm" im Blogbeitrag ".NET Framework 4.7.1 ASP.NET und Konfigurationsfeatures ".

ASP.NET

Ausführungsschritte in ASP.NET Anwendungen

ASP.NET verarbeitet Anforderungen in einer vordefinierten Pipeline, die 23 Ereignisse enthält. ASP.NET führt jeden Ereignishandler als Ausführungsschritt aus. In Versionen von ASP.NET bis .NET Framework 4.7 kann ASP.NET den Ausführungskontext aufgrund des Wechsels zwischen nativen und verwalteten Threads nicht fließen. Stattdessen fließt ASP.NET selektiv nur die HttpContext. Ab .NET Framework 4.7.1 ermöglicht die HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) Methode auch die Wiederherstellung von Umgebungsdaten. Dieses Feature richtet sich an Bibliotheken, die sich mit der Ablaufverfolgung, Profilerstellung, Diagnose oder Transaktionen befassen, z. B. um den Ausführungsfluss der Anwendung. Weitere Informationen finden Sie im Blogbeitrag "ASP.NET Ausführungsschrittfeature" im Blogbeitrag .NET Framework 4.7.1 ASP.NET und Konfigurationsfeatures .

ASP.NET HttpCookie-Analyse

.NET Framework 4.7.1 enthält eine neue Methode, HttpCookie.TryParsedie eine standardisierte Möglichkeit zum Erstellen eines HttpCookie Objekts aus einer Zeichenfolge bietet und Cookiewerte wie Ablaufdatum und Pfad genau zuweist. Weitere Informationen finden Sie im Blogbeitrag "ASP.NET HttpCookie-Analyse" im Blogbeitrag .NET Framework 4.7.1 ASP.NET und Konfigurationsfeatures .

SHA-2-Hashoptionen für ASP.NET Anmeldeinformationen für die Formularauthentifizierung

In .NET Framework 4.7 und früheren Versionen ermöglichte ASP.NET Entwicklern das Speichern von Benutzeranmeldeinformationen mit Hashkennwörtern in Konfigurationsdateien mithilfe von MD5 oder SHA1. Ab .NET Framework 4.7.1 unterstützt ASP.NET auch neue sichere SHA-2-Hashoptionen wie SHA256, SHA384 und SHA512. SHA1 bleibt die Standardeinstellung, und ein nicht standardmäßiger Hashalgorithmus kann in der Webkonfigurationsdatei definiert werden.

Von Bedeutung

Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden. Wenn Sie eine Verbindung mit Azure SQL herstellen, ist Managed Identities for Azure Resources die empfohlene Authentifizierungsmethode.

Neuerungen in .NET Framework 4.7

.NET Framework 4.7 enthält neue Features in den folgenden Bereichen:

Eine Liste der neuen APIs, die .NET Framework 4.7 hinzugefügt wurden, finden Sie unter .NET Framework 4.7 API Changes on GitHub. Eine Liste der Featureverbesserungen und Fehlerbehebungen in .NET Framework 4.7 finden Sie unter .NET Framework 4.7 Liste der Änderungen auf GitHub. Weitere Informationen finden Sie unter Ankündigung von .NET Framework 4.7 im .NET-Blog.

Basisklassen

.NET Framework 4.7 verbessert die Serialisierung durch:DataContractJsonSerializer

Erweiterte Funktionalität mit Elliptic Curve Cryptography (ECC)*

In .NET Framework 4.7 ImportParameters(ECParameters) wurden Methoden zur Darstellung eines bereits eingerichteten Schlüssels zu den ECDsa Klassen und ECDiffieHellman Klassen hinzugefügt, damit ein Objekt einen bereits eingerichteten Schlüssel darstellt. Außerdem wurde eine ExportParameters(Boolean) Methode zum Exportieren des Schlüssels mithilfe expliziter Kurvenparameter hinzugefügt.

.NET Framework 4.7 bietet auch Unterstützung für zusätzliche Kurven (einschließlich der Brainpool-Kurvensuite) und hat vordefinierte Definitionen für die einfache Erstellung durch die neuen Create und Create Werksmethoden hinzugefügt.

Sie können ein Beispiel für .NET Framework 4.7-Kryptografieverbesserungen auf GitHub sehen.

Bessere Unterstützung für Steuerzeichen durch den DataContractJsonSerializer

In .NET Framework 4.7 serialisiert die DataContractJsonSerializer Klasse Steuerzeichen gemäß dem ECMAScript 6-Standard. Dieses Verhalten ist standardmäßig für Anwendungen aktiviert, die auf .NET Framework 4.7 abzielen, und ist ein Opt-In-Feature für Anwendungen, die unter .NET Framework 4.7 ausgeführt werden, aber auf eine frühere Version von .NET Framework abzielen. Weitere Informationen finden Sie im Abschnitt "Anwendungskompatibilität ".

Vernetzung

.NET Framework 4.7 fügt das folgende netzwerkbezogene Feature hinzu:

Standardmäßige Betriebssystemunterstützung für TLS-Protokolle*

Der TLS-Stapel, der von System.Net.Security.SslStream und Up-Stack-Komponenten wie HTTP, FTP und SMTP verwendet wird, ermöglicht Es Entwicklern, die vom Betriebssystem unterstützten Standard-TLS-Protokolle zu verwenden. Entwickler benötigen keine TLS-Version mehr hartcodierten.

ASP.NET

In .NET Framework 4.7 enthält ASP.NET die folgenden neuen Features:

Erweiterbarkeit des Objektcaches

Ab .NET Framework 4.7 fügt ASP.NET einen neuen Satz von APIs hinzu, mit denen Entwickler die standardmäßigen ASP.NET Implementierungen für die Zwischenspeicherung von Speicherobjekten und die Speicherüberwachung ersetzen können. Entwickler können jetzt eine der folgenden drei Komponenten ersetzen, wenn die ASP.NET Implementierung nicht ausreichend ist:

  • Objektcachespeicher. Mithilfe des Konfigurationsabschnitts für neue Cacheanbieter können Entwickler neue Implementierungen eines Objektcaches für eine ASP.NET Anwendung mithilfe der neuen ICacheStoreProvider Schnittstelle anschließen.

  • Speicherüberwachung. Der Standardspeichermonitor in ASP.NET benachrichtigt Anwendungen, wenn sie nahe am konfigurierten Grenzwert für private Bytes für den Prozess ausgeführt werden, oder wenn der Computer auf dem gesamten verfügbaren physischen RAM niedrig ist. Wenn diese Grenzwerte nahe sind, werden Benachrichtigungen ausgelöst. Bei einigen Anwendungen werden Benachrichtigungen zu nah an den konfigurierten Grenzwerten ausgelöst, um nützliche Reaktionen zu ermöglichen. Entwickler können jetzt eigene Speichermonitore schreiben, um die Standardeinstellung durch die ApplicationMonitors.MemoryMonitor Eigenschaft zu ersetzen.

  • Speicherbeschränkungsreaktionen. Standardmäßig versucht ASP.NET, den Objektcache zu kürzen und regelmäßig aufzurufen GC.Collect , wenn der Grenzwert für den privaten Byteprozess nahe ist. Bei einigen Anwendungen ist die Häufigkeit der Aufrufe an GC.Collect oder die Menge des zu kürzenden Caches ineffizient. Entwickler können jetzt das Standardverhalten ersetzen oder ergänzen, indem Sie Implementierungen für den Speichermonitor der Anwendung abonnieren IObserver .

Windows Communication Foundation (WCF)

Windows Communication Foundation (WCF) fügt die folgenden Features und Änderungen hinzu:

Möglichkeit zum Konfigurieren der Standardeinstellungen für Nachrichtensicherheit auf TLS 1.1 oder TLS 1.2

Ab .NET Framework 4.7 ermöglicht WCF die Konfiguration von TLS 1.1 oder TLS 1.2 zusätzlich zu SSL 3.0 und TLS 1.0 als Standardnachrichtensicherheitsprotokoll. Dies ist eine Opt-In-Einstellung; um sie zu aktivieren, müssen Sie der Anwendungskonfigurationsdatei den folgenden Eintrag hinzufügen:

<runtime>
   <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>

Verbesserte Zuverlässigkeit von WCF-Anwendungen und WCF-Serialisierung

WCF enthält eine Reihe von Codeänderungen, die Racebedingungen beseitigen, wodurch die Leistung und die Zuverlässigkeit von Serialisierungsoptionen verbessert werden. Dazu gehören:

  • Bessere Unterstützung für das Mischen von asynchronen und synchronen Code in Aufrufen von SocketConnection.BeginRead und SocketConnection.Read.
  • Verbesserte Zuverlässigkeit beim Abbrechen einer Verbindung mit SharedConnectionListenerDuplexChannelBinder.
  • Verbesserte Zuverlässigkeit von Serialisierungsvorgängen beim Aufrufen der FormatterServices.GetSerializableMembers(Type) Methode.
  • Verbesserte Zuverlässigkeit beim Entfernen eines Waiters durch Aufrufen der ChannelSynchronizer.RemoveWaiter-Methode .

Windows Forms

In .NET Framework 4.7 verbessert Windows Forms die Unterstützung für Monitore mit hohem DPI-Wert.

Unterstützung für hohe DPI-Werte

Beginnend mit Anwendungen, die auf .NET Framework 4.7 abzielen, bietet .NET Framework hohe DPI- und dynamische DPI-Unterstützung für Windows Forms-Anwendungen. Die Unterstützung für hohe DPI-Werte verbessert das Layout und die Darstellung von Formularen und Steuerelementen auf Monitoren mit hohem DPI-Wert. Der dynamische DPI-Wert ändert das Layout und die Darstellung von Formularen und Steuerelementen, wenn der Benutzer den DPI- oder Anzeigemaßstabfaktor einer ausgeführten Anwendung ändert.

Die Unterstützung für hohe DPI-Werte ist ein Opt-In-Feature, das Sie konfigurieren, indem Sie einen <Abschnitt "System.Windows.Forms.ConfigurationSection> " in Ihrer Anwendungskonfigurationsdatei definieren. Weitere Informationen zum Hinzufügen hoher DPI-Unterstützung und dynamischer DPI-Unterstützung zu Ihrer Windows Forms-Anwendung finden Sie unter Unterstützung für hohe DPI-Werte in Windows Forms.

Windows Presentation Foundation (WPF)

In .NET Framework 4.7 enthält WPF die folgenden Verbesserungen:

Unterstützung für einen Touch-/Eingabestiftstapel basierend auf Windows WM_POINTER-Nachrichten

Sie haben jetzt die Möglichkeit, einen Touch-/Eingabestiftstapel basierend auf WM_POINTER Nachrichten anstelle der Windows Ink Services Platform (WISP) zu verwenden. Dies ist ein Opt-In-Feature in .NET Framework. Weitere Informationen finden Sie im Abschnitt "Anwendungskompatibilität ".

Neue Implementierung für WPF-Druck-APIs

Die Druck-APIs von WPF in der System.Printing.PrintQueue Klasse rufen die Windows Print Document Package-API anstelle der veralteten XPS-Druck-API auf. Die Auswirkungen dieser Änderung auf die Anwendungskompatibilität finden Sie im Abschnitt "Anwendungskompatibilität ".

Neuerungen in .NET Framework 4.6.2

.NET Framework 4.6.2 enthält neue Features in den folgenden Bereichen:

Eine Liste der neuen APIs, die .NET Framework 4.6.2 hinzugefügt wurden, finden Sie unter .NET Framework 4.6.2 API Changes on GitHub. Eine Liste der Featureverbesserungen und Fehlerbehebungen in .NET Framework 4.6.2 finden Sie unter .NET Framework 4.6.2 Liste der Änderungen auf GitHub. Weitere Informationen finden Sie unter Ankündigung von .NET Framework 4.6.2 im .NET-Blog.

ASP.NET

In .NET Framework 4.6.2 enthält ASP.NET die folgenden Verbesserungen:

Verbesserte Unterstützung für lokalisierte Fehlermeldungen in Datenanmerkungsprüfern

Mit Datenanmerkungsprüfern können Sie eine Überprüfung durchführen, indem Sie einer Klasseneigenschaft mindestens ein Attribut hinzufügen. Das Attributelement ValidationAttribute.ErrorMessage definiert den Text der Fehlermeldung, wenn die Überprüfung fehlschlägt. Ab .NET Framework 4.6.2 erleichtert ASP.NET das Lokalisieren von Fehlermeldungen. Fehlermeldungen werden lokalisiert, wenn:

  1. Dies ValidationAttribute.ErrorMessage wird im Überprüfungsattribut bereitgestellt.

  2. Die Ressourcendatei wird im ordner App_LocalResources gespeichert.

  3. Der Name der lokalisierten Ressourcendatei weist den DataAnnotation.Localization.{}.resx auf, wobei der Name ein Kulturname im Format languageCode-country/regionCode oder languageCode ist.

  4. Der Schlüsselname der Ressource ist die dem ValidationAttribute.ErrorMessage Attribut zugewiesene Zeichenfolge, und ihr Wert ist die lokalisierte Fehlermeldung.

Das folgende Datenanmerkungsattribut definiert beispielsweise die Fehlermeldung der Standardkultur für eine ungültige Bewertung.

public class RatingInfo
{
   [Required(ErrorMessage = "The rating must be between 1 and 10.")]
   [Display(Name = "Your Rating")]
   public int Rating { get; set; }
}
Public Class RatingInfo
   <Required(ErrorMessage = "The rating must be between 1 and 10.")>
   <Display(Name = "Your Rating")>
   Public Property Rating As Integer = 1
End Class

Anschließend können Sie eine Ressourcendatei dataAnnotation.Localization.fr.resx erstellen, deren Schlüssel die Fehlermeldungszeichenfolge ist und deren Wert die lokalisierte Fehlermeldung ist. Die Datei muss im App.LocalResources Ordner gefunden werden. Im Folgenden sehen Sie beispielsweise den Schlüssel und den Wert in einer lokalisierten französischen (fr)-Sprachfehlermeldung:

Name Wert
Die Bewertung muss zwischen 1 und 10 liegen. La note doit être umfasst entre 1 et 10.

Darüber hinaus ist die Lokalisierung von Datenanmerkungen erweiterbar. Entwickler können ihren eigenen Zeichenfolgenlokalisierungsanbieter anschließen, indem sie die IStringLocalizerProvider Schnittstelle zum Speichern von Lokalisierungszeichenfolgen an einer anderen Stelle als in einer Ressourcendatei implementieren.

Asynchrone Unterstützung für Sitzungsstatusspeicheranbieter

ASP.NET ermöglicht jetzt die Verwendung von Task-Returning-Methoden mit Session-State Store-Anbietern, wodurch ASP.NET Apps die Skalierbarkeitsvorteile asynchroner Nutzen erzielen können. Um asynchrone Vorgänge mit Sitzungsstatusspeicheranbietern zu unterstützen, enthält ASP.NET eine neue Schnittstelle, die von entwicklern erbt System.Web.SessionState.ISessionStateModule und es Entwicklern ermöglicht, IHttpModuleihr eigenes Sitzungsstatusmodul und asynchrone Sitzungsspeicheranbieter zu implementieren. Die Schnittstelle ist wie folgt definiert:

public interface ISessionStateModule : IHttpModule {
    void ReleaseSessionState(HttpContext context);
    Task ReleaseSessionStateAsync(HttpContext context);
}
Public Interface ISessionStateModule : Inherits IHttpModule
   Sub ReleaseSessionState(context As HttpContext)
   Function ReleaseSessionStateAsync(context As HttpContext) As Task
End Interface

Darüber hinaus enthält die SessionStateUtility Klasse zwei neue Methoden und IsSessionStateReadOnlyIsSessionStateRequiredkönnen verwendet werden, um asynchrone Vorgänge zu unterstützen.

Asynchrone Unterstützung für Ausgabecacheanbieter

Ab .NET Framework 4.6.2 können Aufgabenrückgabemethoden mit Ausgabecacheanbietern verwendet werden, um die Skalierbarkeitsvorteile von asynchronen Zugängen bereitzustellen. Anbieter, die diese Methoden implementieren, reduzieren die Threadblockierung auf einem Webserver und verbessern die Skalierbarkeit eines ASP.NET-Diensts.

Die folgenden APIs wurden hinzugefügt, um asynchrone Ausgabecacheanbieter zu unterstützen:

Zeichenkategorien

Zeichen in .NET Framework 4.6.2 werden basierend auf dem Unicode Standard, Version 8.0.0, klassifiziert. In .NET Framework 4.6 und .NET Framework 4.6.1 wurden Zeichen basierend auf Unicode 6.3-Zeichenkategorien klassifiziert.

Die Unterstützung für Unicode 8.0 ist auf die Klassifizierung von Zeichen durch die CharUnicodeInfo Klasse und auf Typen und Methoden beschränkt, die darauf basieren. Dazu gehören die StringInfo Klasse, die überladene Char.GetUnicodeCategory Methode und die Zeichenklassen , die vom Regulären Ausdrucksmodul .NET Framework erkannt werden. Zeichen- und Zeichenfolgenvergleich und -sortierung sind von dieser Änderung nicht betroffen und basieren weiterhin auf dem zugrunde liegenden Betriebssystem oder auf Windows 7-Systemen auf Zeichendaten, die von .NET Framework bereitgestellt werden.

Änderungen in Zeichenkategorien von Unicode 6.0 zu Unicode 7.0 finden Sie auf der Unicode Consortium-Website unter "Unicode Standard, Version 7.0.0 ". Änderungen von Unicode 7.0 zu Unicode 8.0 finden Sie unter "Unicode Standard, Version 8.0.0" auf der Website des Unicode Consortium.

Kryptografie

Unterstützung für X509-Zertifikate mit FIPS 186-3 DSA

.NET Framework 4.6.2 fügt Unterstützung für DSA (Digital Signature Algorithm) X509-Zertifikate hinzu, deren Schlüssel die FIPS 186-2 1024-Bit-Grenze überschreiten.

Zusätzlich zur Unterstützung der größeren Schlüsselgrößen von FIPS 186-3 ermöglicht .NET Framework 4.6.2 das Berechnen von Signaturen mit der SHA-2-Familie von Hashalgorithmen (SHA256, SHA384 und SHA512). DIE FIPS 186-3-Unterstützung wird von der neuen System.Security.Cryptography.DSACng Klasse bereitgestellt.

Im Einklang mit den letzten Änderungen an der RSA Klasse in .NET Framework 4.6 und der ECDsa Klasse in .NET Framework 4.6.1 verfügt die DSA abstrakte Basisklasse in .NET Framework 4.6.2 über zusätzliche Methoden, mit denen Aufrufer diese Funktionalität ohne Umwandlung verwenden können. Sie können die DSACertificateExtensions.GetDSAPrivateKey Erweiterungsmethode aufrufen, um Daten zu signieren, wie im folgenden Beispiel gezeigt.

public static byte[] SignDataDsaSha384(byte[] data, X509Certificate2 cert)
{
    using (DSA dsa = cert.GetDSAPrivateKey())
    {
        return dsa.SignData(data, HashAlgorithmName.SHA384);
    }
}
Public Shared Function SignDataDsaSha384(data As Byte(), cert As X509Certificate2) As Byte()
    Using DSA As DSA = cert.GetDSAPrivateKey()
        Return DSA.SignData(data, HashAlgorithmName.SHA384)
    End Using
End Function

Und Sie können die DSACertificateExtensions.GetDSAPublicKey Erweiterungsmethode aufrufen, um signierte Daten zu überprüfen, wie im folgenden Beispiel gezeigt.

public static bool VerifyDataDsaSha384(byte[] data, byte[] signature, X509Certificate2 cert)
{
    using (DSA dsa = cert.GetDSAPublicKey())
    {
        return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384);
    }
}
 Public Shared Function VerifyDataDsaSha384(data As Byte(), signature As Byte(), cert As X509Certificate2) As Boolean
    Using dsa As DSA = cert.GetDSAPublicKey()
        Return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384)
    End Using
End Function

Erhöhte Klarheit für Eingaben in ECDiffieHellman-Schlüsselableitungsroutinen

.NET Framework 3.5 hat Unterstützung für Elliptic Curve Diffie-Hellman Key Agreement mit drei verschiedenen KDF-Routinen (Key Derivation Function) hinzugefügt. Die Eingaben an die Routinen und die Routinen selbst wurden über Eigenschaften des ECDiffieHellmanCng Objekts konfiguriert. Da aber nicht jede Routine jede Eingabeeigenschaft liest, gab es ausreichend Platz für Verwirrung in der Vergangenheit des Entwicklers.

Um dies in .NET Framework 4.6.2 zu beheben, wurden die folgenden drei Methoden zur ECDiffieHellman Basisklasse hinzugefügt, um diese KDF-Routinen und ihre Eingaben deutlicher darzustellen:

ECDiffieHellman-Methode Description
DeriveKeyFromHash(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[]) Ableiten des Schlüsselmaterials mithilfe der Formel

HASH(secretPrepend || x || secretAppend)

HASH(secretPrepend OrElse x OrElse secretAppend)

dabei ist x das berechnete Ergebnis des EC-Diffie-Hellman Algorithmus.
DeriveKeyFromHmac(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[], Byte[]) Ableiten des Schlüsselmaterials mithilfe der Formel

HMAC(hmacKey, secretPrepend || x || secretAppend)

HMAC(hmacKey, secretPrepend Oder x Oder secretAppend)

dabei ist x das berechnete Ergebnis des EC-Diffie-Hellman Algorithmus.
DeriveKeyTls(ECDiffieHellmanPublicKey, Byte[], Byte[]) Abgeleitet schlüsselmaterial using the TLS pseudo-random function (PRF) der Ableitungsalgorithmus.

Unterstützung für die symmetrische Persisted-Key-Verschlüsselung

Die Windows-Kryptografiebibliothek (CNG) hat Unterstützung für das Speichern beibehaltener symmetrischer Schlüssel und die Verwendung von hardwaregespeicherten symmetrischen Schlüsseln hinzugefügt, und .NET Framework 4.6.2 ermöglichte Entwicklern die Verwendung dieses Features. Da der Begriff der Schlüsselnamen und Schlüsselanbieter implementierungsspezifisch ist, erfordert die Verwendung dieses Features den Konstruktor der konkreten Implementierungstypen anstelle des bevorzugten Factoryansatzes (z. B. Aufrufen Aes.Create).

Die persisted-key symmetrische Verschlüsselungsunterstützung ist für die Algorithmen AES (AesCng) und 3DES (TripleDESCng) vorhanden. Beispiel:

public static byte[] EncryptDataWithPersistedKey(byte[] data, byte[] iv)
{
    using (Aes aes = new AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider))
    {
        aes.IV = iv;

        // Using the zero-argument overload is required to make use of the persisted key
        using (ICryptoTransform encryptor = aes.CreateEncryptor())
        {
            if (!encryptor.CanTransformMultipleBlocks)
            {
                throw new InvalidOperationException("This is a sample, this case wasn't handled...");
            }

            return encryptor.TransformFinalBlock(data, 0, data.Length);
        }
    }
}
Public Shared Function EncryptDataWithPersistedKey(data As Byte(), iv As Byte()) As Byte()
    Using Aes As Aes = New AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider)
        Aes.IV = iv

        ' Using the zero-argument overload Is required to make use of the persisted key
        Using encryptor As ICryptoTransform = Aes.CreateEncryptor()
            If Not encryptor.CanTransformMultipleBlocks Then
                Throw New InvalidOperationException("This is a sample, this case wasn't handled...")
            End If
            Return encryptor.TransformFinalBlock(data, 0, data.Length)
        End Using
    End Using
End Function

SignedXml-Unterstützung für SHA-2-Hashing

.NET Framework 4.6.2 unterstützt die SignedXml Klasse für RSA-SHA256-, RSA-SHA384- und RSA-SHA512 PKCS#1-Signaturmethoden sowie SHA256-, SHA384- und SHA512-Referenzdigestalgorithmen.

Die URI-Konstanten werden alle verfügbar gemacht für SignedXml:

SignedXml-Feld Dauerhaft
XmlDsigSHA256Url "http://www.w3.org/2001/04/xmlenc#sha256"
XmlDsigRSASHA256Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
XmlDsigSHA384Url "http://www.w3.org/2001/04/xmldsig-more#sha384"
XmlDsigRSASHA384Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha384"
XmlDsigSHA512Url "http://www.w3.org/2001/04/xmlenc#sha512"
XmlDsigRSASHA512Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"

Alle Programme, die einen benutzerdefinierten SignatureDescription Handler CryptoConfig registriert haben, um unterstützung für diese Algorithmen hinzuzufügen, funktionieren weiterhin wie in der Vergangenheit, aber da es jetzt Plattformstandardwerte gibt, ist die CryptoConfig Registrierung nicht mehr erforderlich.

SqlClient

.NET Framework-Datenanbieter für SQL Server (System.Data.SqlClient) enthält die folgenden neuen Features in .NET Framework 4.6.2:

Verbindungspooling und Timeouts mit Azure SQL-Datenbanken

Wenn die Verbindungspoolerstellung aktiviert ist und ein Timeout oder ein anderer Anmeldefehler auftritt, wird eine Ausnahme zwischengespeichert, und die zwischengespeicherte Ausnahme wird für jeden nachfolgenden Verbindungsversuch für die nächsten 5 Sekunden bis 1 Minute ausgelöst. Weitere Informationen finden Sie unter SQL Server Connection Pooling (ADO.NET).For more information, see SQL Server Connection Pooling (ADO.NET).

Dieses Verhalten ist beim Herstellen einer Verbindung mit Azure SQL-Datenbanken nicht wünschenswert, da Verbindungsversuche mit vorübergehenden Fehlern fehlschlagen können, die normalerweise schnell wiederhergestellt werden. Um die Verbindungs-Wiederholungserfahrung besser zu optimieren, wird das Blockierungszeitraumverhalten des Verbindungspools entfernt, wenn Verbindungen mit Azure SQL-Datenbanken fehlschlagen.

Durch das Hinzufügen des neuen PoolBlockingPeriod Schlüsselworts können Sie den Blockierungszeitraum auswählen, der für Ihre App am besten geeignet ist. Zu den Werten gehören folgende:

Auto

Der Sperrzeitraum für den Verbindungspool für eine Anwendung, die eine Verbindung mit einer Azure SQL-Datenbank herstellt, ist deaktiviert, und der Sperrzeitraum für den Verbindungspool für eine Anwendung, die eine Verbindung mit einer anderen SQL Server-Instanz herstellt, ist aktiviert. Dies ist der Standardwert. Wenn der Name des Serverendpunkts mit einem der folgenden Endet, werden sie als Azure SQL-Datenbanken betrachtet:

  • .database.windows.net

  • .database.chinacloudapi.cn

  • .database.usgovcloudapi.net

  • .database.cloudapi.de

AlwaysBlock

Der Sperrzeitraum für den Verbindungspool ist immer aktiviert.

NeverBlock

Der Sperrzeitraum des Verbindungspools ist immer deaktiviert.

Verbesserungen für Always Encrypted

SQLClient führt zwei Verbesserungen für Always Encrypted ein:

  • Um die Leistung parametrisierter Abfragen für verschlüsselte Datenbankspalten zu verbessern, werden verschlüsselungsmetadaten für Abfrageparameter jetzt zwischengespeichert. Wenn die SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled eigenschaft auf (der Standardwert) festgelegt true ist, ruft der Client, wenn dieselbe Abfrage mehrmals aufgerufen wird, Parametermetadaten vom Server nur einmal ab.

  • Spaltenverschlüsselungsschlüsseleinträge im Schlüsselcache werden jetzt nach einem konfigurierbaren Zeitintervall entfernt, das mithilfe der SqlConnection.ColumnEncryptionKeyCacheTtl Eigenschaft festgelegt wird.

Windows Communication Foundation

In .NET Framework 4.6.2 wurde Windows Communication Foundation in den folgenden Bereichen verbessert:

WCF-Transportsicherheitsunterstützung für Zertifikate, die mit CNG gespeichert sind

WCF-Transportsicherheit unterstützt Zertifikate, die mithilfe der Windows-Kryptografiebibliothek (CNG) gespeichert sind. In .NET Framework 4.6.2 ist diese Unterstützung auf die Verwendung von Zertifikaten mit einem öffentlichen Schlüssel beschränkt, der nicht mehr als 32 Bit lang ist. Wenn eine Anwendung auf .NET Framework 4.6.2 ausgerichtet ist, ist dieses Feature standardmäßig aktiviert.

Für Anwendungen, die auf .NET Framework 4.6.1 und früher abzielen, aber auf .NET Framework 4.6.2 ausgeführt werden, kann dieses Feature aktiviert werden, indem sie die folgende Zeile zum <Laufzeitabschnitt> der datei app.config oder web.config hinzufügen.

<AppContextSwitchOverrides
    value="Switch.System.IdentityModel.DisableCngCertificates=false"
/>

Dies kann auch programmgesteuert mit Code wie den folgenden erfolgen:

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificates";
AppContext.SetSwitch(disableCngCertificates, false);
Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

Bessere Unterstützung für mehrere Anpassungsregeln für Sommerzeit durch die DataContractJsonSerializer-Klasse

Kunden können eine Anwendungskonfigurationseinstellung verwenden, um zu bestimmen, ob die DataContractJsonSerializer Klasse mehrere Anpassungsregeln für eine einzelne Zeitzone unterstützt. Dies ist ein Opt-In-Feature. Um sie zu aktivieren, fügen Sie ihrer app.config Datei die folgende Einstellung hinzu:

<runtime>
     <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseTimeZoneInfo=false" />
</runtime>

Wenn dieses Feature aktiviert ist, verwendet ein DataContractJsonSerializer Objekt den TimeZoneInfo Typ anstelle des TimeZone Typs, um Datums- und Uhrzeitdaten zu deserialisieren. TimeZoneInfo unterstützt mehrere Anpassungsregeln, wodurch es möglich ist, mit historischen Zeitzonendaten zu arbeiten; TimeZone Nicht.

Weitere Informationen zur TimeZoneInfo Struktur- und Zeitzonenanpassung finden Sie unter "Übersicht über Zeitzonen".

Beste Übereinstimmung mit NetNamedPipeBinding

WCF verfügt über eine neue App-Einstellung, die für Clientanwendungen festgelegt werden kann, um sicherzustellen, dass sie immer eine Verbindung mit dem Dienst herstellen, der den von ihnen angeforderten Dienst überwacht. Wenn diese App-Einstellung auf false (Standardeinstellung) festgelegt ist, ist es möglich, dass Clients NetNamedPipeBinding versuchen, eine Verbindung mit einem Dienst herzustellen, der auf einen URI lauscht, der eine Teilzeichenfolge des angeforderten URI ist.

Beispielsweise versucht ein Client, eine Verbindung mit einem Dienst herzustellen, der überwacht net.pipe://localhost/Service1wird, aber ein anderer Dienst auf diesem Computer, der mit Administratorrechten ausgeführt wird, überwacht net.pipe://localhost. Wenn diese App-Einstellung auf " false" festgelegt ist, versucht der Client, eine Verbindung mit dem falschen Dienst herzustellen. Nach dem Festlegen der App-Einstellung auf true stellt der Client immer eine Verbindung mit dem besten Übereinstimmenden Dienst her.

Hinweis

Clients, NetNamedPipeBinding die Dienste basierend auf der Basisadresse des Diensts (sofern vorhanden) anstelle der vollständigen Endpunktadresse verwenden. Um sicherzustellen, dass diese Einstellung immer funktioniert, sollte der Dienst eine eindeutige Basisadresse verwenden.

Um diese Änderung zu aktivieren, fügen Sie die folgende App-Einstellung zur App.config oder Web.config Datei Ihrer Clientanwendung hinzu:

<configuration>
    <appSettings>
        <add key="wcf:useBestMatchNamedPipeUri" value="true" />
    </appSettings>
</configuration>

SSL 3.0 ist kein Standardprotokoll

Bei Verwendung von NetTcp mit Transportsicherheit und einem Zertifikattyp für Anmeldeinformationen ist SSL 3.0 kein Standardprotokoll mehr, das zum Verhandeln einer sicheren Verbindung verwendet wird. In den meisten Fällen sollte es keine Auswirkungen auf vorhandene Apps geben, da TLS 1.0 in der Protokollliste für NetTcp enthalten ist. Alle vorhandenen Clients sollten in der Lage sein, eine Verbindung mit mindestens TLS 1.0 auszuhandeln. Wenn Ssl3 erforderlich ist, verwenden Sie einen der folgenden Konfigurationsmechanismen, um es der Liste der ausgehandelten Protokolle hinzuzufügen.

Windows Presentation Foundation (WPF)

In .NET Framework 4.6.2 wurde Windows Presentation Foundation in den folgenden Bereichen verbessert:

Gruppieren der Sortierung

Eine Anwendung, die ein CollectionView Objekt zum Gruppieren von Daten verwendet, kann jetzt explizit deklarieren, wie die Gruppen sortiert werden. Explizite Sortierung behebt das Problem der nicht intuitiven Sortierung, die auftritt, wenn eine App Gruppen dynamisch hinzufügt oder entfernt, oder wenn sie den Wert von Elementeigenschaften ändert, die an der Gruppierung beteiligt sind. Sie kann auch die Leistung des Gruppenerstellungsprozesses verbessern, indem Vergleiche der Gruppierungseigenschaften von der Sortierung der vollständigen Auflistung in die Sortierung der Gruppen verschoben werden.

Zur Unterstützung der Gruppensortierung beschreiben die neuen GroupDescription.SortDescriptions und GroupDescription.CustomSort Eigenschaften, wie die Sammlung von Gruppen sortiert wird, die GroupDescription vom Objekt erstellt werden. Dies entspricht der Art und Weise, wie die identisch benannten ListCollectionView Eigenschaften beschreiben, wie die Datenelemente sortiert werden.

Zwei neue statische Eigenschaften der PropertyGroupDescription Klasse CompareNameAscending und CompareNameDescendingkönnen für die häufigsten Fälle verwendet werden.

Die folgenden XAML-Gruppendaten werden z. B. nach Alter gruppiert, die Altersgruppen in aufsteigender Reihenfolge sortiert und die Elemente innerhalb jeder Altersgruppe nach Nachnamen gruppiert.

<GroupDescriptions>
     <PropertyGroupDescription
         PropertyName="Age"
         CustomSort=
              "{x:Static PropertyGroupDescription.CompareNamesAscending}"/>
     </PropertyGroupDescription>
</GroupDescriptions>

<SortDescriptions>
     <SortDescription PropertyName="LastName"/>
</SortDescriptions>

Unterstützung der Bildschirmtastatur

Die Unterstützung der Bildschirmtastatur ermöglicht die Fokusnachverfolgung in WPF-Anwendungen, indem die Bildschirmtastatur in Windows 10 automatisch aufgerufen und geschlossen wird, wenn die Toucheingabe von einem Steuerelement empfangen wird, das Texteingaben übernehmen kann.

In früheren Versionen von .NET Framework können WPF-Anwendungen die Fokusnachverfolgung nicht aktivieren, ohne die Unterstützung von WPF-Stift-/Touchgesten zu deaktivieren. Daher müssen WPF-Anwendungen zwischen der vollständigen WPF-Touchunterstützung oder der Windows-Maus-Heraufstufung wählen.

DPI pro Monitor

Um die jüngste Verbreitung von Umgebungen mit hohem DPI-Wert und Hybrid-DPI für WPF-Apps zu unterstützen, ermöglicht WPF in .NET Framework 4.6.2 die Sensibilisierung pro Monitor. Weitere Informationen dazu, wie Sie Ihre WPF-App für die Berücksichtigung von DPI-Werten pro Monitor aktivieren, finden Sie in den Beispielen und dem Entwicklerhandbuch auf GitHub.

In früheren Versionen von .NET Framework sind WPF-Apps system-DPI-fähig. Mit anderen Worten, die Benutzeroberfläche der Anwendung wird je nach DPI des Monitors, auf dem die App gerendert wird, entsprechend skaliert.

Für Apps, die unter .NET Framework 4.6.2 ausgeführt werden, können Sie DPI-Änderungen pro Monitor in WPF-Apps deaktivieren, indem Sie dem <Laufzeitabschnitt> Der Anwendungskonfigurationsdatei eine Konfigurationsanweisung hinzufügen:

<runtime>
   <AppContextSwitchOverrides value="Switch.System.Windows.DoNotScaleForDpiChanges=false"/>
</runtime>

Windows Workflow Foundation (WF)

In .NET Framework 4.6.2 wurde Windows Workflow Foundation im folgenden Bereich verbessert:

Unterstützung für C#-Ausdrücke und IntelliSense im rehosted WF Designer

Ab .NET Framework 4.5 unterstützt WF C#-Ausdrücke sowohl im Visual Studio Designer als auch in Codeworkflows. Der neu gehostete Workflow-Designer ist ein wichtiges Feature von WF, das es dem Workflow-Designer ermöglicht, sich in einer Anwendung außerhalb von Visual Studio (z. B. in WPF) zu befinden. Windows Workflow Foundation bietet die Möglichkeit, C#-Ausdrücke und IntelliSense im Rehosted Workflow Designer zu unterstützen. Weitere Informationen finden Sie im Windows Workflow Foundation-Blog.

Availability of IntelliSense when a customer rebuilds a workflow project from Visual Studio In Versionen von .NET Framework vor 4.6.2 wird WF Designer IntelliSense unterbrochen, wenn ein Kunde ein Workflowprojekt aus Visual Studio neu erstellt. Während der Projektbuild erfolgreich ist, werden die Workflowtypen im Designer nicht gefunden, und Warnungen von IntelliSense für die fehlenden Workflowtypen werden im Fenster " Fehlerliste " angezeigt. .NET Framework 4.6.2 behebt dieses Problem und stellt IntelliSense zur Verfügung.

Workflow V1-Anwendungen mit Workflowverfolgung werden jetzt im FIPS-Modus ausgeführt

Computer mit aktiviertem FIPS-Kompatibilitätsmodus können jetzt erfolgreich eine Workflowversion 1-Anwendung mit Workflownachverfolgung ausführen. Um dieses Szenario zu aktivieren, müssen Sie die folgende Änderung an Ihrer app.config Datei vornehmen:

<add key="microsoft:WorkflowRuntime:FIPSRequired" value="true" />

Wenn dieses Szenario nicht aktiviert ist, generiert die Anwendung weiterhin eine Ausnahme mit der Meldung "Diese Implementierung ist nicht Teil der überprüften Kryptografiealgorithmen der Windows-Plattform FIPS".

Workflowverbesserungen bei verwendung von dynamischem Update mit Visual Studio Workflow Designer

Workflow-Designer, FlowChart-Aktivitäts-Designer und andere Workflowaktivitäts-Designer laden und anzeigen workflows, die nach dem Aufrufen der DynamicUpdateServices.PrepareForUpdate Methode gespeichert wurden. In Versionen von .NET Framework vor .NET Framework 4.6.2 kann das Laden einer XAML-Datei in Visual Studio für einen Workflow, der nach dem Aufrufen DynamicUpdateServices.PrepareForUpdate gespeichert wurde, zu folgenden Problemen führen:

  • Der Workflow-Designer kann die XAML-Datei nicht ordnungsgemäß laden (wenn sich das ViewStateData.Id Ende der Zeile befindet).

  • Flussdiagramm-Aktivitäts-Designer oder andere Workflowaktivitäts-Designer können alle Objekte an ihren Standardspeicherorten anstelle angefügter Eigenschaftswerte anzeigen.

ClickOnce

ClickOnce wurde zusätzlich zum 1.0-Protokoll aktualisiert, um TLS 1.1 und TLS 1.2 zu unterstützen, das bereits unterstützt wird. ClickOnce erkennt automatisch, welches Protokoll erforderlich ist; Es sind keine zusätzlichen Schritte innerhalb der ClickOnce-Anwendung erforderlich, um die TLS 1.1- und 1.2-Unterstützung zu aktivieren.

Konvertieren von Windows Forms- und WPF-Apps in UWP-Apps

Windows bietet jetzt Funktionen zum Bereitstellen vorhandener Windows-Desktop-Apps, einschließlich WPF- und Windows Forms-Apps, zur universellen Windows-Plattform (UWP). Diese Technologie fungiert als Brücke, indem Sie Ihre vorhandene Codebasis schrittweise zu UWP migrieren können, wodurch Ihre App auf alle Windows 10-Geräte übertragen wird.

Konvertierte Desktop-Apps erhalten eine App-Identität, die der App-Identität von UWP-Apps ähnelt, wodurch UWP-APIs barrierefrei sind, um Features wie Live-Kacheln und Benachrichtigungen zu ermöglichen. Die App verhält sich weiterhin wie zuvor und wird als voll vertrauenswürdige App ausgeführt. Nachdem die App konvertiert wurde, kann ein App-Containerprozess dem vorhandenen voll vertrauenswürdigen Prozess hinzugefügt werden, um eine adaptive Benutzeroberfläche hinzuzufügen. Wenn alle Funktionen in den App-Containerprozess verschoben werden, kann der voll vertrauenswürdige Prozess entfernt werden, und die neue UWP-App kann allen Windows 10-Geräten zur Verfügung gestellt werden.

Debuggingverbesserungen

Die nicht verwaltete Debug-API wurde in .NET Framework 4.6.2 verbessert, um zusätzliche Analysen durchzuführen, wenn ein NullReferenceException Fehler ausgelöst wird, damit es möglich ist, zu bestimmen, welche Variable in einer einzelnen Zeile des Quellcodes ist null. Zur Unterstützung dieses Szenarios wurden die folgenden APIs der nicht verwalteten Debug-API hinzugefügt.

Neuerungen in .NET Framework 4.6.1

.NET Framework 4.6.1 enthält neue Features in den folgenden Bereichen:

Weitere Informationen zu .NET Framework 4.6.1 finden Sie in den folgenden Themen:

Kryptografie: Unterstützung für X509-Zertifikate mit ECDSA

.NET Framework 4.6 hat RSACng-Unterstützung für X509-Zertifikate hinzugefügt. .NET Framework 4.6.1 fügt Unterstützung für ECDSA-Zertifikate (Elliptic Curve Digital Signature Algorithm) X509 hinzu.

ECDSA bietet eine bessere Leistung und ist ein sichererer Kryptografiealgorithmus als RSA und bietet eine hervorragende Wahl, bei der die Leistung und Skalierbarkeit von Transport Layer Security (TLS) ein Problem darstellt. Die .NET Framework-Implementierung umschließt Aufrufe in vorhandene Windows-Funktionen.

Der folgende Beispielcode zeigt, wie einfach es ist, eine Signatur für einen Bytestream mithilfe der neuen Unterstützung für ECDSA X509-Zertifikate zu generieren, die in .NET Framework 4.6.1 enthalten sind.

using System;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

public class Net461Code
{
    public static byte[] SignECDsaSha512(byte[] data, X509Certificate2 cert)
    {
        using (ECDsa privateKey = cert.GetECDsaPrivateKey())
        {
            return privateKey.SignData(data, HashAlgorithmName.SHA512);
        }
    }

    public static byte[] SignECDsaSha512(byte[] data, ECDsa privateKey)
    {
        return privateKey.SignData(data, HashAlgorithmName.SHA512);
    }
}
Imports System.Security.Cryptography
Imports System.Security.Cryptography.X509Certificates

Public Class Net461Code
    Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
        Using privateKey As ECDsa = cert.GetECDsaPrivateKey()
            Return privateKey.SignData(data, HashAlgorithmName.SHA512)
        End Using
    End Function

    Public Shared Function SignECDsaSha512(data As Byte, privateKey As ECDsa) As Byte()
        Return privateKey.SignData(data, HashAlgorithmName.SHA512)
    End Function
End Class

Dies bietet einen markierten Kontrast zum Code, der zum Generieren einer Signatur in .NET Framework 4.6 erforderlich ist.

using System;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

public class Net46Code
{
    public static byte[] SignECDsaSha512(byte[] data, X509Certificate2 cert)
    {
        // This would require using cert.Handle and a series of p/invokes to get at the
        // underlying key, then passing that to a CngKey object, and passing that to
        // new ECDsa(CngKey).  It's a lot of work.
        throw new Exception("That's a lot of work...");
    }

    public static byte[] SignECDsaSha512(byte[] data, ECDsa privateKey)
    {
        // This way works, but SignData probably better matches what you want.
        using (SHA512 hasher = SHA512.Create())
        {
            byte[] signature1 = privateKey.SignHash(hasher.ComputeHash(data));
        }

        // This might not be the ECDsa you got!
        ECDsaCng ecDsaCng = (ECDsaCng)privateKey;
        ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512;
        return ecDsaCng.SignData(data);
    }
}
Imports System.Security.Cryptography
Imports System.Security.Cryptography.X509Certificates

Public Class Net46Code
    Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
        ' This would require using cert.Handle and a series of p/invokes to get at the
        ' underlying key, then passing that to a CngKey object, and passing that to
        ' new ECDsa(CngKey).  It's a lot of work.
        Throw New Exception("That's a lot of work...")
    End Function

    Public Shared Function SignECDsaSha512(data As Byte(), privateKey As ECDsa) As Byte()
        ' This way works, but SignData probably better matches what you want.
        Using hasher As SHA512 = SHA512.Create()
            Dim signature1 As Byte() = privateKey.SignHash(hasher.ComputeHash(data))
        End Using

        ' This might not be the ECDsa you got!
        Dim ecDsaCng As ECDsaCng = CType(privateKey, ECDsaCng)
        ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512
        Return ecDsaCng.SignData(data)
    End Function
End Class

ADO.NET

Der ADO.NET wurde Folgendes hinzugefügt:

Immer verschlüsselte Unterstützung für hardwaregeschützte Schlüssel

ADO.NET unterstützt jetzt das systemeigene Speichern von Hauptschlüsseln für immer verschlüsselte Spalten in Hardwaresicherheitsmodulen (HARDWARE Security Modules, HSMs). Mit dieser Unterstützung können Kunden asymmetrische Schlüssel nutzen, die in HSMs gespeichert sind, ohne benutzerdefinierte Hauptschlüsselspeicheranbieter für Spalten schreiben und in Anwendungen registrieren zu müssen.

Kunden müssen den vom HSM bereitgestellten CSP-Anbieter oder CNG-Schlüsselspeicheranbieter auf den App-Servern oder Clientcomputern installieren, um auf immer verschlüsselte Daten zuzugreifen, die mit in einem HSM gespeicherten Spaltenmasterschlüsseln geschützt sind.

Verbessertes MultiSubnetFailover Verbindungsverhalten für AlwaysOn

SqlClient stellt jetzt automatisch schnellere Verbindungen zu einer AlwaysOn Availability Group (AG) bereit. Sie erkennt transparent, ob Ihre Anwendung eine Verbindung mit einer AlwaysOn-Verfügbarkeitsgruppe (ALWAYSOn Availability Group, AG) in einem anderen Subnetz herstellt und schnell den aktuellen aktiven Server erkennt und eine Verbindung mit dem Server bereitstellt. Vor dieser Version musste eine Anwendung die Verbindungszeichenfolge festlegen, um "MultisubnetFailover=true" anzugeben, dass sie eine Verbindung mit einer AlwaysOn-Verfügbarkeitsgruppe herstellte. Ohne festlegen des Verbindungsstichworts auf true, kann eine Anwendung beim Herstellen einer Verbindung mit einer AlwaysOn-Verfügbarkeitsgruppe ein Timeout erleben. Mit dieser Version muss eine Anwendung nicht mehr auf MultiSubnetFailovertrue Weitere Informationen zur SqlClient-Unterstützung für Always On-Verfügbarkeitsgruppen finden Sie unter SqlClient-Unterstützung für hohe Verfügbarkeit, Notfallwiederherstellung.

Windows Presentation Foundation (WPF)

Windows Presentation Foundation enthält eine Reihe von Verbesserungen und Änderungen.

Verbesserte Leistung

Die Verzögerung beim Auslösen von Touchereignissen wurde in .NET Framework 4.6.1 behoben. Darüber hinaus bindet die Eingabe in ein RichTextBox Steuerelement den Renderthread während der schnellen Eingabe nicht mehr.

Verbesserungen bei der Rechtschreibprüfung

Die Rechtschreibprüfung in WPF wurde unter Windows 8.1 und höheren Versionen aktualisiert, um die Unterstützung des Betriebssystems für die Rechtschreibprüfung zusätzlicher Sprachen zu nutzen. Es gibt keine Änderung der Funktionalität in Windows-Versionen vor Windows 8.1.

Wie in früheren Versionen von .NET Framework wird die Sprache für ein TextBox Steuerelement oder einen RichTextBox Block erkannt, indem nach Informationen in der folgenden Reihenfolge gesucht wird:

  • xml:lang, wenn es vorhanden ist.

  • Aktuelle Eingabesprache.

  • Aktuelle Kultur.

Weitere Informationen zur Sprachunterstützung in WPF finden Sie im WPF-Blogbeitrag zu .NET Framework 4.6.1-Features.

Zusätzliche Unterstützung für benutzerspezifische Benutzerwörterbücher

In .NET Framework 4.6.1 erkennt WPF benutzerdefinierte Wörterbücher, die global registriert sind. Diese Funktion ist zusätzlich zur Möglichkeit verfügbar, sie pro Steuerelement zu registrieren.

In früheren Versionen von WPF wurden benutzerwörterbücher ausgeschlossene Wörter und AutoKorrektur-Listen nicht erkannt. Sie werden unter Windows 8.1 und Windows 10 über die Verwendung von Dateien unterstützt, die unter dem %AppData%\Microsoft\Spelling\<language tag> Verzeichnis platziert werden können. Die folgenden Regeln gelten für diese Dateien:

  • Die Dateien sollten Erweiterungen von dic (für hinzugefügte Wörter), EXC (für ausgeschlossene Wörter) oder ACL (für AutoKorrektur) enthalten.

  • Die Dateien sollten UTF-16 LE-Klartext sein, der mit dem Byte Order Mark (BOM) beginnt.

  • Jede Zeile sollte aus einem Wort (in den Listen hinzugefügter und ausgeschlossener Wörter) oder einem AutoKorrektur-Paar mit den Wörtern bestehen, die durch einen vertikalen Balken ("|") getrennt sind. (in der AutoKorrektur-Wortliste).

  • Diese Dateien gelten als schreibgeschützt und werden vom System nicht geändert.

Hinweis

Diese neuen Dateiformate werden von den WPF-Rechtschreibprüfungs-APIs nicht direkt unterstützt, und die für WPF in Anwendungen bereitgestellten Benutzerwörterbücher sollten weiterhin LEX-Dateien verwenden.

Beispiele

Im GitHub-Repository von Microsoft/WPF-Samples gibt es eine Reihe von WPF-Beispielen. Helfen Sie uns, unsere Beispiele zu verbessern, indem Sie uns eine Pull-Anforderung senden oder ein GitHub-Problem öffnen.

DirectX-Erweiterungen

WPF enthält ein NuGet-Paket , das neue Implementierungen bereitstellt, die es Ihnen erleichtern, mit DX10- und Dx11-Inhalten D3DImage zu arbeiten. Der Code für dieses Paket wurde geöffnet und ist auf GitHub verfügbar.

Windows Workflow Foundation: Transaktionen

Die Transaction.EnlistPromotableSinglePhase Methode kann nun einen anderen verteilten Transaktions-Manager als MSDTC verwenden, um die Transaktion zu bewerben. Dazu geben Sie einen GUID-Transaktionsträgerbezeichner für die neue Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) Überladung an. Wenn dieser Vorgang erfolgreich ist, gelten Einschränkungen für die Funktionen der Transaktion. Sobald ein Nicht-MSDTC-Transaktionsträger aufgelistet ist, lösen die folgenden Methoden einen TransactionPromotionException Ausstieg aus, da diese Methoden eine Heraufsufung auf MSDTC erfordern:

Sobald ein nicht-MSDTC-Transaktionsförderer in die Liste aufgenommen wurde, muss er für zukünftige dauerhafte Listen verwendet werden, indem protokolle verwendet werden, die er definiert. Der Guid Transaktionsförderer kann über die PromoterType Eigenschaft abgerufen werden. Wenn die Transaktion höhergestuft wird, stellt der Transaktionsförderer ein Byte Array bereit, das das höhergestufte Token darstellt. Eine Anwendung kann das höhergestufte Token für eine höhergestufte Transaktion ohne MSDTC mit der GetPromotedToken Methode abrufen.

Benutzer der neuen Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) Überladung müssen einer bestimmten Aufrufsequenz folgen, damit der Heraufsufungsvorgang erfolgreich abgeschlossen werden kann. Diese Regeln sind in der Dokumentation der Methode dokumentiert.

Profiling

Die nicht verwaltete Profilerstellungs-API wurde wie folgt verbessert:

  • Bessere Unterstützung für den Zugriff auf PDBs in der ICorProfilerInfo7-Schnittstelle .

    In ASP.NET Core wird es viel häufiger, dass Assemblys von Roslyn im Arbeitsspeicher kompiliert werden. Für Entwickler, die Profilerstellungstools erstellen, bedeutet dies, dass PDBs, die historisch auf dem Datenträger serialisiert wurden, möglicherweise nicht mehr vorhanden sind. Profiler-Tools verwenden häufig PDBs, um Code zurück zu Quellzeilen für Aufgaben wie Codeabdeckung oder zeilenweise Leistungsanalyse zuzuordnen. Die ICorProfilerInfo7-Schnittstelle enthält nun zwei neue Methoden: ICorProfilerInfo7::GetInMemorySymbolsLength und ICorProfilerInfo7::ReadInMemorySymbols, um diese Profilertools mit Zugriff auf die In-Memory-PDB-Daten bereitzustellen. Mithilfe der neuen APIs kann ein Profiler den Inhalt eines In-Memory-PDB-Objekts als Bytearray abrufen und dann auf datenträgerinterne Daten verarbeiten oder serialisieren.

  • Bessere Instrumentierung mit der ICorProfiler-Schnittstelle.

    Profilierer, die die ICorProfiler APIs ReJit-Funktionalität für dynamische Instrumentierung verwenden, können jetzt einige Metadaten ändern. Bisher konnten solche Tools die IL jederzeit instrumentieren, aber Metadaten konnten nur zum Ladezeitpunkt des Moduls geändert werden. Da IL sich auf Metadaten bezieht, beschränkt sich dies auf die Art der Instrumentierung, die durchgeführt werden kann. Einige dieser Grenzwerte wurden aufgehoben, indem wir die ICorProfilerInfo7::ApplyMetaData-Methode hinzufügen, um eine Teilmenge von Metadatenbearbeitungen nach dem Laden des Moduls zu unterstützen, insbesondere durch Hinzufügen neuer AssemblyRef, , TypeRef, TypeSpec, MemberRef, , MemberSpecund UserString Datensätze. Diese Änderung ermöglicht eine viel breitere Palette an On-the-Fly-Instrumentierung.

Native Image Generator (NGEN) PDBs

Die computerübergreifende Ereignisablaufverfolgung ermöglicht Es Kunden, ein Programm auf Computer A zu profilieren und die Profilerstellungsdaten mit der Quellzeilenzuordnung auf Computer B zu betrachten. Mit früheren Versionen von .NET Framework würde der Benutzer alle Module und systemeigenen Bilder vom profilierten Computer auf den Analysecomputer kopieren, der die IL PDB enthält, um die Quell-zu-systemeigene Zuordnung zu erstellen. Dieser Vorgang kann zwar gut funktionieren, wenn die Dateien relativ klein sind, z. B. für Telefonanwendungen, aber die Dateien können sehr groß auf Desktopsystemen sein und erhebliche Zeit zum Kopieren benötigen.

Mit Ngen-PDBs kann NGen einen PDB erstellen, der die IL-zu-native Zuordnung ohne Abhängigkeit von der IL-PDB enthält. In unserem szenario für die computerübergreifende Ereignisablaufverfolgung müssen Sie die systemeigene Image-PDB kopieren, die von Computer A auf Computer B generiert wird, und die Debug Interface Access-APIs verwenden, um die Quell-to-IL Zuordnung der IL-PDB und die native Image-PDB IL-zu-systemeigene Zuordnung zu lesen. Das Kombinieren beider Zuordnungen stellt eine quelleigene Zuordnung bereit. Da das native Image PDB viel kleiner als alle Module und nativen Images ist, ist der Kopiervorgang von Computer A auf Computer B viel schneller.

Neuerungen in .NET 2015

.NET 2015 führt .NET Framework 4.6 und .NET Core ein. Einige neue Features gelten sowohl für .NET Framework 4.6 als auch für .NET Core.

  • ASP.NET Core

    .NET 2015 enthält ASP.NET Core, eine schlanke .NET-Implementierung zum Erstellen moderner cloudbasierter Apps. ASP.NET Core ist modular, sodass Sie nur die Features einbeziehen können, die in Ihrer Anwendung benötigt werden. Sie kann in IIS oder selbst gehostet in einem benutzerdefinierten Prozess gehostet werden, und Sie können Apps mit verschiedenen Versionen von .NET Framework auf demselben Server ausführen. Es enthält ein neues Umgebungskonfigurationssystem, das für die Cloudbereitstellung entwickelt wurde.

    MVC, Web-API und Webseiten werden in einem einzigen Framework mit dem Namen MVC 6 vereinheitlicht. Sie erstellen ASP.NET Core-Apps mithilfe von Tools in Visual Studio 2015 oder höher. Ihre vorhandenen Anwendungen funktionieren im neuen .NET Framework. Um jedoch eine App zu erstellen, die MVC 6 oder SignalR 3 verwendet, müssen Sie das Projektsystem in Visual Studio 2015 oder höher verwenden.

    Weitere Informationen finden Sie unter ASP.NET Core.

  • ASP.NET Updates

    • Aufgabenbasierte API für asynchrones Leeren von Antworten

      ASP.NET stellt jetzt eine einfache aufgabenbasierte API für asynchrones Leeren von Antworten bereit, HttpResponse.FlushAsyncmit der Antworten asynchron durch die Unterstützung Ihrer Sprache async/await geleert werden können.

    • Modellbindung unterstützt Methoden für die Rückgabe von Aufgaben

      In .NET Framework 4.5 ASP.NET das Modellbindungsfeature hinzugefügt, das einen erweiterbaren, codeorientierten Ansatz für CRUD-basierte Datenvorgänge auf Webseiten und Benutzersteuerelementen ermöglichte. Das Modellbindungssystem unterstützt Taskjetzt Modellbindungsmethoden. Mit diesem Feature können Web Forms-Entwickler die Skalierbarkeitsvorteile von async mit der Leichtigkeit des Datenbindungssystems erhalten, wenn neuere Versionen von ORMs verwendet werden, einschließlich entity Framework.

      Die Asynchrone Modellbindung wird durch die aspnet:EnableAsyncModelBinding Konfigurationseinstellung gesteuert.

      <appSettings>
          <add key=" aspnet:EnableAsyncModelBinding" value="true|false" />
      </appSettings>
      

      In Apps ist das Ziel .NET Framework 4.6 standardmäßig auf true. In Apps, die auf .NET Framework 4.6 ausgeführt werden, die auf eine frühere Version von .NET Framework abzielen, ist false sie standardmäßig vorhanden. Sie kann durch Festlegen der Konfigurationseinstellung auf trueaktiviert werden.

    • HTTP/2-Unterstützung (Windows 10)

      HTTP/2 ist eine neue Version des HTTP-Protokolls, die eine wesentlich bessere Verbindungsauslastung (weniger Roundtrips zwischen Client und Server) bietet, was zu einer geringeren Latenz-Webseitenladezeit für Benutzer führt. Webseiten (im Gegensatz zu Diensten) profitieren am meisten von HTTP/2, da das Protokoll für mehrere Artefakte optimiert wird, die als Teil einer einzigen Oberfläche angefordert werden. Http/2-Unterstützung wurde zu ASP.NET in .NET Framework 4.6 hinzugefügt. Da Netzwerkfunktionen auf mehreren Ebenen vorhanden sind, wurden in Windows, in IIS und in ASP.NET neue Features benötigt, um HTTP/2 zu aktivieren. Sie müssen unter Windows 10 ausgeführt werden, um HTTP/2 mit ASP.NET zu verwenden.

      HTTP/2 wird auch für Windows 10-Apps für die universelle Windows-Plattform (UWP) unterstützt und standardmäßig aktiviert, die die System.Net.Http.HttpClient API verwenden.

      Um die PUSH_PROMISE-Funktion in ASP.NET Anwendungen zu verwenden, wurde der Klasse eine neue Methode mit zwei Überladungen PushPromise(String)PushPromise(String, String, NameValueCollection)hinzugefügt HttpResponse .

      Hinweis

      Während ASP.NET Core HTTP/2 unterstützt, wurde die Unterstützung für das PUSH PROMISE-Feature noch nicht hinzugefügt.

      Der Browser und der Webserver (IIS unter Windows) erledigen alle Aufgaben. Sie müssen keine schwere Hebelastung für Ihre Benutzer ausführen.

      Die meisten der wichtigsten Browser unterstützen HTTP/2, daher ist es wahrscheinlich, dass Ihre Benutzer von der HTTP/2-Unterstützung profitieren, wenn Ihr Server sie unterstützt.

    • Unterstützung für das Tokenbindungsprotokoll

      Microsoft und Google arbeiten an einem neuen Ansatz für die Authentifizierung zusammen, der als Token binding Protocol bezeichnet wird. Die Lokale Umgebung besteht darin, dass Authentifizierungstoken (im Browsercache) gestohlen und von Kriminellen für den Zugriff auf anderweitig sichere Ressourcen (z. B. Ihr Bankkonto) verwendet werden können, ohne dass Ihr Kennwort oder andere privilegierte Kenntnisse erforderlich sind. Das neue Protokoll zielt darauf ab, dieses Problem zu mindern.

      Das Tokenbindungsprotokoll wird in Windows 10 als Browserfeature implementiert. ASP.NET Apps werden am Protokoll teilnehmen, sodass Authentifizierungstoken als legitim überprüft werden. Der Client und die Serverimplementierungen richten den end-to-End-Schutz ein, der durch das Protokoll angegeben wird.

    • Zufällige Zeichenfolgenhashalgorithmen

      .NET Framework 4.5 hat einen zufälligen Zeichenfolgenhashalgorithmus eingeführt. Es wurde jedoch von ASP.NET aufgrund einiger ASP.NET Features nicht unterstützt, die von einem stabilen Hashcode abhängig sind. In .NET Framework 4.6 werden randomisierte Zeichenfolgenhashalgorithmen jetzt unterstützt. Verwenden Sie die aspnet:UseRandomizedStringHashAlgorithm Konfigurationseinstellung, um dieses Feature zu aktivieren.

      <appSettings>
          <add key="aspnet:UseRandomizedStringHashAlgorithm" value="true|false" />
      </appSettings>
      
  • ADO.NET

    ADO .NET unterstützt jetzt das Feature "Immer verschlüsselt", das in SQL Server 2016 verfügbar ist. Mit Always Encrypted kann SQL Server Vorgänge für verschlüsselte Daten ausführen, und am besten befindet sich der Verschlüsselungsschlüssel mit der Anwendung innerhalb der vertrauenswürdigen Umgebung des Kunden und nicht auf dem Server. Mit always Encrypted werden Kundendaten gesichert, sodass DBAs keinen Zugriff auf Nur-Text-Daten haben. Die Verschlüsselung und Entschlüsselung von Daten erfolgt transparent auf Treiberebene und minimiert Änderungen, die an vorhandenen Anwendungen vorgenommen werden müssen. Ausführliche Informationen finden Sie unter Always Encrypted (Database Engine) und Always Encrypted (Client Development).

  • 64-Bit-JIT-Compiler für verwalteten Code

    .NET Framework 4.6 verfügt über eine neue Version des 64-Bit-JIT-Compilers (ursprünglich mit Codename RyuJIT). Der neue 64-Bit-Compiler bietet erhebliche Leistungsverbesserungen gegenüber dem älteren 64-Bit-JIT-Compiler. Der neue 64-Bit-Compiler ist für 64-Bit-Prozesse aktiviert, die über .NET Framework 4.6 ausgeführt werden. Ihre App wird in einem 64-Bit-Prozess ausgeführt, wenn sie als 64-Bit- oder AnyCPU kompiliert wird und auf einem 64-Bit-Betriebssystem ausgeführt wird. Während es darum geht, den Übergang zum neuen Compiler so transparent wie möglich zu machen, sind Verhaltensänderungen möglich.

    Der neue 64-Bit-JIT-Compiler enthält auch Hardware-SIMD-Beschleunigungsfeatures, wenn sie mit SIMD-fähigen Typen im System.Numerics Namespace gekoppelt sind, was zu guten Leistungsverbesserungen führen kann.

  • Verbesserungen beim Assemblyladeprogramm

    Das Assemblyladeprogramm verwendet nun speichereffizienter, indem IL-Assemblys entladen werden, nachdem ein entsprechendes NGEN-Image geladen wurde. Diese Änderung verringert den virtuellen Speicher, was besonders für große 32-Bit-Apps (z. B. Visual Studio) von Vorteil ist und auch physischen Speicher speichert.

  • Änderungen der Basisklassenbibliothek

    Viele neue APIs wurden zu .NET Framework 4.6 hinzugefügt, um wichtige Szenarien zu ermöglichen. Dazu gehören die folgenden Änderungen und Ergänzungen:

    • IReadOnlyCollection<T-Implementierungen>

      Zusätzliche Auflistungen implementieren IReadOnlyCollection<T> , z Queue<T> . B. und Stack<T>.

    • CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture

      Die CultureInfo.CurrentCulture Eigenschaften sind CultureInfo.CurrentUICulture jetzt schreibgeschützt und nicht schreibgeschützt. Wenn Sie diesen Eigenschaften ein neues CultureInfo Objekt zuweisen, ändern sich auch die durch die Thread.CurrentThread.CurrentCulture Eigenschaft definierte aktuelle Threadkultur und die aktuelle UI-Threadkultur, die von den Thread.CurrentThread.CurrentUICulture Eigenschaften definiert wird.

    • Verbesserungen bei der Garbage Collection (GC)

      Die GC Klasse enthält jetzt und TryStartNoGCRegionEndNoGCRegion Methoden, mit denen Sie die Garbage Collection während der Ausführung eines kritischen Pfads nicht zulassen können.

      Mit einer neuen Überladung der GC.Collect(Int32, GCCollectionMode, Boolean, Boolean) Methode können Sie steuern, ob sowohl der Heap des kleinen Objekts als auch der Heap des großen Objekts geschwenkt und komprimiert oder nur geschwemmt werden.

    • SIMD-fähige Typen

      Der System.Numerics Namespace enthält jetzt eine Reihe von SIMD-fähigen Typen, zMatrix3x2. B. , , Matrix4x4, Plane, Quaternion, Vector2, und Vector3Vector4.

      Da der neue 64-Bit-JIT-Compiler auch Hardware-SIMD-Beschleunigungsfunktionen enthält, gibt es bei der Verwendung der SIMD-fähigen Typen mit dem neuen 64-Bit-JIT-Compiler besonders erhebliche Leistungsverbesserungen.

    • Kryptografieupdates

      Die System.Security.Cryptography API wird aktualisiert, um die Windows CNG-Kryptografie-APIs zu unterstützen. Frühere Versionen von .NET Framework basieren vollständig auf einer früheren Version der Windows-Kryptografie-APIs als Grundlage für die System.Security.Cryptography Implementierung. Wir hatten Anfragen zur Unterstützung der CNG-API, da sie moderne Kryptografiealgorithmen unterstützt, die für bestimmte Kategorien von Apps wichtig sind.

      .NET Framework 4.6 enthält die folgenden neuen Verbesserungen zur Unterstützung der Windows CNG-Kryptografie-APIs:

      • Eine Reihe von Erweiterungsmethoden für X509-Zertifikate System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2) und System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(System.Security.Cryptography.X509Certificates.X509Certificate2), die eine CNG-basierte Implementierung anstelle einer CAPI-basierten Implementierung zurückgeben, wenn möglich. (Einige Smartcards usw. erfordern weiterhin CAPI, und die APIs behandeln den Fallback).

      • Die System.Security.Cryptography.RSACng Klasse, die eine CNG-Implementierung des RSA-Algorithmus bereitstellt.

      • Verbesserungen an der RSA-API, sodass häufige Aktionen keine Umwandlung mehr erfordern. Zum Beispiel erfordert das Verschlüsseln von Daten mithilfe eines X509Certificate2 Objekts Code wie den folgenden in früheren Versionen von .NET Framework.

        RSACryptoServiceProvider rsa = (RSACryptoServiceProvider)cert.PrivateKey;
        byte[] oaepEncrypted = rsa.Encrypt(data, true);
        byte[] pkcs1Encrypted = rsa.Encrypt(data, false);
        
        Dim rsa As RSACryptoServiceProvider = CType(cert.PrivateKey, RSACryptoServiceProvider)
        Dim oaepEncrypted() As Byte = rsa.Encrypt(data, True)
        Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, False)
        

        Code, der die neuen Kryptografie-APIs in .NET Framework 4.6 verwendet, kann wie folgt umgeschrieben werden, um die Umwandlung zu vermeiden.

        RSA rsa = cert.GetRSAPrivateKey();
        if (rsa == null)
           throw new InvalidOperationException("An RSA certificate was expected");
        
        byte[] oaepEncrypted = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1);
        byte[] pkcs1Encrypted = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1);
        
        Dim rsa As RSA = cert.GetRSAPrivateKey()
        If rsa Is Nothing Then
            Throw New InvalidOperationException("An RSA certificate was expected")
        End If
        
        Dim oaepEncrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1)
        Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1)
        
    • Unterstützung für die Konvertierung von Datums- und Uhrzeitangaben in oder von Unix-Zeit

      Die folgenden neuen Methoden wurden der DateTimeOffset Struktur hinzugefügt, um die Konvertierung von Datums- und Uhrzeitwerten in oder von Unix-Zeit zu unterstützen:

    • Kompatibilitätsschalter

      Die AppContext Klasse fügt ein neues Kompatibilitätsfeature hinzu, mit dem Bibliotheksautoren einen einheitlichen Opt-Out-Mechanismus für neue Funktionen für ihre Benutzer bereitstellen können. Sie richtet einen lose gekoppelten Vertrag zwischen Komponenten ein, um eine Opt-Out-Anforderung zu kommunizieren. Diese Funktion ist in der Regel wichtig, wenn eine Änderung an vorhandenen Funktionen vorgenommen wird. Umgekehrt gibt es bereits eine implizite Opt-In für neue Funktionen.

      Mit AppContextdiesen Bibliotheken können Kompatibilitätsoptionen definiert und verfügbar gemacht werden, während code, der von ihnen abhängig ist, diese Schalter so festlegen können, dass sie sich auf das Bibliotheksverhalten auswirken. Standardmäßig stellen Bibliotheken die neue Funktionalität bereit, und sie ändern sie nur (d. h., sie stellen die vorherige Funktionalität bereit), wenn der Switch festgelegt ist.

      Eine Anwendung (oder Bibliothek) kann den Wert eines Schalters deklarieren (der immer ein Boolean Wert ist), den eine abhängige Bibliothek definiert. Der Schalter ist immer implizit false. Legen Sie den Schalter so fest, dass true er aktiviert wird. Explizites Festlegen des Schalters auf false das neue Verhalten.

      AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", true);
      
      AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", True)
      

      Die Bibliothek muss überprüfen, ob ein Consumer den Wert des Schalters deklariert hat und dann entsprechend darauf reagiert.

      if (!AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", out shouldThrow))
      {
          // This is the case where the switch value was not set by the application.
          // The library can choose to get the value of shouldThrow by other means.
          // If no overrides nor default values are specified, the value should be 'false'.
          // A false value implies the latest behavior.
      }
      
      // The library can use the value of shouldThrow to throw exceptions or not.
      if (shouldThrow)
      {
          // old code
      }
      else
      {
          // new code
      }
      
      If Not AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", shouldThrow) Then
          ' This is the case where the switch value was not set by the application.
          ' The library can choose to get the value of shouldThrow by other means.
          ' If no overrides nor default values are specified, the value should be 'false'.
          ' A false value implies the latest behavior.
      End If
      
      ' The library can use the value of shouldThrow to throw exceptions or not.
      If shouldThrow Then
          ' old code
      Else
          ' new code
      End If
      

      Es ist vorteilhaft, ein einheitliches Format für Switches zu verwenden, da sie ein formaler Vertrag sind, der von einer Bibliothek verfügbar gemacht wird. Es folgen zwei offensichtliche Formate.

      • Wechseln. namespace. switchname

      • Wechseln. bibliothek. switchname

    • Änderungen am aufgabenbasierten asynchronen Muster (TAP)

      Für Apps, die auf .NET Framework 4.6 abzielen, Task und Task<TResult> Objekte erben die Kultur und UI-Kultur des aufrufenden Threads. Das Verhalten von Apps, die auf frühere Versionen von .NET Framework abzielen oder nicht auf eine bestimmte Version von .NET Framework abzielen, ist davon unberührt. Weitere Informationen finden Sie im Abschnitt "Kultur und aufgabenbasierte asynchrone Vorgänge" des CultureInfo Klassenthemas.

      Mit der System.Threading.AsyncLocal<T> Klasse können Sie Umgebungsdaten darstellen, die für einen bestimmten asynchronen Steuerungsfluss lokal sind, z. B. eine async Methode. Sie kann verwendet werden, um Daten über Threads hinweg zu speichern. Sie können auch eine Rückrufmethode definieren, die benachrichtigt wird, wenn sich die Umgebungsdaten ändern, entweder weil die AsyncLocal<T>.Value Eigenschaft explizit geändert wurde oder weil der Thread einen Kontextübergang festgestellt hat.

      Dem aufgabenbasierten asynchronen Muster (TAP) wurden drei Komfortmethoden hinzugefügt, Task.CompletedTaskTask.FromCanceledTask.FromExceptionum abgeschlossene Aufgaben in einem bestimmten Zustand zurückzugeben.

      Die NamedPipeClientStream Klasse unterstützt jetzt die asynchrone Kommunikation mit dem neuen ConnectAsync. Methode.

    • EventSource unterstützt jetzt das Schreiben in das Ereignisprotokoll.

      Sie können jetzt die EventSource Klasse verwenden, um administrative oder betriebstechnische Nachrichten im Ereignisprotokoll zu protokollieren, zusätzlich zu vorhandenen ETW-Sitzungen, die auf dem Computer erstellt wurden. In der Vergangenheit mussten Sie das NuGet-Paket "Microsoft.Diagnostics.Tracing.EventSource" für diese Funktionalität verwenden. Diese Funktionalität ist jetzt in .NET Framework 4.6 integriert.

      Sowohl das NuGet-Paket als auch .NET Framework 4.6 wurden mit den folgenden Features aktualisiert:

      • Dynamische Ereignisse

        Ermöglicht Ereignisse, die "on the fly" definiert sind, ohne Ereignismethoden zu erstellen.

      • Umfangreiche Nutzlasten

        Ermöglicht die Übergabe von speziell attributierten Klassen und Arrays sowie grundtyptypen als Nutzlast

      • Aktivitätsnachverfolgung

        Bewirkt, dass Start- und Stop-Ereignisse Ereignisse zwischen ihnen mit einer ID markieren, die alle derzeit aktiven Aktivitäten darstellt.

      Um diese Features zu unterstützen, wurde der Klasse die überladene Write Methode hinzugefügt EventSource .

  • Windows Presentation Foundation (WPF)

    • HDPI-Verbesserungen

      Die HDPI-Unterstützung in WPF ist jetzt in .NET Framework 4.6 besser. Änderungen wurden vorgenommen, um das Layout runden zu ändern, um Instanzen von Beschneidungen in Steuerelementen mit Rahmen zu reduzieren. Dieses Feature ist standardmäßig nur aktiviert, wenn Sie TargetFrameworkAttribute auf .NET Framework 4.6 festgelegt sind. Anwendungen, die auf frühere Versionen des Frameworks abzielen, aber unter .NET Framework 4.6 ausgeführt werden, können sich für das neue Verhalten entscheiden, indem Sie der <Laufzeitabschnitt> der datei app.config die folgende Zeile hinzufügen:

      <AppContextSwitchOverrides
      value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false"
      />
      

      WPF-Fenster, die mehrere Monitore mit unterschiedlichen DPI-Einstellungen (Multi-DPI-Setup) überspannen, werden jetzt vollständig ohne abgeschwarzte Bereiche gerendert. Sie können dieses Verhalten deaktivieren, indem Sie dem <appSettings> Abschnitt der app.config-Datei die folgende Zeile hinzufügen, um dieses neue Verhalten zu deaktivieren:

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

      Unterstützung für das automatische Laden des rechten Cursors basierend auf der DPI-Einstellung wurde hinzugefügt System.Windows.Input.Cursor.

    • Toucheingabe ist besser

      Kundenberichte zu Connect , die zu unvorhersehbaren Verhaltensweisen führen, wurden in .NET Framework 4.6 behandelt. Der Schwellenwert für Doppeltippen für Windows Store-Anwendungen und WPF-Anwendungen ist jetzt in Windows 8.1 und höher identisch.

    • Transparente Unterstützung für untergeordnete Fenster

      WPF in .NET Framework 4.6 unterstützt transparente untergeordnete Fenster in Windows 8.1 und höher. Auf diese Weise können Sie nicht rechteckige und transparente untergeordnete Fenster in Ihren Fenstern der obersten Ebene erstellen. Sie können dieses Feature aktivieren, indem Sie die HwndSourceParameters.UsesPerPixelTransparency Eigenschaft auf true.

  • Windows Communication Foundation (WCF)

    • SSL-Unterstützung

      WCF unterstützt jetzt SSL-Version TLS 1.1 und TLS 1.2, zusätzlich zu SSL 3.0 und TLS 1.0, wenn NetTcp mit Transportsicherheit und Clientauthentifizierung verwendet wird. Es ist jetzt möglich, das zu verwendende Protokoll auszuwählen oder alte weniger sichere Protokolle zu deaktivieren. Dazu können Sie entweder die SslProtocols Eigenschaft festlegen oder einer Konfigurationsdatei Folgendes hinzufügen.

      <netTcpBinding>
          <binding>
            <security mode= "None|Transport|Message|TransportWithMessageCredential" >
                <transport clientCredentialType="None|Windows|Certificate"
                          protectionLevel="None|Sign|EncryptAndSign"
                          sslProtocols="Ssl3|Tls1|Tls11|Tls12">
                  </transport>
            </security>
          </binding>
      </netTcpBinding>
      
    • Senden von Nachrichten mit unterschiedlichen HTTP-Verbindungen

      WCF ermöglicht benutzern jetzt, sicherzustellen, dass bestimmte Nachrichten mit unterschiedlichen zugrunde liegenden HTTP-Verbindungen gesendet werden. Sie können auf zwei Arten vorgehen:

      • Verwenden eines Verbindungsgruppennamenpräfixes

        Benutzer können eine Zeichenfolge angeben, die WCF als Präfix für den Namen der Verbindungsgruppe verwendet. Zwei Nachrichten mit unterschiedlichen Präfixen werden mit unterschiedlichen zugrunde liegenden HTTP-Verbindungen gesendet. Sie legen das Präfix fest, indem Sie der Eigenschaft der Nachricht Message.Properties ein Schlüssel-Wert-Paar hinzufügen. Der Schlüssel lautet "HttpTransportConnectionGroupNamePrefix"; der Wert ist das gewünschte Präfix.

      • Verwenden verschiedener Kanalfabriken

        Benutzer können auch ein Feature aktivieren, das sicherstellt, dass nachrichten, die mit Kanälen gesendet werden, die von verschiedenen Kanalfabriken erstellt wurden, unterschiedliche zugrunde liegende HTTP-Verbindungen verwenden. Um dieses Feature zu aktivieren, müssen Benutzer Folgendes appSetting festlegen:true

        <appSettings>
            <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true" />
        </appSettings>
        
  • Windows Workflow Foundation (WWF)

    Sie können jetzt die Anzahl von Sekunden angeben, die ein Workflowdienst an einer Out-of-Order-Vorgangsanforderung hält, wenn eine ausstehende Textmarke "nicht protokolliert" vorhanden ist, bevor die Anforderung abgesenkt wird. Eine Textmarke ohne Protokoll ist eine Textmarke, die nicht mit ausstehenden Empfangsaktivitäten verknüpft ist. Einige Aktivitäten erstellen Nicht-Protokoll-Lesezeichen innerhalb ihrer Implementierung, sodass es möglicherweise nicht offensichtlich ist, dass eine Nicht-Protokoll-Textmarke vorhanden ist. Dazu gehören "Status" und "Auswählen". Wenn Sie also einen Workflowdienst mit einem Zustandsautomaten oder einer Auswahlaktivität implementiert haben, verfügen Sie höchstwahrscheinlich über Nicht-Protokoll-Lesezeichen. Sie geben das Intervall an, indem Sie dem Abschnitt Ihrer app.config Datei eine Zeile wie die folgende appSettings hinzufügen:

    <add key="microsoft:WorkflowServices:FilterResumeTimeoutInSeconds" value="60"/>
    

    Der Standardwert beträgt 60 Sekunden. Wenn value auf 0 festgelegt ist, werden Out-of-Order-Anforderungen sofort mit einem Fehler mit Text abgelehnt, der wie folgt aussieht:

    Operation 'Request3|{http://tempuri.org/}IService' on service instance with identifier '2b0667b6-09c8-4093-9d02-f6c67d534292' cannot be performed at this time. Please ensure that the operations are performed in the correct order and that the binding in use provides ordered delivery guarantees.
    

    Dies ist die gleiche Nachricht, die Sie erhalten, wenn eine Abwesenheitsvorgangsnachricht empfangen wird und keine Nicht-Protokoll-Lesezeichen vorhanden sind.

    Wenn der Wert des FilterResumeTimeoutInSeconds Elements ungleich Null ist, gibt es nicht protokollbezogene Textmarken, und das Timeoutintervall läuft ab, schlägt der Vorgang mit einer Timeoutmeldung fehl.

  • Transaktionen

    Sie können nun den verteilten Transaktionsbezeichner für die Transaktion einschließen, die eine Ausnahme verursacht hat, die von TransactionException dem Auslösen abgeleitet wurde. Dazu fügen Sie den appSettings folgenden Schlüssel zum Abschnitt Ihrer app.config Datei hinzu:

    <add key="Transactions:IncludeDistributedTransactionIdInExceptionMessage" value="true"/>
    

    Der Standardwert ist false.

  • Vernetzung

    • Socketwiederverwendung

      Windows 10 enthält einen neuen Hochskalierbarkeitsnetzwerkalgorithmus, der Computerressourcen besser nutzt, indem lokale Ports für ausgehende TCP-Verbindungen wiederverwenden. .NET Framework 4.6 unterstützt den neuen Algorithmus, sodass .NET-Apps das neue Verhalten nutzen können. In früheren Versionen von Windows gab es ein künstliches gleichzeitiges Verbindungslimit (in der Regel 16.384, die Standardgröße des dynamischen Portbereichs), was die Skalierbarkeit eines Diensts einschränken könnte, indem die Portauslastung beim Laden beeinträchtigt wird.

      In .NET Framework 4.6 wurden zwei APIs hinzugefügt, um die Portwiederverwendung zu ermöglichen, wodurch der Grenzwert von 64 KB für gleichzeitige Verbindungen effektiv entfernt wird:

      Standardmäßig ist ServicePointManager.ReusePort die false Eigenschaft nur dann festgelegt, wenn der HWRPortReuseOnSocketBind Wert des HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 Registrierungsschlüssels auf 0x1 festgelegt ist. Um die lokale Portwiederverwendung für HTTP-Verbindungen zu aktivieren, legen Sie die ServicePointManager.ReusePort Eigenschaft auf true. Dadurch werden alle ausgehenden TCP-Socketverbindungen von HttpClient und HttpWebRequest eine neue Windows 10-Socketoption SO_REUSE_UNICASTPORT verwendet, die die lokale Portwiederverwendung ermöglicht.

      Entwickler, die eine nur Sockets-Anwendung schreiben, können beim Aufrufen einer Methode die System.Net.Sockets.SocketOptionName Option angeben, z Socket.SetSocketOption . B. dass ausgehende Sockets lokale Ports während der Bindung wiederverwenden.

    • Unterstützung für internationale Domänennamen und PunyCode

      Der Klasse wurde eine neue Eigenschaft hinzugefügtIdnHost, Urium internationale Domänennamen und PunyCode besser zu unterstützen.

  • Ändern der Größe in Windows Forms-Steuerelementen

    Dieses Feature wurde in .NET Framework 4.6 erweitert, um das , , , und DomainUpDown die Typen und NumericUpDown das rechteck, das von der Eigenschaft angegeben wird, die DataGridViewComboBoxColumn beim Zeichnen einer DataGridViewColumn. ToolStripSplitButtonBoundsUITypeEditor

    Dies ist ein Opt-In-Feature. Um es zu EnableWindowsFormsHighDpiAutoResizing aktivieren, legen Sie das true Element in der Anwendungskonfigurationsdatei (app.config) fest:

    <appSettings>
        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
    </appSettings>
    
  • Unterstützung für Codeseitencodierungen

    .NET Core unterstützt in erster Linie die Unicode-Codierungen und bietet standardmäßig eingeschränkte Unterstützung für Codeseitencodierungen. Sie können Unterstützung für Codeseitencodierungen hinzufügen, die in .NET Framework verfügbar sind, aber in .NET Core nicht unterstützt werden, indem Sie Codeseitencodierungen mit der Encoding.RegisterProvider Methode registrieren. Weitere Informationen finden Sie unter System.Text.CodePagesEncodingProvider.

  • .NET Native

Apps für die universelle Windows-Plattform (UWP), die in C# oder Visual Basic geschrieben wurden, können von einer neuen Technologie profitieren, mit der Apps in systemeigenem Code kompiliert werden, anstatt in IL. Diese Technologie erzeugt Apps mit schnelleren Start- und Ausführungszeiten. Weitere Informationen finden Sie unter Kompilieren von Apps mit .NET Native. Eine Übersicht über .NET Native, die untersucht, wie sie sich von JIT-Kompilierung und NGEN unterscheidet und was für Ihren Code bedeutet, finden Sie unter .NET Native und Compilation.

Ihre Apps werden standardmäßig in systemeigenem Code kompiliert, wenn Sie sie mit Visual Studio 2015 oder höher kompilieren. Weitere Informationen finden Sie unter "Erste Schritte mit .NET Native".

Um das Debuggen von .NET Native-Apps zu unterstützen, wurden der nicht verwalteten Debugging-API neue Schnittstellen und Enumerationen hinzugefügt. Weitere Informationen finden Sie unter Debugging (Referenz zur nicht verwalteten API).

Neuerungen in .NET Framework 4.5.2

  • Neue APIs für ASP.NET-Apps. Mit den neuen HttpResponse.AddOnSendingHeaders Methoden HttpResponseBase.AddOnSendingHeaders können Sie Antwortheader und Statuscode prüfen und ändern, während die Antwort auf die Client-App geleert wird. Erwägen Sie, diese Methoden anstelle der PreSendRequestHeadersPreSendRequestContent Ereignisse zu verwenden; sie sind effizienter und zuverlässiger.

    Mit der HostingEnvironment.QueueBackgroundWorkItem Methode können Sie kleine Hintergrundarbeitselemente planen. ASP.NET verfolgt diese Elemente und verhindert, dass IIS den Arbeitsprozess abrupt beendet, bis alle Hintergrundarbeitselemente abgeschlossen sind. Diese Methode kann nicht außerhalb einer ASP.NET verwalteten App-Domäne aufgerufen werden.

    Die neuen HttpResponse.HeadersWritten Und HttpResponseBase.HeadersWritten Eigenschaften geben boolesche Werte zurück, die angeben, ob die Antwortheader geschrieben wurden. Sie können diese Eigenschaften verwenden, um sicherzustellen, dass Aufrufe von APIs wie HttpResponse.StatusCode (die Ausnahmen auslösen, wenn die Header geschrieben wurden) erfolgreich ausgeführt werden.

  • Ändern der Größe in Windows Forms-Steuerelementen Dieses Feature wurde erweitert. Sie können nun die System-DPI-Einstellung verwenden, um die Größe der Komponenten der folgenden zusätzlichen Steuerelemente zu ändern (z. B. den Dropdownpfeil in Kombinationsfeldern):

    Dies ist ein Opt-In-Feature. Um es zu EnableWindowsFormsHighDpiAutoResizing aktivieren, legen Sie das true Element in der Anwendungskonfigurationsdatei (app.config) fest:

    <appSettings>
        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
    </appSettings>
    
  • Neues Workflowfeature. Ein Ressourcenmanager, der die EnlistPromotableSinglePhase Methode verwendet (und daher die IPromotableSinglePhaseNotification Schnittstelle implementiert), kann die neue Transaction.PromoteAndEnlistDurable Methode verwenden, um Folgendes anzufordern:

    Dies kann innerhalb derselben App-Domäne erfolgen und erfordert keinen zusätzlichen nicht verwalteten Code, um mit MSDTC zu interagieren, um die Heraufstufung durchzuführen. Die neue Methode kann nur aufgerufen werden, wenn es einen ausstehenden Aufruf von System.Transactions der Methode gibt, die IPromotableSinglePhaseNotificationPromote von der promotable-Liste implementiert wird.

  • Verbesserungen bei der Profilerstellung. Die folgenden neuen nicht verwalteten Profilerstellungs-APIs bieten robustere Profilerstellung:

    Frühere ICorProfiler Implementierungen unterstützten das faule Laden abhängiger Assemblys. Die neuen Profilerstellungs-APIs erfordern abhängige Assemblys, die vom Profiler eingefügt werden, um sofort zu laden, anstatt geladen zu werden, nachdem die App vollständig initialisiert wurde. Diese Änderung wirkt sich nicht auf Benutzer der vorhandenen ICorProfiler APIs aus.

  • Debuggingverbesserungen. Die folgenden neuen nicht verwalteten Debugging-APIs bieten eine bessere Integration in einen Profiler. Sie können jetzt auf vom Profiler eingefügte Metadaten sowie lokale Variablen und Code zugreifen, die von Compiler-ReJIT-Anforderungen beim Dumpdebugging erstellt werden.

  • Ereignisablaufverfolgungsänderungen. .NET Framework 4.5.2 ermöglicht out-of-process, Event Tracing for Windows (ETW)-basierte Aktivitätsablaufverfolgung für einen größeren Oberflächenbereich. Auf diese Weise können APM-Anbieter (Advanced Power Management) einfache Tools bereitstellen, mit denen die Kosten einzelner Anforderungen und Aktivitäten, die Threads überschreiten, genau nachverfolgt werden. Diese Ereignisse werden nur ausgelöst, wenn ETW-Controller sie aktivieren; Daher wirken sich die Änderungen nicht auf zuvor geschriebenen ETW-Code oder Code aus, der mit deaktivierter ETW-Ausführung ausgeführt wird.

  • Fördern einer Transaktion und Konvertieren in eine dauerhafte Einlistung

    Transaction.PromoteAndEnlistDurable ist eine neue API, die .NET Framework 4.5.2 und 4.6 hinzugefügt wurde:

    [System.Security.Permissions.PermissionSetAttribute(System.Security.Permissions.SecurityAction.LinkDemand, Name = "FullTrust")]
    public Enlistment PromoteAndEnlistDurable(Guid resourceManagerIdentifier,
                                              IPromotableSinglePhaseNotification promotableNotification,
                                              ISinglePhaseNotification enlistmentNotification,
                                              EnlistmentOptions enlistmentOptions)
    
    <System.Security.Permissions.PermissionSetAttribute(System.Security.Permissions.SecurityAction.LinkDemand, Name:="FullTrust")>
    public Function PromoteAndEnlistDurable(resourceManagerIdentifier As Guid,
                                            promotableNotification As IPromotableSinglePhaseNotification,
                                            enlistmentNotification As ISinglePhaseNotification,
                                            enlistmentOptions As EnlistmentOptions) As Enlistment
    

    Die Methode kann von einer Liste verwendet werden, die zuvor als Transaction.EnlistPromotableSinglePhase Reaktion auf die ITransactionPromoter.Promote Methode erstellt wurde. Sie fordert System.Transactions auf, die Transaktion in eine MSDTC-Transaktion zu bewerben und die Promotable-Einlistung in eine dauerhafte Einlistung zu konvertieren. Nachdem diese Methode erfolgreich abgeschlossen wurde, wird auf die IPromotableSinglePhaseNotification Schnittstelle nicht mehr verwiesen System.Transactions, und zukünftige Benachrichtigungen werden auf der bereitgestellten ISinglePhaseNotification Schnittstelle eingehen. Die fragliche Auflistung muss als dauerhafte Einlistung dienen, die Transaktionsprotokollierung und -wiederherstellung unterstützen. Einzelheiten finden Sie unter Transaction.EnlistDurable. Darüber hinaus muss die Einlistung unterstützt werden ISinglePhaseNotification. Diese Methode kann nur während der Verarbeitung eines Aufrufs ITransactionPromoter.Promote aufgerufen werden. Wenn dies nicht der Fall ist, wird eine TransactionException Ausnahme ausgelöst.

Neuerungen in .NET Framework 4.5.1

Updates für April 2014:

  • Visual Studio 2013 Update 2 enthält Updates für die Vorlagen der portablen Klassenbibliothek, um diese Szenarien zu unterstützen:

    • Sie können Windows-Runtime-APIs in tragbaren Bibliotheken verwenden, die auf Windows 8.1, Windows Phone 8.1 und Windows Phone Silverlight 8.1 abzielen.

    • Sie können XAML-Typen (Windows.UI.XAML-Typen) in tragbare Bibliotheken einschließen, wenn Sie auf Windows 8.1 oder Windows Phone 8.1 abzielen. Die folgenden XAML-Vorlagen werden unterstützt: Leere Seite, Ressourcenwörterbuch, Vorlagensteuerelement und Benutzersteuerelement.

    • Sie können eine portable Windows-Runtime-Komponente (WINMD-Datei) für die Verwendung in Store-Apps erstellen, die auf Windows 8.1 und Windows Phone 8.1 abzielen.

    • Sie können eine Windows Store- oder Windows Phone Store-Klassenbibliothek wie eine portable Klassenbibliothek neu zuweisen.

    Weitere Informationen zu diesen Änderungen finden Sie unter Portable Class Library.

  • Der .NET Framework-Inhaltssatz enthält jetzt dokumentation für .NET Native, eine Vorkompilierungstechnologie zum Erstellen und Bereitstellen von Windows-Apps. .NET Native kompiliert Ihre Apps direkt in systemeigenen Code und nicht in Zwischensprache (IL), um eine bessere Leistung zu erzielen. Ausführliche Informationen finden Sie unter Kompilieren von Apps mit .NET Native.

  • Die .NET Framework-Referenzquelle bietet eine neue Browserumgebung und erweiterte Funktionalität. Sie können nun den .NET Framework-Quellcode online durchsuchen, die Referenz für die Offlineanzeige herunterladen und während des Debuggens die Quellen (einschließlich Patches und Updates) durchlaufen. Weitere Informationen finden Sie im Blogeintrag Eine neue Suche nach .NET-Referenzquelle.

Zu den neuen Features und Verbesserungen in den Basisklassen in .NET Framework 4.5.1 gehören:

  • Automatische Bindungsumleitung für Assemblys. Ab Visual Studio 2013 wird beim Kompilieren einer App, die auf .NET Framework 4.5.1 ausgerichtet ist, möglicherweise Bindungsumleitungen zur App-Konfigurationsdatei hinzugefügt, wenn Ihre App oder ihre Komponenten auf mehrere Versionen derselben Assembly verweisen. Sie können dieses Feature auch für Projekte aktivieren, die auf ältere Versionen von .NET Framework abzielen. Weitere Informationen finden Sie unter How to: Enable and Disable Automatic Binding Redirection.

  • Möglichkeit zum Sammeln von Diagnoseinformationen, um Entwicklern zu helfen, die Leistung von Server- und Cloudanwendungen zu verbessern. Weitere Informationen finden Sie unter den WriteEventWithRelatedActivityId Und WriteEventWithRelatedActivityIdCore Methoden in der EventSource Klasse.

  • Die Möglichkeit zum expliziten Komprimieren des Heaps für große Objekte (LOH) während der Garbage Collection. Weitere Informationen finden Sie in der GCSettings.LargeObjectHeapCompactionMode Eigenschaft.

  • Zusätzliche Leistungsverbesserungen wie ASP.NET Anhalten der App, Verbesserungen am Multi-Core-JIT und schnelleres Starten von Apps nach einem .NET Framework-Update. Ausführliche Informationen finden Sie in der .NET Framework 4.5.1-Ankündigung und im Blogbeitrag zum anhalten der ASP.NET App .

Zu den Verbesserungen von Windows Forms gehören:

  • Ändern der Größe in Windows Forms-Steuerelementen Sie können die System-DPI-Einstellung verwenden, um die Größe von Steuerelementkomponenten (z. B. die Symbole, die in einem Eigenschaftenraster angezeigt werden) zu ändern, indem Sie sich mit einem Eintrag in der Anwendungskonfigurationsdatei (app.config) für Ihre App anmelden. Dieses Feature wird derzeit in den folgenden Windows Forms-Steuerelementen unterstützt:

    Um dieses Feature zu aktivieren, fügen Sie der Konfigurationsdatei (app.config) ein neues <appSettings> Element hinzu, und legen Sie das EnableWindowsFormsHighDpiAutoResizing Element auf :true

    <appSettings>
        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
    </appSettings>
    

Verbesserungen beim Debuggen Ihrer .NET Framework-Apps in Visual Studio 2013 umfassen:

  • Gibt Werte im Visual Studio-Debugger zurück. Wenn Sie eine verwaltete App in Visual Studio 2013 debuggen, zeigt das Fenster "Autos" Rückgabetypen und -werte für Methoden an. Diese Informationen sind für Desktop-, Windows Store- und Windows Phone-Apps verfügbar. Weitere Informationen finden Sie unter Untersuchen der Rückgabewerte von Methodenaufrufen.

  • Bearbeiten und Fortfahren für 64-Bit-Apps. Visual Studio 2013 unterstützt das Feature "Bearbeiten und Fortsetzen" für 64-Bit-verwaltete Apps für Desktop, Windows Store und Windows Phone. Die bestehenden Einschränkungen bleiben sowohl für 32-Bit- als auch für 64-Bit-Apps gültig (siehe letzten Abschnitt des Artikels "Unterstützte Codeänderungen(C#) ").

  • Asynchrones Debuggen. Um das Debuggen asynchroner Apps in Visual Studio 2013 zu vereinfachen, blendet der Aufrufstapel den Infrastrukturcode aus, der von Compilern bereitgestellt wird, um die asynchrone Programmierung zu unterstützen, und auch Ketten in logischen übergeordneten Frames, sodass Sie die logische Programmausführung klarer verfolgen können. Ein Aufgabenfenster ersetzt das Fenster "Parallele Vorgänge" und zeigt Vorgänge an, die sich auf einen bestimmten Haltepunkt beziehen, und zeigt auch alle anderen Vorgänge an, die derzeit in der App aktiv oder geplant sind. Sie können dieses Feature im Abschnitt "Async-aware debugging" der Ankündigung von .NET Framework 4.5.1 lesen.

  • Bessere Ausnahmeunterstützung für Komponenten für Windows-Runtime. In Windows 8.1 erhalten Ausnahmen, die sich aus Windows Store-Apps ergeben, Informationen zu dem Fehler, der die Ausnahme verursacht hat, auch über Sprachgrenzen hinweg. Sie können dieses Feature im Abschnitt "Entwicklung von Windows Store-Apps" der Ankündigung von .NET Framework 4.5.1 lesen.

Ab Visual Studio 2013 können Sie das Managed Profile Guided Optimization Tool (Mpgo.exe) verwenden, um Windows 8.x Store-Apps sowie Desktop-Apps zu optimieren.

Informationen zu neuen Features in ASP.NET 4.5.1 finden Sie in den Versionshinweisen zu ASP.NET und Webtools für Visual Studio 2013.

Neuerungen in .NET Framework 4.5

Basisklassen

  • Möglichkeit, Systemneustarts zu reduzieren, indem .NET Framework 4-Anwendungen während der Bereitstellung erkannt und geschlossen werden. Siehe Reduzieren von Systemneustarts während .NET Framework 4.5-Installationen.

  • Unterstützung für Arrays, die größer als 2 Gigabyte (GB) auf 64-Bit-Plattformen sind. Dieses Feature kann in der Anwendungskonfigurationsdatei aktiviert werden. Sehen Sie sich das <gcAllowVeryLargeObjects> Element an, das auch andere Einschränkungen für die Objektgröße und die Arraygröße auflistet.

  • Bessere Leistung durch die Garbage Collection im Hintergrund für Server. Wenn Sie die Server garbage Collection in .NET Framework 4.5 verwenden, wird die Garbage Collection im Hintergrund automatisch aktiviert. Weitere Informationen finden Sie im Abschnitt "Garbage Collection" des Abschnitts "Grundlagen der Garbage Collection" des Hintergrundservers .

  • Die Just-in-Time-Kompilierung (Just-in-Time, JIT) im Hintergrund, die optional auf Multi-Core-Prozessoren verfügbar ist, um die Anwendungsleistung zu verbessern. Siehe ProfileOptimization.

  • Die Möglichkeit, zu begrenzen, wie lange das Modul für reguläre Ausdrücke versucht, einen regulären Ausdruck aufzulösen, bevor ein Zeitlimit überschritten wird. Siehe die Regex.MatchTimeout Eigenschaft.

  • Möglichkeit zum Definieren der Standardkultur für eine Anwendungsdomäne. Sehen Sie sich die Klasse an CultureInfo .

  • Konsolenunterstützung für unicode-Codierung (UTF-16). Sehen Sie sich die Klasse an Console .

  • Unterstützung für die Versionsverwaltung von Kulturzeichenfolgenreihenfolgen und Vergleichsdaten. Sehen Sie sich die Klasse an SortVersion .

  • Bessere Leistung beim Abrufen von Ressourcen. Siehe "Packen und Bereitstellen von Ressourcen".

  • Verbesserungen bei der Zip-Komprimierung, um die Größe einer komprimierten Datei zu verringern. Siehe den System.IO.Compression Namespace.

  • Möglichkeit zum Anpassen eines Spiegelungskontexts, um das Standardspiegelungsverhalten über die CustomReflectionContext Klasse außer Kraft zu setzen.

  • Unterstützung für die Version 2008 des Internationalized Domain Names in Applications (IDNA)-Standards, wenn die System.Globalization.IdnMapping Klasse unter Windows 8 verwendet wird.

  • Delegierung von Zeichenfolgenvergleich mit dem Betriebssystem, das Unicode 6.0 implementiert, wenn .NET Framework unter Windows 8 verwendet wird. Wenn sie auf anderen Plattformen ausgeführt wird, enthält .NET Framework eigene Zeichenfolgenvergleichsdaten, die Unicode 5.x implementiert. String Weitere Informationen finden Sie im Abschnitt "Kurs" und "Hinweise" der SortVersion Klasse.

  • Die Möglichkeit, die Hashcodes für Zeichenfolgen pro Anwendungsdomäne zu berechnen. Siehe <UseRandomizedStringHashAlgorithm> Element.

  • Typreflektion unterstützt die Aufteilung zwischen Type und TypeInfo Klassen. Siehe Reflection in .NET Framework für Windows Store-Apps.

Verwaltetes Erweiterbarkeits-Framework (MEF)

In .NET Framework 4.5 bietet das Managed Extensibility Framework (MEF) die folgenden neuen Features:

  • Unterstützung für generische Typen.

  • Konventionsbasiertes Programmiermodell, mit dem Sie Teile basierend auf Benennungskonventionen anstelle von Attributen erstellen können.

  • Mehrere Bereiche.

  • Eine Teilmenge von MEF, die Sie beim Erstellen von Windows 8.x Store-Apps verwenden können. Diese Teilmenge ist als herunterladbares Paket aus dem NuGet-Katalog verfügbar. Um das Paket zu installieren, öffnen Sie Ihr Projekt in Visual Studio, wählen Sie "NuGet-Pakete verwalten" im Menü "Projekt " aus, und suchen Sie online nach dem Microsoft.Composition Paket.

Weitere Informationen finden Sie unter Managed Extensibility Framework (MEF).

Asynchrone Dateivorgänge

In .NET Framework 4.5 wurden den Sprachen C# und Visual Basic neue asynchrone Features hinzugefügt. Diese Features fügen ein aufgabenbasiertes Modell zum Ausführen asynchroner Vorgänge hinzu. Um dieses neue Modell zu verwenden, verwenden Sie die asynchronen Methoden in den E/A-Klassen. Siehe Asynchrone Datei-E/A.

Tools

In .NET Framework 4.5 können Sie mit dem Ressourcendateigenerator (Resgen.exe) eine RESW-Datei für die Verwendung in Windows 8.x Store-Apps aus einer .NET Framework-Datei erstellen, die in einer .NET Framework-Assembly eingebettet ist. Weitere Informationen finden Sie unter Resgen.exe (Ressourcendatei-Generator).For more information, seeResgen.exe (Resource File Generator).

Managed Profile Guided Optimization (Mpgo.exe) ermöglicht es Ihnen, die Startzeit der Anwendung, die Speicherauslastung (Arbeitssatzgröße) und den Durchsatz zu verbessern, indem Sie systemeigene Imageassemblys optimieren. Das Befehlszeilentool generiert Profildaten für systemeigene Imageanwendungsassemblys. Siehe Mpgo.exe (Managed Profile Guided Optimization Tool). Ab Visual Studio 2013 können Sie Mpgo.exe verwenden, um Windows 8.x Store-Apps sowie Desktop-Apps zu optimieren.

Paralleles Computing

.NET Framework 4.5 bietet mehrere neue Features und Verbesserungen für parallele Computer. Dazu gehören verbesserte Leistung, erhöhte Kontrolle, verbesserte Unterstützung für asynchrone Programmierung, eine neue Datenflussbibliothek und verbesserte Unterstützung für paralleles Debuggen und Leistungsanalyse. Lesen Sie den Eintrag What's New for Parallelism in .NET Framework 4.5 im Blog "Parallel Programming with .NET".

das Internet

ASP.NET 4.5 und 4.5.1 fügen Modellbindung für Webformulare, WebSocket-Unterstützung, asynchrone Handler, Leistungsverbesserungen und viele andere Features hinzu. Weitere Informationen finden Sie in den folgenden Ressourcen:

Vernetzung

.NET Framework 4.5 bietet eine neue Programmierschnittstelle für HTTP-Anwendungen. Weitere Informationen finden Sie in den neuen System.Net.Http Namespaces System.Net.Http.Headers .

Unterstützung ist auch für eine neue Programmierschnittstelle zum Akzeptieren und Interagieren mit einer WebSocket-Verbindung mithilfe der vorhandenen HttpListener und verwandten Klassen enthalten. Weitere Informationen finden Sie im neuen System.Net.WebSockets Namespace und in der HttpListener Klasse.

Darüber hinaus enthält .NET Framework 4.5 die folgenden Netzwerkverbesserungen:

  • RFC-kompatible URI-Unterstützung. Weitere Informationen finden Sie unter Uri und verwandte Klassen.

  • Unterstützung für die Analyse von Internationalized Domain Name (IDN). Weitere Informationen finden Sie unter Uri und verwandte Klassen.

  • Unterstützung für E-Mail-Adresse Internationalization (EAI). Weitere Informationen finden Sie im System.Net.Mail Namespace.

  • Verbesserte IPv6-Unterstützung. Weitere Informationen finden Sie im System.Net.NetworkInformation Namespace.

  • Unterstützung des Dualmodus-Sockets. Weitere Informationen finden Sie unter den Socket Und TcpListener Klassen.

Windows Presentation Foundation (WPF)

In .NET Framework 4.5 enthält Windows Presentation Foundation (WPF) Änderungen und Verbesserungen in den folgenden Bereichen:

  • Das neue Ribbon Steuerelement, mit dem Sie eine Menüband-Benutzeroberfläche implementieren können, die eine Symbolleiste für den Schnellzugriff, ein Anwendungsmenü und Registerkarten hostet.

  • Die neue INotifyDataErrorInfo Schnittstelle, die synchrone und asynchrone Datenüberprüfung unterstützt.

  • Neue Features für die VirtualizingPanel und Dispatcher Klassen.

  • Verbesserte Leistung beim Anzeigen großer Gruppen gruppierter Daten und durch Den Zugriff auf Sammlungen auf Nicht-UI-Threads.

  • Datenbindung an statische Eigenschaften, Datenbindung an benutzerdefinierte Typen, die die ICustomTypeProvider Schnittstelle implementieren, und Abrufen von Datenbindungsinformationen aus einem Bindungsausdruck.

  • Ändern der Position von Daten, wenn sich die Werte ändern (Livestrukturierung).

  • Möglichkeit, zu überprüfen, ob der Datenkontext für einen Elementcontainer getrennt ist.

  • Möglichkeit zum Festlegen der Zeitspanne, die zwischen Eigenschaftsänderungen und Datenquellenaktualisierungen verstrichen werden soll.

  • Verbesserte Unterstützung für die Implementierung schwacher Ereignismuster. Ereignisse können jetzt Markuperweiterungen akzeptieren.

Windows Communication Foundation (WCF)

In .NET Framework 4.5 wurden die folgenden Features hinzugefügt, um das Schreiben und Verwalten von Windows Communication Foundation (WCF)-Anwendungen zu vereinfachen:

  • Vereinfachung der generierten Konfigurationsdateien.

  • Unterstützung für die Vertragsentwicklung.

  • Die Möglichkeit, ASP.NET Kompatibilitätsmodus einfacher zu konfigurieren.

  • Änderungen an Standard-Transporteigenschaftenwerten, um die Wahrscheinlichkeit zu verringern, dass Sie sie festlegen müssen.

  • Aktualisiert die XmlDictionaryReaderQuotas Klasse, um die Wahrscheinlichkeit zu verringern, dass Sie Kontingente für XML-Wörterbuchleser manuell konfigurieren müssen.

  • Überprüfung von WCF-Konfigurationsdateien durch Visual Studio als Teil des Buildprozesses, sodass Sie Konfigurationsfehler erkennen können, bevor Sie Ihre Anwendung ausführen.

  • Neue asynchrone Streamingunterstützung.

  • Neue HTTPS-Protokollzuordnung, um es einfacher zu machen, einen Endpunkt über HTTPS mit Internetinformationsdienste (Internet Information Services, IIS) verfügbar zu machen.

  • Möglichkeit zum Generieren von Metadaten in einem einzelnen WSDL-Dokument durch Anfügen ?singleWSDL an die Dienst-URL.

  • Websockets unterstützen die echte bidirektionale Kommunikation über ports 80 und 443 mit Leistungsmerkmalen, die dem TCP-Transport ähneln.

  • Unterstützung für die Konfiguration von Diensten im Code.

  • XML-Editor-QuickInfos.

  • ChannelFactory Unterstützung für das Zwischenspeichern.

  • Unterstützung für binäre Encoderkomprimierung.

  • Unterstützung für einen UDP-Transport, mit dem Entwickler Dienste schreiben können, die "Fire and Forget"-Nachrichten verwenden. Ein Client sendet eine Nachricht an einen Dienst und erwartet keine Antwort vom Dienst.

  • Möglichkeit zur Unterstützung mehrerer Authentifizierungsmodi auf einem einzelnen WCF-Endpunkt bei Verwendung der HTTP-Transport- und Transportsicherheit.

  • Unterstützung für WCF-Dienste, die internationalisierte Domänennamen (IDNs) verwenden.

Weitere Informationen finden Sie unter What's New in Windows Communication Foundation.

Windows Workflow Foundation (WF)

In .NET Framework 4.5 wurden mehrere neue Features zu Windows Workflow Foundation (WF) hinzugefügt, darunter:

  • Zustandsautomatworkflows, die erstmals als Teil von .NET Framework 4.0.1 (.NET Framework 4 Platform Update 1) eingeführt wurden. Dieses Update enthält mehrere neue Klassen und Aktivitäten, mit denen Entwickler Zustandsautomatworkflows erstellen können. Diese Klassen und Aktivitäten wurden für .NET Framework 4.5 aktualisiert, um Folgendes einzuschließen:

    • Die Möglichkeit, Haltepunkte für Zustände festzulegen.

    • Die Möglichkeit zum Kopieren und Einfügen von Übergängen im Workflow-Designer.

    • Designerunterstützung für die Erstellung gemeinsam genutzter Triggerübergänge.

    • Aktivitäten zum Erstellen von Zustandsautomatworkflows, einschließlich: StateMachine, State, und Transition.

  • Erweiterte Workflow-Designer-Features wie die folgenden:

    • Erweiterte Workflowsuchfunktionen in Visual Studio, einschließlich Der Schnellsuche und der Suche in Dateien.

    • Möglichkeit zum automatischen Erstellen einer Sequenzaktivität, wenn einer containeraktivität eine zweite untergeordnete Aktivität hinzugefügt wird und beide Aktivitäten in die Sequence-Aktivität einbezogen werden soll.

    • Verschiebungsunterstützung, wodurch der sichtbare Teil eines Workflows geändert werden kann, ohne die Bildlaufleisten zu verwenden.

    • Eine neue Dokumentgliederungsansicht , in der die Komponenten eines Workflows in einer Strukturformat-Gliederungsansicht angezeigt werden, und Sie können eine Komponente in der Dokumentgliederungsansicht auswählen.

    • Möglichkeit zum Hinzufügen von Anmerkungen zu Aktivitäten.

    • Möglichkeit zum Definieren und Nutzen von Aktivitätsdelegaten mithilfe des Workflow-Designers.

    • Automatische Verbindung und automatisches Einfügen für Aktivitäten und Übergänge in Zustandsautomat- und Flussdiagrammworkflows.

  • Speichern der Ansichtsstatusinformationen für einen Workflow in einem einzelnen Element in der XAML-Datei, sodass Sie die Ansichtsstatusinformationen ganz einfach suchen und bearbeiten können.

  • Eine NoPersistScope-Containeraktivität, um zu verhindern, dass untergeordnete Aktivitäten beibehalten werden.

  • Unterstützung für C#-Ausdrücke:

    • Workflowprojekte, die Visual Basic verwenden, verwenden Visual Basic-Ausdrücke, und C#-Workflowprojekte verwenden C#-Ausdrücke.

    • C#-Workflowprojekte, die in Visual Studio 2010 erstellt wurden und visual Basic-Ausdrücke aufweisen, sind mit C#-Workflowprojekten kompatibel, die C#-Ausdrücke verwenden.

  • Versionsverwaltungsverbesserungen:

    • Die neue WorkflowIdentity Klasse, die eine Zuordnung zwischen einer dauerhaften Workflowinstanz und ihrer Workflowdefinition bereitstellt.

    • Parallele Ausführung mehrerer Workflowversionen im selben Host, einschließlich WorkflowServiceHost.

    • In dynamischer Aktualisierung können Sie die Definition einer beibehaltenen Workflowinstanz ändern.

  • Vertrags-first-Workflowdienstentwicklung, die Unterstützung für die automatische Generierung von Aktivitäten bietet, die einem vorhandenen Servicevertrag entsprechen.

Weitere Informationen finden Sie unter What's New in Windows Workflow Foundation.

.NET für Windows 8.x Store-Apps

Windows 8.x Store-Apps sind für bestimmte Formfaktoren ausgelegt und nutzen die Leistungsfähigkeit des Windows-Betriebssystems. Eine Teilmenge von .NET Framework 4.5 oder 4.5.1 steht zum Erstellen von Windows 8.x Store-Apps für Windows mit C# oder Visual Basic zur Verfügung. Diese Teilmenge wird als .NET für Windows 8.x Store-Apps bezeichnet und in einer Übersicht erläutert.

Portable Klassenbibliotheken

Mit dem Portable Class Library-Projekt in Visual Studio 2012 (und höheren Versionen) können Sie verwaltete Assemblys schreiben und erstellen, die auf mehreren .NET Framework-Plattformen funktionieren. Mit einem Portable Class Library-Projekt wählen Sie die Plattformen (z. B. Windows Phone- und .NET für Windows 8.x Store-Apps) aus, die als Ziel dienen sollen. Die verfügbaren Typen und Member in Ihrem Projekt sind automatisch auf die allgemeinen Typen und Member auf diesen Plattformen beschränkt. Weitere Informationen finden Sie unter Portable Class Library.

Siehe auch