Partager via

Nouveautés de .NET Framework

  • Article

Remarque

.NET Framework est géré indépendamment des mises à jour Windows avec des correctifs de bogues de sécurité et de fiabilité. En général, les mises à jour de sécurité sont publiées trimestriellement. .NET Framework continuera d’être inclus avec Windows, sans aucune intention de le supprimer. Vous n’avez pas besoin de migrer vos applications .NET Framework, mais pour le nouveau développement, utilisez .NET 8 ou version ultérieure.

Cet article récapitule les nouvelles fonctionnalités clés et les améliorations apportées aux versions suivantes de .NET Framework :

Cet article ne fournit pas d’informations complètes sur chaque nouvelle fonctionnalité et est susceptible de changer. Pour plus d’informations générales sur .NET Framework, consultez prise en main. Pour les plateformes prises en charge, consultez Exigences du système. Pour obtenir des liens de téléchargement et des instructions d’installation, consultez Guide d’installation.

Remarque

L’équipe .NET Framework publie également des fonctionnalités hors bande, à l’aide de NuGet, pour développer la prise en charge de la plateforme et introduire de nouvelles fonctionnalités, telles que les collections immuables et les types de vecteurs compatibles SIMD. Pour plus d’informations, consultez Autres bibliothèques de classes et API et Versions finales hors plage de .NET Framework. Consultez la liste complète des packages NuGet pour .NET Framework.

Présentation de .NET Framework 4.8.1

.NET Framework 4.8.1 s’appuie sur les versions précédentes de .NET Framework 4.x en ajoutant de nombreux nouveaux correctifs et plusieurs nouvelles fonctionnalités tout en restant un produit très stable.

Télécharger et installer .NET Framework 4.8.1

Vous pouvez télécharger .NET Framework 4.8.1 à partir des emplacements suivants :

.NET Framework 4.8 peut être installé sur Windows 11, Windows 10 version 21H2, Windows 10 version 21H1, Windows 10 version 20H2 et les plateformes serveur correspondantes à partir de Windows Server 2022. Vous pouvez installer .NET Framework 4.8.1 à l’aide du programme d’installation web ou du programme d’installation hors connexion. La méthode recommandée pour la plupart des utilisateurs consiste à utiliser le programme d’installation web.

Vous pouvez cibler .NET Framework 4.8.1 dans Visual Studio 2022 17.3 ou version ultérieure en installant le .NET Framework 4.8.1 Developer Pack.

Nouveautés de .NET Framework 4.8.1

.NET Framework 4.8.1 introduit de nouvelles fonctionnalités dans les domaines suivants :

L’accessibilité améliorée, qui permet à une application de fournir une expérience appropriée aux utilisateurs de la technologie d’assistance, est un objectif majeur de .NET Framework 4.8.1. Pour plus d’informations sur les améliorations apportées à l’accessibilité dans .NET Framework 4.8.1, consultez Nouveautés de l’accessibilité dans .NET Framework.

.NET Framework 4.8.1 ajoute la prise en charge native d’Arm64 à la famille .NET Framework. Ainsi, vos investissements dans l’vaste écosystème d’applications et de bibliothèques .NET Framework peuvent désormais tirer parti des avantages de l’exécution de charges de travail en mode natif sur Arm64, à savoir de meilleures performances par rapport à l’exécution de code x64 émulé sur Arm64.

Microsoft s’engage à fournir des produits et des plateformes qui sont accessibles à tous. .NET Framework 4.8.1 offre deux plateformes de développement d’interface utilisateur Windows, qui fournissent aux développeurs la prise en charge nécessaire pour créer des applications accessibles. Au cours des dernières versions, Windows Forms et WPF ont ajouté de nouvelles fonctionnalités et résolu de nombreux problèmes de fiabilité liés à l’accessibilité. Vous pouvez en savoir plus sur les détails de ce qui a été résolu ou ajouté dans chaque version en visitant Nouveautés de l’accessibilité dans .NET Framework.

Dans cette version, Windows Forms et WPF ont apporté des améliorations à la gestion des info-bulles pour les rendre plus accessibles. Dans les deux cas, les info-bulles sont désormais conformes aux instructions énoncées dans le contenu WCAG2.1 sur le pointage ou le focus. La configuration requise pour les info-bulles est la suivante :

  • Les info-bulles doivent s’afficher via le pointage de la souris ou par navigation au clavier vers le contrôle.
  • Les info-bulles doivent pouvoir être ignorées. Autrement dit, une simple commande clavier comme Échap doit ignorer l’info-bulle.
  • Les info-bulles doivent pouvoir être survolées. Les utilisateurs doivent pouvoir placer leur curseur sur l’info-bulle. Cela permet aux scénarios tels que l’utilisation de la loupe de pouvoir lire l’info-bulle pour les utilisateurs malvoyants.
  • Les info-bulles doivent être persistantes. Les info-bulles ne doivent pas disparaître automatiquement après un certain temps. Au lieu de cela, les info-bulles doivent être ignorées par l’utilisateur qui déplace sa souris vers un autre contrôle ou par une commande clavier.

Dans Windows Forms, cette prise en charge est disponible uniquement sur les systèmes d’exploitation Windows 11 ou ultérieur. Windows Forms est un wrapper managé léger autour de l’API Windows, et le nouveau comportement d’info-bulle n’est devenu disponible que dans Windows 11. WPF n’a aucune dépendance de version de système d’exploitation pour ses info-bulles accessibles.

WPF avait implémenté la plupart des exigences pour les info-bulles conformes à WCAG2.1 dans .NET Framework 4.8. Dans cette version, WPF a amélioré l’expérience en s’assurant qu’une info-bulle dans la fenêtre actuelle peut facilement être masquée à l’aide de la touche Échap, de la touche Ctrl (seule) ou de la combinaison Ctrl+Maj+F10. L’étendue de la clé d’échappement a été réduite dans cette version pour s’appliquer uniquement à la fenêtre active. Auparavant, elle s’appliquait à n’importe quelle info-bulle ouverte dans l’application.

Windows Forms était la première pile d’interface utilisateur Windows créée pour .NET Framework. Par conséquent, il a été créé à l’origine pour utiliser la technologie d’accessibilité héritée, qui ne répond pas aux exigences d’accessibilité actuelles. Dans cette version, Windows Forms a résolu un certain nombre de problèmes. Pour obtenir la liste complète des modifications liées à l’accessibilité, consultez Nouveautés de l’accessibilité dans .NET Framework.

Les principales améliorations de Windows Forms dans .NET Framework 4.8.1 sont les suivantes :

  • Prise en charge du modèle de texte: Windows Forms a ajouté la prise en charge du UIA Text Pattern. Ce modèle permet à la technologie d’assistance de parcourir le contenu d’une zone de texte ou d’une lettre de contrôle basée sur du texte similaire par lettre. Il permet de sélectionner du texte dans le champ de contrôle, de le modifier et d'insérer un nouveau texte au niveau du curseur. Windows Forms a ajouté cette prise en charge de TextBox, de cellules DataGridView, de contrôles ComboBox, etc.

  • Résoudre les problèmes de contraste : dans plusieurs contrôles, Windows Forms a modifié le rapport de contraste des rectangles de sélection de façon à ce qu’ils soient plus sombres et plus visibles.

  • Correction de plusieurs problèmes DataGridView :

    • Les noms de barre de défilement ont été mis à jour pour être cohérents.
    • Le Narrateur est désormais en mesure de se concentrer sur des cellules DataGridView vides.
    • Les développeurs peuvent définir la propriété de type de contrôle localisé pour les cellules Custom DataGridView.
    • La couleur de lien des cellules DataGridViewLink a été mise à jour pour avoir un meilleur contraste avec l’arrière-plan.

Présentation de .NET Framework 4.8

.NET Framework 4.8 s’appuie sur les versions précédentes de .NET Framework 4.x en ajoutant de nombreux nouveaux correctifs et plusieurs nouvelles fonctionnalités tout en restant un produit très stable.

Télécharger et installer .NET Framework 4.8

Vous pouvez télécharger .NET Framework 4.8 à partir des emplacements suivants :

.NET Framework 4.8 peut être installé sur Windows 10, Windows 8.1, Windows 7 SP1 et les plateformes serveur correspondantes à partir de Windows Server 2008 R2 SP1. Vous pouvez installer .NET Framework 4.8 à l’aide du programme d’installation web ou du programme d’installation hors connexion. La méthode recommandée pour la plupart des utilisateurs consiste à utiliser le programme d’installation web.

Vous pouvez cibler .NET Framework 4.8 dans Visual Studio 2012 ou version ultérieure en installant le .NET Framework 4.8 Developer Pack.

Nouveautés de .NET Framework 4.8

.NET Framework 4.8 introduit de nouvelles fonctionnalités dans les domaines suivants :

Amélioration de l’accessibilité, qui permet à une application de fournir une expérience appropriée aux utilisateurs de la technologie d’assistance, continue d’être un objectif majeur de .NET Framework 4.8. Pour plus d’informations sur les améliorations apportées à l’accessibilité dans .NET Framework 4.8, consultez Nouveautés de l’accessibilité dans .NET Framework.

Classes de base

Impact FIPS réduit sur le chiffrement. Dans les versions précédentes de .NET Framework, les classes de fournisseur de chiffrement managées telles que SHA256Managed lèvent un CryptographicException lorsque les bibliothèques de chiffrement système sont configurées en « mode FIPS ». Ces exceptions sont levées, car les versions gérées des classes de fournisseur de chiffrement, contrairement aux bibliothèques de chiffrement système, n’ont pas subi de certification FIPS (Federal Information Processing Standards) 140-2. Étant donné que peu de développeurs ont leurs machines de développement en mode FIPS, les exceptions sont généralement levées dans les systèmes de production.

Par défaut, dans les applications qui ciblent .NET Framework 4.8, les classes de chiffrement managées suivantes ne lèvent plus de CryptographicException dans ce cas :

Au lieu de cela, ces classes redirigent les opérations de chiffrement vers une bibliothèque de chiffrement système. Cette modification supprime efficacement une différence potentiellement déroutante entre les environnements de développement et les environnements de production et rend les composants natifs et les composants managés fonctionnent sous la même stratégie de chiffrement. Les applications qui dépendent de ces exceptions peuvent restaurer le comportement précédent en définissant le commutateur AppContext Switch.System.Security.Cryptography.UseLegacyFipsThrow sur true. Pour plus d’informations, consultez Managed cryptography classes do not throw a CryptographyException in FIPS mode (Les classes de chiffrement managées ne lèvent pas d’exception de chiffrement en mode FIPS).

Utilisation de la version mise à jour de ZLib

À compter de .NET Framework 4.5, l’assembly clrcompression.dll utilise ZLib, une bibliothèque externe native pour la compression des données, afin de fournir une implémentation pour l’algorithme de déflate. La version .NET Framework 4.8 de clrcompression.dll est mise à jour pour utiliser ZLib version 1.2.11, qui comprend plusieurs améliorations et correctifs clés.

Windows Communication Foundation (WCF)

Présentation de ServiceHealthBehavior

Les points de terminaison de santé sont largement utilisés par les outils d’orchestration pour gérer les services en fonction de leur état de santé. Les contrôles d’intégrité peuvent également être utilisés par des outils de surveillance pour suivre et fournir des notifications sur la disponibilité et les performances d’un service.

ServiceHealthBehavior est un comportement de service WCF qui étend IServiceBehavior. Lorsqu’il est ajouté à la collection ServiceDescription.Behaviors, un comportement de service effectue les opérations suivantes :

  • Retourne le statut de santé du service avec des codes de réponse HTTP. Vous pouvez spécifier dans une chaîne de requête le code d’état HTTP d’une requête de sonde d’intégrité HTTP/GET.

  • Publie des informations sur l’intégrité du service. Les détails spécifiques au service, notamment l’état du service, le nombre de limitations et la capacité peuvent être affichés à l’aide d’une requête HTTP/GET avec la chaîne de requête ?health. La facilité d’accès à ces informations est importante lors de la résolution d’un problème de comportement d’un service WCF.

Deux méthodes permettent d’exposer le point de terminaison d’intégrité et de publier les informations d’intégrité du service WCF :

  • Par le biais du code. Par exemple:

    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)

  • À l’aide d’un fichier de configuration. Par exemple:

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

L’état d’intégrité d’un service peut être interrogé à l’aide de paramètres de requête tels que OnServiceFailure, OnDispatcherFailure, OnListenerFailure, OnThrottlePercentExceeded), et un code de réponse HTTP peut être spécifié pour chaque paramètre de requête. Si le code de réponse HTTP est omis pour un paramètre de requête, un code de réponse HTTP 503 est utilisé par défaut. Par exemple:

Paramètres de requête et exemples :

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

    Un code d’état de réponse HTTP 455 est retourné lorsque l’état d’un répartiteur de canal est supérieur à CommunicationState.Opened.

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

    Un code d’état de réponse HTTP 465 est retourné lorsque l’état de l’un des écouteurs de canal est supérieur à CommunicationState.Opened.

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

    Spécifie le pourcentage {1 à 100} qui déclenche la réponse et son code de réponse HTTP {200 – 599}. Dans cet exemple :

    • Si le pourcentage est supérieur à 95, un code de réponse HTTP 500 est retourné.

    • Si le pourcentage est compris entre 70 et 95, 350 est retourné.

    • Sinon, 200 est renvoyé.

L’état d’intégrité du service peut être affiché en HTML en spécifiant une chaîne de requête comme https://contoso:81/Service1?health ou en XML en spécifiant une chaîne de requête comme https://contoso:81/Service1?health&Xml. Une chaîne de requête telle que https://contoso:81/Service1?health&NoContent retourne une page HTML vide.

Windows Presentation Foundation (WPF)

Améliorations de la haute résolution

Dans .NET Framework 4.8, WPF ajoute la prise en charge DPI V2 par moniteur et la mise à l’échelle PPP en mode mixte. Consultez la section Développement d'applications de bureau à DPI élevé sur Windows pour plus d'informations sur le développement à DPI élevé.

.NET framework 4.8 améliore la prise en charge pour l’interopérabilité de HWND et de Windows Forms hébergés dans des applications WPF haute résolution sur les plateformes qui prennent en charge la mise à l’échelle PPP en mode mixte (depuis la Mise à jour d’avril 2018 de Windows 10). Lorsque des contrôles HWND ou Windows Forms hébergés sont créés en tant que fenêtres mises à l’échelle PPP en mode en appelant SetThreadDpiHostingBehavior et SetThreadDpiAwarenessContext, ils peuvent être hébergés dans une application WPF V2 par moniteur, et sont dimensionnés et mis à l’échelle de manière appropriée. Ce contenu hébergé n’est pas rendu à la résolution DPI native ; au lieu de cela, le système d’exploitation met à l’échelle le contenu hébergé à la taille appropriée. Le mode de prise en charge de DPI V2 par moniteur permet également que des contrôles WPF soient hébergés (c’est-à-dire apparentés) dans une fenêtre native d’une application en haute résolution.

Pour activer la prise en charge de la mise à l’échelle de la haute résolution en mode mixte, vous pouvez définir les commutateurs AppContext suivants dans le fichier de configuration de l’application :

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

Common Language Runtime

Le runtime dans .NET Framework 4.8 inclut les modifications et améliorations suivantes :

Améliorations apportées au compilateur JIT. Le compilateur Just-in-time (JIT) dans .NET Framework 4.8 est basé sur le compilateur JIT dans .NET Core 2.1. La plupart des optimisations et tous les correctifs de bogues apportés au compilateur JIT .NET Core 2.1 sont inclus dans le compilateur JIT .NET Framework 4.8.

Améliorations du NGEN. La gestion de la mémoire du runtime a été améliorée pour les images Native Image Generator (NGEN) afin que les données mappées à partir d’images NGEN ne résident pas en mémoire. Cela réduit la surface d’exposition disponible pour les attaques qui tentent d’exécuter du code arbitraire en modifiant la mémoire qui sera exécutée.

Analyse de logiciel anti-programme malveillant pour tous les assemblys. Dans les versions précédentes de .NET Framework, le runtime analyse tous les assemblys chargés à partir du disque à l’aide de Windows Defender ou d’un logiciel anti-programme malveillant tiers. Toutefois, les assemblys chargés à partir d’autres sources, comme par la méthode Assembly.Load(Byte[]), ne sont pas analysés et peuvent potentiellement contenir des programmes malveillants non détectés. À compter de .NET Framework 4.8 s’exécutant sur Windows 10, le runtime déclenche une analyse par les solutions anti-programme malveillant qui implémentent l’interface d’analyse anti-programme malveillant (AMSI) .

Nouveautés de .NET Framework 4.7.2

.NET Framework 4.7.2 inclut de nouvelles fonctionnalités dans les domaines suivants :

Un focus continu dans .NET Framework 4.7.2 est une accessibilité améliorée, ce qui permet à une application de fournir une expérience appropriée aux utilisateurs de la technologie d’assistance. Pour plus d’informations sur les améliorations apportées à l’accessibilité dans .NET Framework 4.7.2, consultez Nouveautés de l’accessibilité dans .NET Framework.

Classes de base

.NET Framework 4.7.2 offre un grand nombre d’améliorations de chiffrement, une meilleure prise en charge de la décompression pour les archives ZIP et des API de collection supplémentaires.

Nouvelles surcharges de RSA.Create et DSA.Create

Les méthodes DSA.Create(DSAParameters) et RSA.Create(RSAParameters) vous permettent de fournir des paramètres de clé lors de l’instanciation d’une nouvelle DSA ou d’une clé RSA. Ils vous permettent de remplacer du code comme suit :

// 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

avec du code comme suit :

// 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

Les méthodes DSA.Create(Int32) et RSA.Create(Int32) vous permettent de générer de nouvelles clés DSA ou RSA avec une taille de clé spécifique. Par exemple:

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

Les constructeurs Rfc2898DeriveBytes acceptent un nom d’algorithme de hachage

La classe Rfc2898DeriveBytes a trois nouveaux constructeurs avec un paramètre HashAlgorithmName qui identifie l’algorithme HMAC à utiliser lors de la dérivation des clés. Au lieu d’utiliser SHA-1, les développeurs doivent utiliser un HMAC basé sur SHA-2 comme SHA-256, comme illustré dans l’exemple suivant :

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

Prise en charge des clés éphémères

L’importation PFX peut éventuellement charger des clés privées directement à partir de la mémoire, en contournant le disque dur. Lorsque le nouvel indicateur X509KeyStorageFlags.EphemeralKeySet est spécifié dans un constructeur X509Certificate2 ou l'une des surcharges de la méthode X509Certificate2.Import, les clés privées seront chargées en tant que clés éphémères. Cela empêche les clés d’être visibles sur le disque. Toutefois:

  • Étant donné que les clés ne sont pas conservées sur le disque, les certificats chargés avec cet indicateur ne sont pas de bons candidats à ajouter à un X509Store.

  • Les clés chargées de cette façon sont presque toujours chargées via Windows CNG. Par conséquent, les appelants doivent accéder à la clé privée en appelant des méthodes d'extension, telles que cert.GetRSAPrivateKey(). La propriété X509Certificate2.PrivateKey ne fonctionne pas.

  • Étant donné que la propriété X509Certificate2.PrivateKey héritée ne fonctionne pas avec les certificats, les développeurs doivent effectuer des tests rigoureux avant de passer à des clés éphémères.

création programmatique des demandes de signature de certification PKCS#10 et des certificats de clé publique X.509

À compter de .NET Framework 4.7.2, les charges de travail peuvent générer des demandes de signature de certificat (CSR), ce qui permet à la génération de demandes de certificat d’être intermédiaire dans des outils existants. Cela est fréquemment utile dans les scénarios de test.

Pour plus d’informations et des exemples de code, consultez « Création programmatique de demandes de signature de certification PKCS#10 et certificats de clé publique X.509 » dans le blog .NET.

nouveaux membres de SignerInfo

À compter de .NET Framework 4.7.2, la classe SignerInfo expose plus d’informations sur la signature. Vous pouvez récupérer la valeur de la propriété System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm pour déterminer l’algorithme de signature utilisé par le signataire. SignerInfo.GetSignature peut être appelée pour obtenir une copie de la signature cryptographique de ce signataire.

Laisser un flux encapsulé ouvert après que CryptoStream a été supprimé

À compter de .NET Framework 4.7.2, la classe CryptoStream a un constructeur supplémentaire qui permet Dispose de ne pas fermer le flux encapsulé. Pour laisser le flux encapsulé ouvert une fois l’instance CryptoStream supprimée, appelez le nouveau constructeur CryptoStream comme suit :

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

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

Changements de décompression dans DeflateStream

À compter de .NET Framework 4.7.2, l’implémentation des opérations de décompression dans la classe DeflateStream a changé pour utiliser les API Windows natives par défaut. En règle générale, cela entraîne une amélioration substantielle des performances.

La prise en charge de la décompression à l’aide des API Windows est activée par défaut pour les applications qui ciblent .NET Framework 4.7.2. Les applications qui ciblent les versions antérieures de .NET Framework, mais qui s’exécutent sous .NET Framework 4.7.2, peuvent adopter ce comportement en ajoutant le commutateur AppContext suivant au fichier de configuration de l’application :

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

API de collection supplémentaires

.NET Framework 4.7.2 ajoute un certain nombre de nouvelles API aux types SortedSet<T> et HashSet<T>. Voici quelques-uns des éléments suivants :

La classe ConcurrentDictionary<TKey,TValue> inclut de nouvelles surcharges des méthodes AddOrUpdate et GetOrAdd pour récupérer une valeur du dictionnaire ou l’ajouter si elle n’est pas trouvée, et pour ajouter une valeur au dictionnaire ou pour la mettre à jour s’il existe déjà.

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

Prise en charge de l'injection de dépendances dans les Web Forms

'injection de dépendances (DI) dissocie les objets et leurs dépendances afin que le code d’un objet n’ait plus besoin d’être modifié simplement parce qu’une dépendance a changé. Lorsque vous développez des applications ASP.NET qui ciblent .NET Framework 4.7.2, vous pouvez :

Support for same-site cookies

SameSite empêche un navigateur d’envoyer un cookie avec une requête intersite. .NET Framework 4.7.2 ajoute une propriété HttpCookie.SameSite dont la valeur est un membre d’énumération System.Web.SameSiteMode. Si sa valeur est SameSiteMode.Strict ou SameSiteMode.Lax, ASP.NET ajoute l’attribut SameSite à l’en-tête set-cookie. La compatibilité SameSite s’applique aux objets HttpCookie, ainsi qu’aux cookies FormsAuthentication et System.Web.SessionState.

Vous pouvez définir SameSite pour un objet HttpCookie comme suit :

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

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

Vous pouvez également configurer des cookies SameSite au niveau de l’application en modifiant le fichier web.config :

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

Vous pouvez ajouter SameSite pour FormsAuthentication et System.Web.SessionState cookies en modifiant le fichier de configuration web :

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

Réseautage

Implémentation des propriétés HttpClientHandler

.NET Framework 4.7.1 a ajouté huit propriétés à la classe System.Net.Http.HttpClientHandler. Toutefois, deux d’entre elles levaient une PlatformNotSupportedException. .NET Framework 4.7.2 fournit désormais une implémentation pour ces propriétés. Les propriétés sont les suivantes :

SQLClient

Prise en charge de l’authentification universelle Azure Active Directory et de l’authentification multifacteur

La conformité et les exigences de sécurité croissantes nécessitent que de nombreux clients utilisent l’authentification multifacteur (MFA). En outre, les meilleures pratiques actuelles découragent l’inclusion des mots de passe utilisateur directement dans les chaînes de connexion. Pour gérer ces changements, .NET Framework 4.7.2 étend les chaînes de connexion SQLClient en ajoutant une nouvelle valeur, « Active Directory Interactive », pour le mot clé « Authentification » existant afin de prendre en charge MFA et Azure AD Authentication. La nouvelle méthode interactive prend en charge les utilisateurs Azure AD natifs et fédérés ainsi que les utilisateurs invités Azure AD. Lorsque cette méthode est utilisée, l’authentification MFA imposée par Azure AD est prise en charge pour les bases de données SQL. En outre, le processus d’authentification demande à un mot de passe utilisateur de respecter les meilleures pratiques de sécurité.

Dans les versions précédentes de .NET Framework, la connectivité SQL n’a pris en charge que les options SqlAuthenticationMethod.ActiveDirectoryPassword et SqlAuthenticationMethod.ActiveDirectoryIntegrated. Ces deux éléments font partie du protocole ADAL non interactif , qui ne prend pas en charge l’authentification multifacteur. Avec la nouvelle option SqlAuthenticationMethod.ActiveDirectoryInteractive, la connectivité SQL prend en charge l’authentification multifacteur ainsi que les méthodes d’authentification existantes (mot de passe et authentification intégrée), ce qui permet aux utilisateurs d’entrer des mots de passe utilisateur de manière interactive sans conserver les mots de passe dans la chaîne de connexion.

Pour plus d’informations et un exemple, consultez « SQL - Prise en charge de l’authentification multifacteur et universelle Azure AD » dans le blog .NET.

Prise en charge d’Always Encrypted version 2

NET Framework 4.7.2 ajoute des supports pour Always Encrypted basé sur enclave. La version d’origine d’Always Encrypted est une technologie de chiffrement côté client dans laquelle les clés de chiffrement ne quittent jamais le client. Dans Always Encrypted basé sur les enclaves, le client peut éventuellement envoyer les clés de chiffrement à une enclave sécurisée, qui est une entité de calcul sécurisée qui peut être considérée comme faisant partie de SQL Server, mais que le code SQL Server ne peut pas falsifier. Pour prendre en charge Always Encrypted basé sur les enclaves, .NET Framework 4.7.2 ajoute les types et les membres suivants à l’espace de noms System.Data.SqlClient :

Le fichier de configuration de l’application spécifie ensuite une implémentation concrète de la classe System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider abstraite qui fournit les fonctionnalités du fournisseur d’enclaves. Par exemple:

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

Le flux de base d’Always Encrypted basé sur les enclaves est le suivant :

  1. L’utilisateur crée une connexion AlwaysEncrypted à SQL Server qui prend en charge Always Encrypted basé sur enclave. Le pilote contacte le service d’attestation pour s’assurer qu’il se connecte à la bonne enclave.

  2. Une fois l’enclave attestée, le pilote établit un canal sécurisé avec l’enclave sécurisée hébergée sur SQL Server.

  3. Le pilote partage les clés de chiffrement autorisées par le client avec l’enclave sécurisée pendant la durée de la connexion SQL.

Windows Presentation Foundation

Recherche de ResourceDictionaries par source

À compter de .NET Framework 4.7.2, un assistant de diagnostic peut localiser les ResourceDictionaries qui ont été créées à partir d’un URI source donné. (Cette fonctionnalité est utilisée par les assistants de diagnostic, et non par les applications de production.) Un assistant de diagnostic tel que la fonctionnalité « Edit-and-Continue » de Visual Studio permet à son utilisateur de modifier un ResourceDictionary avec l’intention que les modifications soient appliquées à l’application en cours d’exécution. Une étape consiste à trouver tous les ResourceDictionaries que l’application en cours d’exécution a créées à partir du dictionnaire en cours de modification. Par exemple, une application peut déclarer un ResourceDictionary dont le contenu est copié à partir d’un URI source donné :

<ResourceDictionary Source="MyRD.xaml" />

Un assistant de diagnostic qui modifie le balisage d’origine dans MyRD.xaml peut utiliser la nouvelle fonctionnalité pour localiser le dictionnaire. La fonctionnalité est implémentée par une nouvelle méthode statique, ResourceDictionaryDiagnostics.GetResourceDictionariesForSource. L’Assistant diagnostic appelle la nouvelle méthode à l’aide d’un URI absolu qui identifie le balisage d’origine, comme illustré par le code suivant :

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

La méthode retourne une énumérable vide, sauf si VisualDiagnostics est activé et que la variable d’environnement ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO est définie.

Recherche des propriétaires de ResourceDictionary

À compter de .NET Framework 4.7.2, un assistant de diagnostic peut localiser les propriétaires d’une ResourceDictionarydonnée. (La fonctionnalité est utilisée par les assistants de diagnostic et non par les applications de production.) Chaque fois qu’une modification est apportée à un ResourceDictionary, WPF recherche automatiquement toutes les références DynamicResource susceptibles d’être affectées par la modification.

Un assistant de diagnostic tel que la fonctionnalité Edit-and-Continue de Visual Studio peut souhaiter étendre cette fonctionnalité pour gérer les références StaticResource. La première étape de ce processus consiste à trouver les propriétaires du dictionnaire ; autrement dit, pour rechercher tous les objets dont la propriété Resources fait référence au dictionnaire (directement ou indirectement via la propriété ResourceDictionary.MergedDictionaries). Trois nouvelles méthodes statiques implémentées sur la classe System.Windows.Diagnostics.ResourceDictionaryDiagnostics, une pour chacun des types de base ayant une propriété Resources, prennent en charge cette étape :

Ces méthodes retournent une énumérable vide, sauf si VisualDiagnostics est activé et que la variable d’environnement ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO est définie.

Recherche de références StaticResource

Un assistant de diagnostic peut désormais recevoir une notification chaque fois qu’une StaticResource référence est résolue. (La fonctionnalité est utilisée par les assistants de diagnostic, et non par les applications de production.) Un assistant de diagnostic tel que la fonctionnalité « Modifier et continuer » de Visual Studio peut mettre à jour toutes les utilisations d’une ressource lorsque sa valeur dans un ResourceDictionary change. WPF effectue cette opération automatiquement pour les références DynamicResource, mais ne le fait intentionnellement pas pour les références StaticResource. À compter de .NET Framework 4.7.2, l’Assistant diagnostic peut utiliser ces notifications pour localiser ces utilisations de la ressource statique.

La notification est implémentée par le nouvel événement ResourceDictionaryDiagnostics.StaticResourceResolved :

public static event EventHandler<StaticResourceResolvedEventArgs> StaticResourceResolved;

Public Shared Event StaticResourceResolved As EventHandler(Of StaticResourceResolvedEventArgs)

Cet événement est déclenché chaque fois que le runtime résout une référence StaticResource. Les arguments StaticResourceResolvedEventArgs décrivent la résolution et indiquent l’objet et la propriété qui hébergent la référence StaticResource et la ResourceDictionary et la clé utilisées pour la résolution :

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

L’événement n’est pas déclenché (et son accesseur add est ignoré), sauf si VisualDiagnostics est activé et que la variable d’environnement ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO est définie.

ClickOnce

Les applications compatibles HDPI pour Windows Forms, Windows Presentation Foundation (WPF) et Visual Studio Tools pour Office (VSTO) peuvent toutes être déployées à l’aide de ClickOnce. Si l’entrée suivante se trouve dans le manifeste de l’application, le déploiement réussit sous .NET Framework 4.7.2 :

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

Pour les applications Windows Forms, il n'est plus nécessaire de configurer la sensibilisation DPI dans le fichier de configuration de l'application plutôt que dans le manifeste de l'application pour que le déploiement ClickOnce réussisse.

Nouveautés de .NET Framework 4.7.1

.NET Framework 4.7.1 inclut de nouvelles fonctionnalités dans les domaines suivants :

En outre, un objectif majeur dans .NET Framework 4.7.1 est d’améliorer l’accessibilité, ce qui permet à une application de fournir une expérience appropriée aux utilisateurs de la technologie d’assistance. Pour plus d’informations sur les améliorations apportées à l’accessibilité dans .NET Framework 4.7.1, consultez Nouveautés de l’accessibilité dans .NET Framework.

Classes de base

Prise en charge de .NET 2.0 Standard

.NET Standard définit un ensemble d’API qui doivent être disponibles sur chaque implémentation .NET qui prend en charge cette version de la norme. .NET Framework 4.7.1 prend entièrement en charge .NET Standard 2.0 et ajoute environ 200 API définies dans .NET Standard 2.0 et sont manquantes dans .NET Framework 4.6.1, 4.6.2 et 4.7. (Notez que ces versions de .NET Framework prennent en charge .NET Standard 2.0 uniquement si des fichiers de prise en charge .NET Standard supplémentaires sont également déployés sur le système cible.) Pour plus d’informations, consultez « BCL - Prise en charge de .NET Standard 2.0 » dans le billet de blog Fonctionnalités d'exécution et du compilateur de .NET Framework 4.7.1.

Prise en charge des générateurs de configuration

Les générateurs de configuration permettent aux développeurs d’injecter et de générer des paramètres de configuration pour les applications dynamiquement au moment de l’exécution. Les générateurs de configuration personnalisés peuvent être utilisés pour modifier les données existantes dans une section de configuration ou pour créer entièrement une section de configuration à partir de zéro. Sans générateurs de configuration, les fichiers .config sont statiques et leurs paramètres sont définis un certain temps avant le lancement d’une application.

Pour créer un générateur de configuration personnalisé, vous dérivez votre générateur de la classe ConfigurationBuilder abstraite et remplacez son ConfigurationBuilder.ProcessConfigurationSection et son ConfigurationBuilder.ProcessRawXml. Vous définissez également vos générateurs dans votre fichier .config. Pour plus d'informations, consultez la section « Générateurs de configuration » dans le billet de blog sur le .NET Framework 4.7.1 ASP.NET et les fonctionnalités de configuration.

Détection des fonctionnalités au moment de l’exécution

La classe System.Runtime.CompilerServices.RuntimeFeature fournit un mécanisme permettant de déterminer si une fonctionnalité prédéfinie est prise en charge sur une implémentation .NET donnée au moment de la compilation ou de l’exécution. Au moment de la compilation, un compilateur peut vérifier si un champ spécifié existe pour déterminer si la fonctionnalité est prise en charge ; le cas échéant, il peut émettre du code qui tire parti de cette fonctionnalité. Au moment de l’exécution, une application peut appeler la méthode RuntimeFeature.IsSupported avant d’émettre du code au moment de l’exécution. Pour plus d’informations, consultez méthode Add helper pour décrire les fonctionnalités prises en charge par le runtime.

Les types tuple de valeur sont sérialisables

À compter de .NET Framework 4.7.1, System.ValueTuple et ses types génériques associés sont marqués comme sérialisable, ce qui permet la sérialisation binaire. Cela doit faciliter la migration des types Tuple, comme Tuple<T1,T2,T3> et Tuple<T1,T2,T3,T4>, vers des types tuple de valeur. Pour plus d’informations, consultez « Compiler -- ValueTuple is Serializable » dans le billet de blog .NET Framework 4.7.1 Runtime and Compiler Features.

Prise en charge des références en lecture seule

.NET framework 4.7.1 ajoute le System.Runtime.CompilerServices.IsReadOnlyAttribute. Cet attribut est utilisé par les compilateurs de langage pour marquer les membres qui ont des paramètres ou des types de retour de référence en lecture seule. Pour plus d’informations, consultez « Compiler -- Support for ReadOnlyReferences » dans le billet de blog .NET Framework 4.7.1 Runtime and Compiler Features. Pour plus d’informations sur les valeurs de retour de référence, consultez Valeurs de retour de référence, variables locales ref et Valeurs de retour de référence (Visual Basic).

Common Language Runtime (CLR)

Améliorations des performances de la collecte de déchets

Des modifications apportées à garbage collection (GC) dans .NET Framework 4.7.1 améliorent les performances globales, plus particulièrement pour les allocations de tas d’objets volumineux (LOH). Dans .NET Framework 4.7.1, des verrous distincts sont utilisés pour les allocations de tas de petits objets (SOH) et LOH, ce qui permet aux allocations LOH de se produire lors du GC en arrière-plan ou du nettoyage du SOH. Les applications qui créent un grand nombre d’allocations LOH bénéficient donc d’une réduction de la contention de verrouillage des allocations et de meilleures performances. Pour plus d’informations, consultez la section « Runtime - Améliorations des performances GC » dans le billet de blog .NET Framework 4.7.1 Fonctionnalités du Runtime et du Compilateur.

Réseautage

Prise en charge de SHA-2 pour Message.HashAlgorithm

Dans .NET Framework 4.7 et versions antérieures, la propriété Message.HashAlgorithm prend en charge les valeurs de HashAlgorithm.Md5 et de HashAlgorithm.Sha uniquement. À compter de .NET Framework 4.7.1, HashAlgorithm.Sha256, HashAlgorithm.Sha384et HashAlgorithm.Sha512 sont également pris en charge. Si cette valeur est réellement utilisée dépend de MSMQ, car l’instance Message elle-même ne fait pas de hachage, mais passe simplement des valeurs à MSMQ. Pour plus d’informations, consultez la section « SHA-2 support for Message.HashAlgorithm » dans le billet de blog .NET Framework 4.7.1 ASP.NET and Configuration features.

ASP.NET

étapes d’exécution dans ASP.NET applications

ASP.NET traite les demandes dans un pipeline prédéfini qui inclut 23 événements. ASP.NET exécute chaque gestionnaire d’événements en tant qu’étape d’exécution. Dans les versions de ASP.NET jusqu’à .NET Framework 4.7, ASP.NET ne peut pas transmettre le contexte d’exécution en raison du basculement entre les threads natifs et managés. Au lieu de cela, ASP.NET transmet sélectivement uniquement le HttpContext. À compter de .NET Framework 4.7.1, la méthode HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) permet également aux modules de restaurer les données ambiantes. Cette fonctionnalité est destinée aux bibliothèques concernées par le suivi, le profilage, les diagnostics ou les transactions, par exemple, qui s’intéressent au flux d’exécution de l’application. Pour plus d’informations, consultez « ASP.NET Execution Step Feature » dans le billet de blog .NET Framework 4.7.1 ASP.NET and Configuration Features.

Analyse HttpCookie ASP.NET

.NET Framework 4.7.1 inclut une nouvelle méthode, HttpCookie.TryParse, qui fournit un moyen standardisé de créer un objet HttpCookie à partir d’une chaîne et d’attribuer avec précision des valeurs de cookie telles que la date d’expiration et le chemin d’accès. Pour plus d'informations, consultez « l'analyse de ASP.NET HttpCookie » dans le billet de blog .NET Framework 4.7.1 ASP.NET et fonctionnalités de configuration.

Options de hachage SHA-2 pour les informations d’identification de l’authentification par formulaires ASP.NET

Dans .NET Framework 4.7 et versions antérieures, ASP.NET permis aux développeurs de stocker les informations d’identification utilisateur avec des mots de passe hachés dans des fichiers de configuration à l’aide de MD5 ou SHA1. À compter de .NET Framework 4.7.1, ASP.NET prend également en charge de nouvelles options de hachage SHA-2 sécurisées telles que SHA256, SHA384 et SHA512. SHA1 reste la valeur par défaut et un algorithme de hachage non par défaut peut être défini dans le fichier de configuration web.

Important

Microsoft vous recommande d’utiliser le flux d’authentification le plus sécurisé disponible. Si vous vous connectez à Azure SQL, Identités managées pour les ressources Azure est la méthode d’authentification recommandée.

Nouveautés de .NET Framework 4.7

.NET Framework 4.7 inclut de nouvelles fonctionnalités dans les domaines suivants :

Pour obtenir la liste des nouvelles API ajoutées à .NET Framework 4.7, consultez modifications de l’API .NET Framework 4.7 sur GitHub. Pour obtenir la liste des améliorations des fonctionnalités et des correctifs de bogues dans .NET Framework 4.7, consultez liste des modifications .NET Framework 4.7 sur GitHub. Pour plus d’informations, consultez Announcing .NET Framework 4.7 sur le blog .NET.

Classes de base

.NET Framework 4.7 améliore la sérialisation par le DataContractJsonSerializer:

fonctionnalités améliorées avec le chiffrement de courbe elliptique (ECC)*

Dans .NET Framework 4.7, ImportParameters(ECParameters) méthodes ont été ajoutées aux classes ECDsa et ECDiffieHellman pour permettre à un objet de représenter une clé déjà établie. Une méthode ExportParameters(Boolean) a également été ajoutée pour exporter la clé à l’aide de paramètres de courbe explicites.

.NET Framework 4.7 ajoute également la prise en charge des courbes supplémentaires (y compris la suite de courbes Brainpool) et ajoute des définitions prédéfinies pour faciliter la création via les nouvelles méthodes usine Create et Create.

Vous pouvez voir un exemple des améliorations apportées au chiffrement de .NET Framework 4.7 sur GitHub.

Meilleure prise en charge des caractères de contrôle par le DataContractJsonSerializer

Dans .NET Framework 4.7, la classe DataContractJsonSerializer sérialise les caractères de contrôle conformément à la norme ECMAScript 6. Ce comportement est activé par défaut pour les applications qui ciblent .NET Framework 4.7 et est une fonctionnalité d’opt-in pour les applications qui s’exécutent sous .NET Framework 4.7, mais ciblent une version précédente de .NET Framework. Pour plus d'informations, consultez la section Compatibilité des applications.

Réseautage

.NET Framework 4.7 ajoute la fonctionnalité réseau suivante :

prise en charge par défaut du système d’exploitation pour les protocoles TLS*

La pile TLS, utilisée par System.Net.Security.SslStream et les composants de niveaux supérieurs tels que HTTP, FTP et SMTP, permet aux développeurs d’utiliser les protocoles TLS par défaut pris en charge par le système d’exploitation. Les développeurs n’ont plus besoin de coder en dur une version TLS.

ASP.NET

Dans .NET Framework 4.7, ASP.NET inclut les nouvelles fonctionnalités suivantes :

Extensibilité du Cache d’Objets

À compter de .NET Framework 4.7, ASP.NET ajoute un nouvel ensemble d’API qui permettent aux développeurs de remplacer les implémentations de ASP.NET par défaut pour la mise en cache d’objets en mémoire et la surveillance de la mémoire. Les développeurs peuvent désormais remplacer l’un des trois composants suivants si l’implémentation ASP.NET n’est pas adéquate :

  • Object Cache Store. En utilisant la nouvelle section de configuration des fournisseurs de cache, les développeurs peuvent plug-in de nouvelles implémentations d’un cache d’objets pour une application ASP.NET à l’aide de la nouvelle interface ICacheStoreProvider.

  • Surveillance de la mémoire. Le moniteur de mémoire par défaut dans ASP.NET avertit les applications lorsqu’elles s’exécutent près de la limite d’octets privés configurée pour le processus, ou lorsque la machine est faible sur le nombre total de RAM physiques disponibles. Lorsque ces limites sont proches, les notifications sont déclenchées. Pour certaines applications, les notifications sont déclenchées trop près des limites configurées pour permettre des réactions utiles. Les développeurs peuvent désormais écrire leurs propres moniteurs de mémoire pour remplacer la valeur par défaut à l’aide de la propriété ApplicationMonitors.MemoryMonitor.

  • Memory Limit Reactions. Par défaut, ASP.NET tente de découper le cache d’objets et appelle régulièrement GC.Collect lorsque la limite du processus d’octet privé est proche. Pour certaines applications, la fréquence des appels à GC.Collect ou la quantité de cache qui est rogné sont inefficaces. Les développeurs peuvent maintenant remplacer ou compléter le comportement par défaut en souscrivant des implémentations IObserver auprès du moniteur de mémoire de l’application.

Windows Communication Foundation (WCF)

Windows Communication Foundation (WCF) ajoute les fonctionnalités et modifications suivantes :

Possibilité de configurer les paramètres de sécurité des messages par défaut sur TLS 1.1 ou TLS 1.2

À compter de .NET Framework 4.7, WCF vous permet de configurer TLS 1.1 ou TLS 1.2 en plus de SSL 3.0 et TLS 1.0 comme protocole de sécurité de message par défaut. Il s’agit d’un paramètre d’adhésion ; pour l’activer, vous devez ajouter l’entrée suivante au fichier de configuration de votre application :

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

Fiabilité améliorée des applications WCF et de la sérialisation WCF

WCF inclut un certain nombre de modifications de code qui éliminent les conditions de concurrence, améliorant ainsi les performances et la fiabilité des options de sérialisation. Voici quelques-uns des éléments suivants :

  • Meilleure prise en charge pour le mélange de code synchrone et asynchrone dans les appels à SocketConnection.BeginRead et à SocketConnection.Read.
  • Amélioration de la fiabilité lors de l’abandon d’une connexion avec SharedConnectionListener et DuplexChannelBinder.
  • Amélioration de la fiabilité des opérations de sérialisation lors de l’appel de la méthode FormatterServices.GetSerializableMembers(Type).
  • Meilleure fiabilité lors de la suppression d’un objet waiter en appelant la méthode ChannelSynchronizer.RemoveWaiter.

Windows Forms

Dans .NET Framework 4.7, Windows Forms améliore la prise en charge des moniteurs DPI élevés.

Prise en charge de la haute résolution

À partir des applications qui ciblent .NET Framework 4.7, .NET Framework prend en charge la haute résolution et la haute résolution dynamique pour les applications Windows Forms. La prise en charge des DPI élevés améliore la mise en page et l’apparence des formulaires et des éléments de contrôle sur des moniteurs à haute DPI. Le DPI dynamique modifie la disposition et l'apparence des formulaires et des contrôles lorsque l'utilisateur change le DPI ou le facteur d'échelle d'affichage d'une application en cours.

La prise en charge des DPI élevés est une fonctionnalité à activer que vous configurez en définissant une section <System.Windows.Forms.ConfigurationSection> dans votre fichier de configuration d’application. Pour plus d'informations sur l'ajout de la prise en charge des résolutions élevées DPI et de la prise en charge dynamique des DPI à votre application Windows Forms, consultez High DPI Support in Windows Forms.

Windows Presentation Foundation (WPF)

Dans .NET Framework 4.7, WPF inclut les améliorations suivantes :

Prise en charge d’une pile tactile/de stylet basée sur les messages Windows WM_POINTER

Vous pouvez désormais utiliser une fonction tactile ou stylet basée sur les messages WM_POINTER, au lieu de la plateforme WISP (Windows Ink Services Platform). Il s’agit d’une fonctionnalité d’opt-in dans .NET Framework. Pour plus d’informations, consultez la section Compatibilité des applications.

Nouvelle implémentation pour les API d’impression WPF

Les API d’impression de WPF de la classe System.Printing.PrintQueue appellent l’API Print Document Package de Windows au lieu de l’API d’impression XPS dépréciée. Pour plus d’informations sur l’impact de cette modification sur la compatibilité des applications, consultez la section compatibilité des applications.

Nouveautés de .NET Framework 4.6.2

.NET Framework 4.6.2 inclut de nouvelles fonctionnalités dans les domaines suivants :

Pour obtenir la liste des nouvelles API ajoutées à .NET Framework 4.6.2, consultez modifications apportées aux API .NET Framework 4.6.2 sur GitHub. Pour obtenir la liste des améliorations des fonctionnalités et des correctifs de bogues dans .NET Framework 4.6.2, consultez .NET Framework 4.6.2 Liste des modifications sur GitHub. Pour plus d’informations, consultez l'annonce de .NET Framework 4.6.2 sur le blog .NET.

ASP.NET

Dans .NET Framework 4.6.2, ASP.NET inclut les améliorations suivantes :

Prise en charge améliorée des messages d’erreur localisés dans les validateurs d’annotation de données

Les validateurs d’annotation de données vous permettent d’effectuer la validation en ajoutant un ou plusieurs attributs à une propriété de classe. L’élément ValidationAttribute.ErrorMessage de l’attribut définit le texte du message d’erreur en cas d’échec de la validation. À compter de .NET Framework 4.6.2, ASP.NET facilite la localisation des messages d’erreur. Les messages d’erreur sont localisés si :

  1. Le ValidationAttribute.ErrorMessage est fourni dans l’attribut de validation.

  2. Le fichier de ressources est stocké dans le dossier App_LocalResources.

  3. Le nom du fichier de ressources localisées porte le nom DataAnnotation.Localization.{}.resx, où nom est un nom de culture au format languageCode-country/regionCode ou languageCode.

  4. Le nom de clé de la ressource est la chaîne affectée à l’attribut ValidationAttribute.ErrorMessage, et sa valeur est le message d’erreur localisé.

Par exemple, l’attribut d’annotation de données suivant définit le message d’erreur de la culture par défaut pour une évaluation non valide.

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

Vous pouvez ensuite créer un fichier de ressources, DataAnnotation.Localization.fr.resx, dont la clé est la chaîne de message d’erreur et dont la valeur est le message d’erreur localisé. Le fichier doit se trouver dans le dossier App.LocalResources. Par exemple, voici la clé et sa valeur dans un message d’erreur en français localisé (fr) :

Nom Valeur
L’évaluation doit être comprise entre 1 et 10. La note doit être comprise entre 1 et 10.

En outre, la localisation des annotations de données est extensible. Les développeurs peuvent se connecter à leur propre fournisseur de localiseur de chaînes en implémentant l’interface IStringLocalizerProvider pour stocker la chaîne de localisation ailleurs que dans un fichier de ressources.

Prise en charge asynchrone avec les fournisseurs de magasins d’état de session

ASP.NET autorise désormais l’utilisation de méthodes retournant des tâches avec les fournisseurs de magasins d’état de session, ce qui permet ainsi aux applications ASP.NET de profiter de la scalabilité des opérations asynchrones. Pour prendre en charge les opérations asynchrones avec les fournisseurs de magasin d’état de session, ASP.NET inclut une nouvelle interface, System.Web.SessionState.ISessionStateModule, qui hérite de IHttpModule et permet aux développeurs d’implémenter leurs propres modules d’état de session et fournisseurs de magasins de sessions asynchrones. L’interface est définie comme suit :

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

En outre, la classe SessionStateUtility comprend deux nouvelles méthodes, IsSessionStateReadOnly et IsSessionStateRequired, qui peuvent être utilisées pour prendre en charge les opérations asynchrones.

Prise en charge asynchrone des fournisseurs de cache de sortie

À compter de .NET Framework 4.6.2, les méthodes de retour de tâches peuvent être utilisées avec des fournisseurs de cache de sortie pour offrir les avantages de l’extensibilité d’async. Les fournisseurs qui implémentent ces méthodes réduisent le blocage des threads sur un serveur web et améliorent l’extensibilité d’un service ASP.NET.

Les API suivantes ont été ajoutées pour prendre en charge les fournisseurs de cache de sortie asynchrones :

Catégories de caractères

Les caractères de .NET Framework 4.6.2 sont classés en fonction de la Standard Unicode, version 8.0.0. Dans .NET Framework 4.6 et .NET Framework 4.6.1, les caractères ont été classés en fonction des catégories de caractères Unicode 6.3.

La prise en charge d’Unicode 8.0 est limitée à la classification des caractères par la classe CharUnicodeInfo et aux types et méthodes qui s’y appuient. Il s’agit notamment de la classe StringInfo, de la méthode Char.GetUnicodeCategory surchargée et des classes de caractères reconnues par le moteur d’expression régulière .NET Framework. La comparaison de caractères et de chaînes et le tri ne sont pas affectés par cette modification et continuent de s’appuyer sur le système d’exploitation sous-jacent ou, sur les systèmes Windows 7, sur les données de caractères fournies par .NET Framework.

Pour connaître les modifications apportées aux catégories de caractères d’Unicode 6.0 à Unicode 7.0, consultez La norme Unicode, version 7.0.0 sur le site web du Consortium Unicode. Pour connaître les modifications apportées d'Unicode 7.0 à Unicode 8.0, consultez la version 8.0.0 du Standard Unicode sur le site web du Consortium Unicode.

Cryptographie

Prise en charge des certificats X509 contenant l’algorithme DSA FIPS 186-3

.NET Framework 4.6.2 ajoute la prise en charge des certificats X509 DSA (Digital Signature Algorithm) dont les clés dépassent la limite FIPS 186-2 1024 bits.

En plus de prendre en charge les tailles de clés plus importantes de FIPS 186-3, .NET Framework 4.6.2 autorise l’informatique des signatures avec la famille SHA-2 d’algorithmes de hachage (SHA256, SHA384 et SHA512). La prise en charge de FIPS 186-3 est fournie par la nouvelle classe System.Security.Cryptography.DSACng.

Conformément aux modifications récentes apportées à la classe RSA dans .NET Framework 4.6 et à la classe ECDsa dans .NET Framework 4.6.1, la classe de base abstraite DSA dans .NET Framework 4.6.2 a des méthodes supplémentaires pour permettre aux appelants d’utiliser cette fonctionnalité sans conversion. Vous pouvez appeler la méthode d’extension DSACertificateExtensions.GetDSAPrivateKey pour signer des données, comme l’illustre l’exemple suivant.

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

Vous pouvez également appeler la méthode d’extension DSACertificateExtensions.GetDSAPublicKey pour vérifier les données signées, comme l’illustre l’exemple suivant.

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

Plus de clarté pour les entrées dans les routines de dérivation de clé ECDiffieHellman

.NET Framework 3.5 a ajouté la prise en charge de l'Accord de Clé à Courbe Elliptique Diffie-Hellman avec trois routines différentes de fonction de dérivation de clé (KDF). Les entrées des routines, et les routines elles-mêmes, ont été configurées via des propriétés sur l’objet ECDiffieHellmanCng. Mais comme les routines ne pouvaient pas toutes lire chaque propriété d’entrée, la confusion était de mise auprès des développeurs.

Pour résoudre ce problème dans .NET Framework 4.6.2, les trois méthodes suivantes ont été ajoutées à la classe de base ECDiffieHellman pour représenter plus clairement ces routines KDF et leurs entrées :

ECDiffieHellman, méthode Description
DeriveKeyFromHash(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[]) Dérive un matériau clé à l’aide de la formule

HASH(secretPrepend || x || secretAppend)

HASH(secretPrepend OrElse x OrElse secretAppend)

où x est le résultat calculé de l’algorithme ec Diffie-Hellman.
DeriveKeyFromHmac(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[], Byte[]) Dérive un matériau clé à l’aide de la formule

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

HMAC(hmacKey, secretPrepend OrElse x OrElse secretAppend)

où x est le résultat calculé de l’algorithme ec Diffie-Hellman.
DeriveKeyTls(ECDiffieHellmanPublicKey, Byte[], Byte[]) Dérive le matériau clé à l’aide de l’algorithme de dérivation pseudo-aléatoire TLS (PRF).

Prise en charge du chiffrement symétrique des clés persistantes

La bibliothèque de chiffrement Windows (CNG) a ajouté la prise en charge du stockage de clés symétriques persistantes et l’utilisation de clés symétriques stockées par le matériel, et .NET Framework 4.6.2 a permis aux développeurs d’utiliser cette fonctionnalité. Étant donné que la notion de noms de clés et de fournisseurs de clés est spécifique à l’implémentation, l’utilisation de cette fonctionnalité nécessite d’utiliser le constructeur des types d’implémentation concrets au lieu de l’approche de fabrique préférée (par exemple, appeler Aes.Create).

La prise en charge du chiffrement symétrique à clé persistante existe pour les algorithmes AES (AesCng) et 3DES (TripleDESCng). Par exemple:

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

Prise en charge de SignedXml pour le hachage SHA-2

.NET Framework 4.6.2 ajoute une prise en charge à la classe SignedXml pour les méthodes de signature RSA-SHA256, RSA-SHA384, and RSA-SHA512 PKCS#1, ainsi que pour les algorithmes Digest de référence SHA256, SHA384 et SHA512.

Les constantes URI sont toutes exposées sur SignedXml:

Champ SignedXml Constante
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"

Tous les programmes qui ont inscrit un gestionnaire de SignatureDescription personnalisé dans CryptoConfig pour ajouter la prise en charge de ces algorithmes continueront de fonctionner comme ils l’ont fait dans le passé, mais étant donné qu’il existe désormais des valeurs par défaut de plateforme, l’inscription CryptoConfig n’est plus nécessaire.

SqlClient

Le fournisseur de données .NET Framework pour SQL Server (System.Data.SqlClient) inclut les nouvelles fonctionnalités suivantes dans .NET Framework 4.6.2 :

Regroupement de connexions et délais d’expiration avec des bases de données Azure SQL

Lorsque le regroupement de connexions est activé et qu’un délai d’attente ou une autre erreur de connexion se produit, une exception est mise en cache et l’exception mise en cache est levée lors de toute tentative de connexion suivante pour les 5 secondes à 1 minute suivantes. Pour plus d’informations, consultez Regroupement de connexions SQL Server (ADO.NET).

Ce comportement n’est pas souhaitable lors de la connexion aux bases de données Azure SQL, car les tentatives de connexion peuvent échouer avec des erreurs temporaires qui sont généralement récupérées rapidement. Pour optimiser l’expérience de nouvelle tentative de connexion, le comportement de la période de blocage du pool de connexions est supprimé lorsque les connexions aux bases de données Azure SQL échouent.

L’ajout du nouveau mot clé PoolBlockingPeriod vous permet de sélectionner la période de blocage la mieux adaptée à votre application. Les valeurs sont les suivantes :

Auto

La période de blocage du pool de connexions pour une application qui se connecte à une base de données Azure SQL est désactivée et la période de blocage du pool de connexions pour une application qui se connecte à une autre instance SQL Server est activée. Il s’agit de la valeur par défaut. Si le nom du point de terminaison du serveur se termine par l’un des éléments suivants, ils sont considérés comme des bases de données Azure SQL :

  • .database.windows.net

  • .database.chinacloudapi.cn

  • .database.usgovcloudapi.net

  • .database.cloudapi.de

AlwaysBlock

La période de blocage du pool de connexions est toujours activée.

NeverBlock

La période de blocage du pool de connexions est toujours désactivée.

Améliorations pour Always Encrypted

SQLClient présente deux améliorations pour Always Encrypted :

  • Pour améliorer les performances des requêtes paramétrables sur des colonnes de base de données chiffrées, les métadonnées de chiffrement pour les paramètres de requête sont désormais mises en cache. Avec la propriété SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled définie sur true (valeur par défaut), si la même requête est appelée plusieurs fois, le client récupère les métadonnées de paramètre du serveur une seule fois.

  • Les entrées de clé de chiffrement de colonne dans le cache de clés sont désormais supprimées après un intervalle de temps configurable, définies à l’aide de la propriété SqlConnection.ColumnEncryptionKeyCacheTtl.

Windows Communication Foundation

Dans .NET Framework 4.6.2, Windows Communication Foundation a été amélioré dans les domaines suivants :

Prise en charge des certificats stockés à l’aide de CNG par la sécurité du transport WCF

La sécurité du transport WCF prend en charge les certificats stockés à l’aide de la bibliothèque de chiffrement Windows (CNG). Dans .NET Framework 4.6.2, cette prise en charge est limitée à l’utilisation de certificats avec une clé publique qui n’a pas plus de 32 bits de longueur. Lorsqu’une application cible .NET Framework 4.6.2, cette fonctionnalité est activée par défaut.

Pour les applications qui ciblent .NET Framework 4.6.1 et versions antérieures, mais qui s’exécutent sur .NET Framework 4.6.2, cette fonctionnalité peut être activée en ajoutant la ligne suivante à la section <runtime> du fichier app.config ou web.config.

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

Cela peut également être effectué par programmation avec du code comme suit :

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

Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

Meilleure prise en charge de plusieurs règles d’ajustement du temps d’été par la classe DataContractJsonSerializer

Les clients peuvent utiliser un paramètre de configuration d’application pour déterminer si la classe DataContractJsonSerializer prend en charge plusieurs règles d’ajustement pour un fuseau horaire unique. Il s’agit d’une fonctionnalité d’adhésion. Pour l’activer, ajoutez le paramètre suivant à votre fichier app.config :

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

Lorsque cette fonctionnalité est activée, un objet DataContractJsonSerializer utilise le type TimeZoneInfo au lieu du type TimeZone pour désérialiser les données de date et d’heure. TimeZoneInfo prend en charge plusieurs règles d’ajustement, ce qui permet d’utiliser des données de fuseau horaire historiques ; TimeZone ne le fait pas.

Pour plus d’informations sur la structure TimeZoneInfo et les ajustements de fuseau horaire, consultez Vue d’ensemble du fuseau horaire.

Meilleure correspondance NetNamedPipeBinding

WCF propose un nouveau paramètre d’application qui peut être défini sur les applications clientes de telle sorte qu’elles se connectent systématiquement au service écoutant l’URI qui correspond le mieux à celui qu’elles demandent. Avec ce paramètre d’application réglé sur false (valeur par défaut), il est possible pour les clients utilisant NetNamedPipeBinding d'essayer de se connecter à un service écoutant sur un URI qui est une sous-chaîne de l'URI demandé.

Par exemple, un client tente de se connecter à un service à l’écoute de net.pipe://localhost/Service1, mais un autre service de cet ordinateur s’exécutant avec des privilèges d’administrateur écoute net.pipe://localhost. Avec ce paramètre d’application défini sur false, le client tente de se connecter au service incorrect. Après avoir défini le paramètre d’application sur true, le client se connecte toujours au service correspondant le mieux adapté.

Remarque

Les clients qui utilisent NetNamedPipeBinding recherchent des services en fonction de l’adresse de base du service (si elle existe) plutôt que de l’adresse de point de terminaison complète. Pour garantir que ce paramètre fonctionne toujours, le service doit utiliser une adresse de base unique.

Pour activer cette modification, ajoutez le paramètre d’application suivant au fichier App.config ou Web.config de votre application cliente :

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

SSL 3.0 n’est pas un protocole par défaut

Lorsque vous utilisez NetTcp avec sécurité de transport et un type de certificat d’informations d’identification, SSL 3.0 n’est plus un protocole par défaut utilisé pour négocier une connexion sécurisée. Dans la plupart des cas, il ne doit pas y avoir d’impact sur les applications existantes, car TLS 1.0 est inclus dans la liste des protocoles pour NetTcp. Tous les clients existants doivent pouvoir négocier une connexion à l’aide d’au moins TLS 1.0. Si Ssl3 est requis, utilisez l’un des mécanismes de configuration suivants pour l’ajouter à la liste des protocoles négociés.

Windows Presentation Foundation (WPF)

Dans .NET Framework 4.6.2, Windows Presentation Foundation a été amélioré dans les domaines suivants :

Tri des groupes

Une application qui utilise un objet CollectionView pour regrouper des données peut désormais déclarer explicitement comment trier les groupes. Le tri explicite résout le problème de l’ordre non intuitif qui se produit lorsqu’une application ajoute ou supprime dynamiquement des groupes, ou lorsqu’elle modifie la valeur des propriétés d’élément impliquées dans le regroupement. Il peut également améliorer les performances du processus de création de groupe en déplaçant les comparaisons des propriétés de regroupement du type de la collection complète au type des groupes.

Pour prendre en charge le tri de groupe, les nouvelles propriétés GroupDescription.SortDescriptions et GroupDescription.CustomSort décrivent comment trier la collection de groupes produite par l’objet GroupDescription. Cela est analogue à la façon dont les propriétés ListCollectionView identiquement nommées décrivent comment trier les éléments de données.

Deux nouvelles propriétés statiques de la classe PropertyGroupDescription, CompareNameAscending et CompareNameDescending, peuvent être utilisées pour les cas les plus courants.

Par exemple, les données XAML suivantes regroupent les données par âge, trient les groupes d’âge par ordre croissant et regroupent les éléments au sein de chaque groupe d’âge par nom.

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

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

Prise en charge des claviers tactiles

La prise en charge du clavier tactile permet le suivi des focus dans les applications WPF en appelant et en supprimant automatiquement le clavier tactile dans Windows 10 lorsque l’entrée tactile est reçue par un contrôle qui peut prendre une entrée textuelle.

Dans les versions précédentes de .NET Framework, les applications WPF ne peuvent pas opter pour le suivi du focus sans désactiver la prise en charge du stylo et des entrées tactiles WPF. Par conséquent, les applications WPF doivent soit choisir la prise en charge complète des entrées tactiles WPF, soit privilégier la souris Windows.

Résolution par moniteur

Pour faire face à la prolifération récente des environnements à haute résolution et à résolution hybride pour les applications WPF, WPF dans .NET Framework 4.6.2 autorise une prise en charge par moniteur. Consultez les exemples et le guide du développeur sur GitHub pour savoir comment rendre votre application WPF compatible avec la prise en charge du DPI par moniteur.

Dans les versions précédentes de .NET Framework, les applications WPF étaient conscientes du DPI du système. En d’autres termes, l’interface utilisateur de l’application est mise à l’échelle par le système d’exploitation en fonction du PPP du moniteur sur lequel l’application est affichée.

Pour les applications s’exécutant sous .NET Framework 4.6.2, vous pouvez désactiver les modifications de PPP par moniteur dans les applications WPF en ajoutant une instruction de configuration à la section <runtime> de votre fichier de configuration d’application, comme suit :

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

Windows Workflow Foundation (WF)

Dans .NET Framework 4.6.2, Windows Workflow Foundation a été amélioré dans la zone suivante :

Prise en charge des expressions C# et d’IntelliSense dans le Concepteur de flux de travail réhébergé

À compter de .NET Framework 4.5, WF prend en charge les expressions C# dans le Concepteur Visual Studio et dans les flux de travail de code. Le Concepteur de flux de travail réhébergé est une fonctionnalité clé de WF qui permet au Concepteur de flux de travail d’être dans une application en dehors de Visual Studio (par exemple, dans WPF). Windows Workflow Foundation permet de prendre en charge les expressions C# et IntelliSense dans le Concepteur de flux de travail réhébergé. Pour plus d’informations, consultez le blog Windows Workflow Foundation.

Availability of IntelliSense when a customer rebuilds a workflow project from Visual Studio Dans les versions du .NET Framework antérieures à la version 4.6.2, WF Designer IntelliSense est rompu lorsqu’un client reconstruit un projet de flux de travail à partir de Visual Studio. Quand la génération du projet aboutit, les types de flux de travail ne se trouvent pas dans le concepteur, et IntelliSense affiche des avertissements dans la fenêtre Liste d’erreurs par rapport aux types de flux de travail manquants. .NET Framework 4.6.2 résout ce problème et rend IntelliSense disponible.

Les applications Workflow V1 avec Workflow Tracking activé s'exécutent désormais en mode FIPS

Les machines avec le mode de conformité FIPS activé peuvent désormais exécuter une application de style workflow version 1 avec le suivi de flux de travail activé. Pour activer ce scénario, vous devez apporter la modification suivante à votre fichier app.config :

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

Si ce scénario n’est pas activé, l’exécution de l’application continue de générer une exception avec le message « Cette implémentation ne fait pas partie des algorithmes de chiffrement validés fiPS de la plateforme Windows ».

améliorations apportées aux flux de travail lors de l’utilisation de la mise à jour dynamique avec le Concepteur de flux de travail Visual Studio

Le Concepteur de flux de travail, le Concepteur d’activités d’organigramme et les autres Concepteurs d’activité de flux de travail peuvent désormais charger et afficher les flux de travail qui ont été enregistrés consécutivement à l’appel de la méthode DynamicUpdateServices.PrepareForUpdate. Dans les versions du .NET Framework avant .NET Framework 4.6.2, le chargement d’un fichier XAML dans Visual Studio pour un flux de travail enregistré après l’appel de DynamicUpdateServices.PrepareForUpdate peut entraîner les problèmes suivants :

  • Le Concepteur de flux de travail ne peut pas charger correctement le fichier XAML (lorsque le ViewStateData.Id se trouve à la fin de la ligne).

  • Le Concepteur d’activités de diagramme de flux ou d’autres concepteurs d’activités de flux de travail peut afficher tous les objets dans leurs emplacements par défaut, par opposition aux valeurs de propriété jointes.

ClickOnce

ClickOnce a été mis à jour pour prendre en charge TLS 1.1 et TLS 1.2 en plus du protocole 1.0, qu’il prend déjà en charge. ClickOnce détecte automatiquement le protocole requis ; Aucune étape supplémentaire dans l’application ClickOnce n’est nécessaire pour activer la prise en charge de TLS 1.1 et 1.2.

Conversion d’applications Windows Forms et WPF en applications UWP

Windows offre désormais des fonctionnalités permettant d’apporter des applications de bureau Windows existantes, notamment des applications WPF et Windows Forms, à la plateforme Windows universelle (UWP). Cette technologie agit comme un pont en vous permettant de migrer progressivement votre base de code existante vers UWP, ce qui apporte votre application à tous les appareils Windows 10.

Les applications de bureau converties obtiennent une identité d’application similaire à l’identité d’application des applications UWP, ce qui rend les API UWP accessibles pour activer des fonctionnalités telles que les vignettes dynamiques et les notifications. L’application continue de se comporter comme avant et s’exécute en tant qu’application de confiance totale. Une fois l’application convertie, un processus de conteneur d’application peut être ajouté au processus de confiance totale existant pour ajouter une interface utilisateur adaptative. Lorsque toutes les fonctionnalités sont déplacées vers le processus de conteneur d’application, le processus de confiance totale peut être supprimé et la nouvelle application UWP peut être mise à la disposition de tous les appareils Windows 10.

Améliorations du débogage

L’API de débogage non managée a été améliorée dans .NET Framework 4.6.2 de façon à effectuer des analyses supplémentaires quand un NullReferenceException est levé dans le but de permettre l’identification de la variable qui a la valeur null dans une même ligne de code source. Pour prendre en charge ce scénario, les API suivantes ont été ajoutées à l’API de débogage non managée.

Nouveautés de .NET Framework 4.6.1

.NET Framework 4.6.1 inclut de nouvelles fonctionnalités dans les domaines suivants :

Pour plus d’informations sur .NET Framework 4.6.1, consultez les rubriques suivantes :

Chiffrement : prise en charge des certificats X509 contenant ECDSA

.NET Framework 4.6 a ajouté la prise en charge de RSACng pour les certificats X509. .NET Framework 4.6.1 prend en charge les certificats X509 ECDSA (Elliptic Curve Digital Signature Algorithm).

ECDSA offre de meilleures performances et est un algorithme de chiffrement plus sécurisé que RSA, offrant un excellent choix où les performances et l’extensibilité du protocole TLS (Transport Layer Security) sont un problème. L’implémentation du .NET Framework encapsule les appels dans les fonctionnalités Windows existantes.

L’exemple de code suivant montre comment il est facile de générer une signature pour un flux d’octets à l’aide de la nouvelle prise en charge des certificats ECDSA X509 inclus dans .NET Framework 4.6.1.

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

Cela offre un contraste marqué avec le code nécessaire pour générer une signature dans .NET Framework 4.6.

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

Les éléments suivants ont été ajoutés à ADO.NET :

Prise en charge de la fonctionnalité Always Encrypted pour les clés matérielles protégées

ADO.NET prend désormais en charge le stockage des clés principales de colonne Always Encrypted en mode natif dans les modules de sécurité matériels (HSM). Cette prise en charge permet aux clients de tirer profit des clés asymétriques stockées dans les modules HSM sans avoir à écrire des fournisseurs de magasins de clés principales de colonnes personnalisés et sans les inscrire dans les applications.

Les clients doivent installer le fournisseur CSP fourni par le fournisseur HSM ou les fournisseurs de magasin de clés CNG sur les serveurs d’applications ou les ordinateurs clients afin d’accéder aux données Always Encrypted protégées avec des clés principales de colonne stockées dans un HSM.

Comportement de connexion amélioré MultiSubnetFailover pour AlwaysOn

SqlClient fournit désormais automatiquement des connexions plus rapides à un groupe de disponibilité AlwaysOn. Il détecte de manière transparente si votre application se connecte à un groupe de disponibilité AlwaysOn sur un autre sous-réseau et découvre rapidement le serveur actif actuel et fournit une connexion au serveur. Avant cette version, une application devait définir la chaîne de connexion pour inclure "MultisubnetFailover=true" pour indiquer qu’elle se connectait à un groupe de disponibilité AlwaysOn. Si le mot clé de connexion n’était pas défini sur true, une application pouvait rencontrer un dépassement du délai lors de la connexion à un groupe de disponibilité AlwaysOn. Avec cette version, une application n’a plus besoin de définir MultiSubnetFailover sur true. Pour plus d’informations sur la prise en charge de SqlClient pour les groupes de disponibilité AlwaysOn, consultez Prise en charge de SqlClient pour la haute disponibilité et la récupération d’urgence.

Windows Presentation Foundation (WPF)

Windows Presentation Foundation inclut un certain nombre d’améliorations et de modifications.

amélioration des performances

Le délai de déclenchement des événements tactiles a été résolu dans .NET Framework 4.6.1. En outre, la saisie dans un contrôle RichTextBox ne mobilise plus le thread de rendu pendant la saisie rapide.

améliorations apportées à la vérification orthographique

Le vérificateur orthographique dans WPF a été mis à jour sur Windows 8.1 et versions ultérieures pour tirer parti de la prise en charge du système d’exploitation pour la vérification orthographique des langues supplémentaires. Il n’existe aucune modification des fonctionnalités sur les versions de Windows antérieures à Windows 8.1.

Comme dans les versions précédentes de .NET Framework, le langage d’un contrôle TextBox ou d’un bloc RichTextBox est détecté en recherchant des informations dans l’ordre suivant :

  • xml:lang, le cas échéant.

  • Langue d’entrée actuelle.

  • Culture actuelle.

Pour plus d’informations sur la prise en charge du langage dans WPF, consultez le billet de blog WPF sur les fonctionnalités de .NET Framework 4.6.1.

Prise en charge supplémentaire des dictionnaires personnalisés par utilisateur

Dans .NET Framework 4.6.1, WPF reconnaît les dictionnaires personnalisés inscrits globalement. Cette fonctionnalité est disponible en plus de la possibilité de les enregistrer pour chaque contrôle.

Dans les versions précédentes de WPF, les dictionnaires personnalisés n’ont pas reconnu les mots exclus et les listes de correction automatique. Ils sont pris en charge sur Windows 8.1 et Windows 10 via l’utilisation de fichiers pouvant être placés sous le répertoire %AppData%\Microsoft\Spelling\<language tag>. Les règles suivantes s’appliquent à ces fichiers :

  • Les fichiers doivent avoir des extensions de .dic (pour les mots ajoutés), .exc (pour les mots exclus) ou .acl (pour la correction automatique).

  • Les fichiers doivent être du texte clair UTF-16 LE qui commence par la marque d’ordre d’octet (BOM).

  • Chaque ligne doit se composer d’un mot (dans les listes de mots ajoutés et exclus) ou d’une paire de corrections automatiques avec les mots séparés par une barre verticale (« | ») (dans la liste de mots de correction automatique).

  • Ces fichiers sont considérés comme en lecture seule et ne sont pas modifiés par le système.

Remarque

Ces nouveaux formats de fichiers ne sont pas directement pris en charge par les API de vérification orthographique WPF, et les dictionnaires personnalisés fournis à WPF dans les applications doivent continuer à utiliser des fichiers .lex.

Exemples

Il existe un certain nombre d’exemples WPF sur le dépôt Microsoft/WPF-Samples GitHub. Aidez-nous à améliorer nos exemples en nous envoyant une pull-request ou en ouvrant un problème sur GitHub .

Extensions DirectX

WPF inclut un package NuGet qui fournit de nouvelles implémentations de D3DImage qui vous permettent d’interagir facilement avec du contenu DX10 et Dx11. Le code de ce package a été open source et est disponible sur GitHub.

Windows Workflow Foundation : Transactions

La méthode Transaction.EnlistPromotableSinglePhase peut désormais utiliser un gestionnaire de transactions distribué autre que MSDTC pour promouvoir la transaction. Pour ce faire, spécifiez un identificateur de promoteur de transaction GUID pour la nouvelle surcharge Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid). Si cette opération réussit, il existe des limitations sur les fonctionnalités de la transaction. Une fois qu’un promoteur de transaction non MSDTC est inscrit, les méthodes suivantes lèvent un TransactionPromotionException car ces méthodes nécessitent une promotion vers MSDTC :

Une fois qu’un promoteur de transaction non MSDTC est inscrit, il doit être utilisé pour les inscriptions durables futures à l’aide de protocoles qu’il définit. Vous pouvez obtenir le Guid du promoteur de transaction à l’aide de la propriété PromoterType. Lorsque la transaction est promue, le promoteur de transaction fournit un tableau Byte qui représente le jeton promu. Une application peut obtenir le jeton promu pour une transaction non-MSDTC promue avec la méthode GetPromotedToken.

Les utilisateurs de la nouvelle surcharge Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) doit suivre une séquence d’appel spécifique pour que l’opération de promotion se termine correctement. Ces règles sont documentées dans la documentation de la méthode.

Profilage

L’API de profilage non managée a été améliorée comme suit :

  • Meilleure prise en charge de l'accès aux fichiers PDB dans l'interface ICorProfilerInfo7.

    Dans ASP.NET Core, il devient beaucoup plus courant que les assemblys soient compilés en mémoire par Roslyn. Pour les développeurs qui effectuent des outils de profilage, cela signifie que les PDB qui ont historiquement été sérialisées sur le disque peuvent ne plus être présentes. Les outils de profilage utilisent souvent des PDB pour associer le code aux lignes sources pour des tâches telles que la couverture du code ou l’analyse des performances ligne par ligne. L’interface ICorProfilerInfo7 comprend désormais deux nouvelles méthodes, ICorProfilerInfo7 ::GetInMemorySymbolsLength et ICorProfilerInfo7 ::ReadInMemorySymbols, pour fournir à ces profileurs un accès aux données PDB en mémoire, À l’aide des nouvelles API, un profileur peut obtenir le contenu d’une base de données PDB en mémoire en tant que tableau d’octets, puis le traiter ou le sérialiser sur le disque.

  • Meilleure instrumentation avec l’interface ICorProfiler.

    Les profileurs qui utilisent la fonctionnalité ReJit des API ICorProfiler pour l’instrumentation dynamique peuvent désormais modifier certaines métadonnées. Auparavant, ces outils pouvaient instrumenter il à tout moment, mais les métadonnées ne pouvaient être modifiées qu’au moment du chargement du module. Étant donné que le langage intermédiaire fait référence aux métadonnées, cela limitait les types d’instrumentation qui pouvaient être effectuées. Nous avons levé certaines de ces limites en ajoutant la méthode ICorProfilerInfo7 ::ApplyMetaData pour prendre en charge un sous-ensemble de modifications de métadonnées après le chargement du module, en particulier en ajoutant de nouveaux AssemblyRef, TypeRef, TypeSpec, MemberRef, MemberSpecet UserString enregistrements. Cette modification rend possible une plus grande gamme d’instrumentation à la volée.

Fichiers PDF du générateur d’images natives (NGEN)

Le suivi d’événements inter-ordinateurs permet aux clients de profiler un programme sur l’ordinateur A et d’examiner les données de profilage avec le mappage de ligne source sur la machine B. À l’aide des versions précédentes de .NET Framework, l’utilisateur copie tous les modules et images natives de l’ordinateur profilé vers l’ordinateur d’analyse qui contient la base de données PDB IL pour créer le mappage source à natif. Bien que ce processus fonctionne bien lorsque les fichiers sont relativement petits, tels que pour les applications téléphoniques, les fichiers peuvent être très volumineux sur les systèmes de bureau et nécessiter beaucoup de temps pour copier.

Avec les PDB NGen, NGen peut créer un fichier PDB qui contient le mappage IL-vers-natif sans dépendance sur le PDB IL. Dans notre scénario de suivi d’événements entre ordinateurs, il suffit de copier le fichier PDB de l’image native généré par l’Ordinateur A sur l’Ordinateur B et d’utiliser les API Debug Interface Access pour lire le mappage du code source au code en langage intermédiaire du fichier PDB en langage intermédiaire et le mappage du code en langage intermédiaire au code natif du fichier PDB de l’image native. La combinaison des deux mappages fournit un mappage du code source au code natif. Étant donné que l’image native PDB est beaucoup plus petite que tous les modules et images natives, le processus de copie de machine A vers la machine B est beaucoup plus rapide.

Nouveautés de .NET 2015

.NET 2015 introduit .NET Framework 4.6 et .NET Core. Certaines nouvelles fonctionnalités s’appliquent aux deux, et d’autres fonctionnalités sont spécifiques à .NET Framework 4.6 ou .NET Core.

  • ASP.NET Core

    .NET 2015 inclut ASP.NET Core, qui est une implémentation .NET maigre pour la création d’applications cloud modernes. ASP.NET Core est modulaire pour vous permettre d’inclure uniquement les fonctionnalités nécessaires dans votre application. Il peut être hébergé sur IIS ou auto-hébergé dans un processus personnalisé, et vous pouvez exécuter des applications avec différentes versions du .NET Framework sur le même serveur. Il inclut un nouveau système de configuration d’environnement conçu pour le déploiement cloud.

    MVC, API web et pages web sont unifiés dans un seul framework appelé MVC 6. Vous générez des applications ASP.NET Core via des outils dans Visual Studio 2015 ou version ultérieure. Vos applications existantes fonctionnent sur le nouveau .NET Framework ; Toutefois, pour créer une application qui utilise MVC 6 ou SignalR 3, vous devez utiliser le système de projet dans Visual Studio 2015 ou version ultérieure.

    Pour plus d’informations, consultez ASP.NET core.

  • Mises à jour ASP.NET

    • API basée sur des tâches pour le vidage de réponse asynchrone

      ASP.NET fournit désormais une API simple basée sur des tâches pour le vidage asynchrone des réponses, HttpResponse.FlushAsync, qui permet de vider les réponses de manière asynchrone à l’aide de la prise en charge async/await de votre langage.

    • La liaison de modèle prend en charge les méthodes retournant Task

      Dans le .NET Framework 4.5, ASP.NET a ajouté la fonctionnalité de Liaison de Modèle, permettant une approche extensible orientée code pour les opérations de données CRUD dans les pages Web Forms et les contrôles utilisateur. Le système de liaison de modèle prend désormais en charge les méthodes de liaison de modèle avec renvoi de Task. Cette fonctionnalité permet aux développeurs Web Forms d’obtenir les avantages de l’extensibilité d’async avec la facilité du système de liaison de données lors de l’utilisation de versions plus récentes d’ORMs, y compris Entity Framework.

      La liaison de modèle asynchrone est contrôlée par le paramètre de configuration aspnet:EnableAsyncModelBinding.

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

      Pour les applications utilisant le .NET Framework 4.6, il est défini par défaut sur true. Sur les applications s’exécutant sur .NET Framework 4.6 qui ciblent une version antérieure de .NET Framework, elle est false par défaut. Il peut être activé en définissant le paramètre de configuration sur true.

    • Prise en charge de HTTP/2 (Windows 10)

      HTTP/2 est une nouvelle version du protocole HTTP qui offre une meilleure utilisation de la connexion (moins d’allers-retours entre le client et le serveur), ce qui entraîne un chargement de page web à latence inférieure pour les utilisateurs. Les pages web (par opposition aux services) bénéficient le plus de HTTP/2, car le protocole optimise pour plusieurs artefacts demandés dans le cadre d’une expérience unique. La prise en charge de HTTP/2 a été ajoutée à ASP.NET dans .NET Framework 4.6. Étant donné que la fonctionnalité de mise en réseau existe à plusieurs couches, de nouvelles fonctionnalités ont été requises dans Windows, dans IIS et dans ASP.NET pour activer HTTP/2. Vous devez utiliser Windows 10 pour utiliser HTTP/2 avec ASP.NET.

      HTTP/2 est également pris en charge et activé par défaut pour les applications de plateforme Windows universelle (UWP) Windows 10 qui utilisent l’API System.Net.Http.HttpClient.

      Pour fournir un moyen d’utiliser la fonctionnalité de PUSH_PROMISE dans ASP.NET applications, une nouvelle méthode avec deux surcharges, PushPromise(String) et PushPromise(String, String, NameValueCollection), a été ajoutée à la classe HttpResponse.

      Remarque

      Bien que ASP.NET Core prenne en charge HTTP/2, la prise en charge de la fonctionnalité PUSH PROMISE n’a pas encore été ajoutée.

      Le navigateur et le serveur web (IIS sur Windows) effectuent tout le travail. Vous n’avez pas à faire de gros efforts pour vos utilisateurs.

      La plupart des principaux navigateurs prennent en charge HTTP/2. Il est donc probable que vos utilisateurs bénéficient de la prise en charge de HTTP/2 si votre serveur le prend en charge.

    • Prise en charge du protocole de liaison de jeton

      Microsoft et Google ont travaillé en collaboration sur une nouvelle approche de l’authentification, appelée le Protocole de liaison de jeton. Le principe est que les jetons d’authentification (dans votre cache de navigateur) peuvent être volés et utilisés par des criminels pour accéder à des ressources autrement sécurisées (par exemple, votre compte bancaire) sans nécessiter votre mot de passe ou toute autre connaissance privilégiée. Le nouveau protocole vise à atténuer ce problème.

      Le protocole de liaison de jeton sera implémenté dans Windows 10 en tant que fonctionnalité de navigateur. ASP.NET applications participeront au protocole afin que les jetons d’authentification soient validés comme légitimes. Le client et les implémentations de serveur établissent la protection de bout en bout spécifiée par le protocole.

    • algorithmes de hachage de chaîne aléatoire

      .NET Framework 4.5 a introduit un algorithme de hachage de chaîne aléatoire . Toutefois, elle n’a pas été prise en charge par ASP.NET en raison de certaines fonctionnalités ASP.NET dépendent d’un code de hachage stable. Dans .NET Framework 4.6, les algorithmes de hachage de chaîne aléatoire sont désormais pris en charge. Pour activer cette fonctionnalité, utilisez le paramètre de configuration aspnet:UseRandomizedStringHashAlgorithm.

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

  • ADO.NET

    ADO .NET prend désormais en charge la fonctionnalité Always Encrypted disponible dans SQL Server 2016. Avec Always Encrypted, SQL Server peut effectuer des opérations sur des données chiffrées, et la meilleure partie de la clé de chiffrement réside avec l’application à l’intérieur de l’environnement approuvé du client et non sur le serveur. Always Encrypted sécurise les données client afin que les administrateurs de base de données n’aient pas accès aux données en texte brut. Le chiffrement et le déchiffrement des données se produisent de manière transparente au niveau du pilote, ce qui réduit les modifications qui doivent être apportées aux applications existantes. Pour plus d’informations, consultez Always Encrypted (moteur de base de données) et Always Encrypted (développement client).

  • compilateur JIT 64 bits pour code managé

    .NET Framework 4.6 propose une nouvelle version du compilateur JIT 64 bits (initialement nommé RyuJIT). Le nouveau compilateur 64 bits offre des améliorations significatives des performances sur l’ancien compilateur JIT 64 bits. Le nouveau compilateur 64 bits est activé pour les processus 64 bits s’exécutant sur .NET Framework 4.6. Votre application s’exécute dans un processus 64 bits s’il est compilé en tant que processeur 64 bits ou AnyCPU et s’exécute sur un système d’exploitation 64 bits. Même si vous avez pris soin d’effectuer la transition vers le nouveau compilateur aussi transparent que possible, les modifications apportées au comportement sont possibles.

    Le nouveau compilateur JIT 64 bits inclut également des fonctionnalités d’accélération SIMD matérielles associées à des types compatibles SIMD dans l’espace de noms System.Numerics, ce qui peut améliorer les performances.

  • Améliorations du chargeur d’assembly

    Le chargeur d’assembly utilise désormais la mémoire plus efficacement en déchargeant les assemblys IL après le chargement d’une image NGEN correspondante. Cette modification diminue la mémoire virtuelle, ce qui est particulièrement bénéfique pour les grandes applications 32 bits (telles que Visual Studio) et permet également d'économiser la mémoire physique.

  • Changements de la bibliothèque de classes de base

    De nombreuses nouvelles API ont été ajoutées à .NET Framework 4.6 pour activer les scénarios clés. Il s’agit notamment des modifications et des ajouts suivants :

    • Implémentations de <I>ReadOnlyCollectionT

      Des collections supplémentaires implémentent IReadOnlyCollection<T>, comme Queue<T> et Stack<T>.

    • CultureInfo.CurrentCulture et CultureInfo.CurrentUICulture

      Les propriétés CultureInfo.CurrentCulture et CultureInfo.CurrentUICulture sont désormais en lecture et en écriture, et non plus en lecture seule. Si vous affectez un nouvel objet CultureInfo à ces propriétés, la culture de thread actuelle définie par la propriété Thread.CurrentThread.CurrentCulture et la culture actuelle du thread d’interface utilisateur définie par les propriétés Thread.CurrentThread.CurrentUICulture changent également.

    • Améliorations apportées au garbage collection (GC)

      La classe GC inclut désormais des méthodes TryStartNoGCRegion et EndNoGCRegion qui vous permettent d'interdire le ramasse-miettes pendant l'exécution d'un trajet critique.

      Une nouvelle surcharge de la méthode GC.Collect(Int32, GCCollectionMode, Boolean, Boolean) vous permet de contrôler si le tas de petits objets et le tas d'objets volumineux sont rangés et compactés, ou rangés uniquement.

    • Types compatibles SIMD

      L’espace de noms System.Numerics inclut désormais un certain nombre de types compatibles SIMD, tels que Matrix3x2, Matrix4x4, Plane, Quaternion, Vector2, Vector3et Vector4.

      Étant donné que le nouveau compilateur JIT 64 bits inclut également des fonctionnalités d’accélération SIMD matérielle, il existe des améliorations particulièrement significatives des performances lors de l’utilisation des types compatibles SIMD avec le nouveau compilateur JIT 64 bits.

    • mises à jour de chiffrement

      L’API System.Security.Cryptography est mise à jour pour prendre en charge les API de chiffrement Windows CNG . Les versions précédentes du .NET Framework s’appuient entièrement sur une version antérieure des API de chiffrement Windows comme base pour l’implémentation System.Security.Cryptography. Nous avons eu des demandes pour prendre en charge l’API CNG, car elle prend en charge algorithmes de chiffrement modernes, qui sont importants pour certaines catégories d’applications.

      .NET Framework 4.6 inclut les nouvelles améliorations suivantes pour prendre en charge les API de chiffrement Windows CNG :

      • Ensemble de méthodes d’extension pour les certificats X509, System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2) et System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(System.Security.Cryptography.X509Certificates.X509Certificate2), qui retournent une implémentation basée sur CNG plutôt qu’une implémentation basée sur CAPI si possible. (Certaines cartes à puce, etc., nécessitent toujours CAPI, et les API gèrent le secours).

      • Classe System.Security.Cryptography.RSACng, qui fournit une implémentation CNG de l’algorithme RSA.

      • Améliorations apportées à l’API RSA afin que les actions courantes ne nécessitent plus de conversion. Par exemple, le chiffrement des données à l’aide d’un objet X509Certificate2 nécessite du code semblable à ce qui suit dans les versions précédentes de .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)

        Le code qui utilise les nouvelles API de chiffrement dans .NET Framework 4.6 peut être réécrit comme suit pour éviter le cast.

        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)

    • Prise en charge de la conversion des dates et heures vers ou à partir d’Unix

      Les nouvelles méthodes suivantes ont été ajoutées à la structure DateTimeOffset pour prendre en charge la conversion de valeurs de date et d’heure vers ou depuis l’heure Unix :

    • commutateurs de compatibilité

      La classe AppContext ajoute une nouvelle fonctionnalité de compatibilité qui permet aux auteurs de bibliothèques d'offrir à leurs utilisateurs un mécanisme uniforme pour se désengager des nouvelles fonctionnalités. Il établit un contrat faiblement couplé entre les composants afin de communiquer une demande d’opt-out. Cette fonctionnalité est généralement importante lorsqu’une modification est apportée aux fonctionnalités existantes. À l’inverse, il existe déjà un opt-in implicite pour de nouvelles fonctionnalités.

      Avec AppContext, les bibliothèques définissent et exposent des commutateurs de compatibilité, tandis que le code qui en dépend peut définir ces commutateurs pour affecter le comportement de la bibliothèque. Par défaut, les bibliothèques fournissent les nouvelles fonctionnalités et les modifient uniquement (autrement dit, elles fournissent la fonctionnalité précédente) si le commutateur est défini.

      Une application (ou une bibliothèque) peut déclarer la valeur d’un commutateur (qui est toujours une valeur Boolean) qu’une bibliothèque dépendante définit. Le commutateur a toujours implicitement la valeur false. Le réglage du commutateur sur true l'active. En réglant explicitement l'interrupteur sur false, vous obtenez le nouveau comportement.

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

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

      La bibliothèque doit vérifier si un consommateur a déclaré la valeur du commutateur, puis agir en conséquence.

      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

      Il est utile d’utiliser un format cohérent pour les commutateurs, car ils sont un contrat formel exposé par une bibliothèque. Voici deux formats évidents.

      • Commutateur.espace de noms.nom_commutateur

      • Commutateur.bibliothèque.nom_commutateur

    • modifications apportées au modèle asynchrone basé sur les tâches (TAP)

      Pour les applications qui ciblent .NET Framework 4.6, les objets Task et Task<TResult> héritent de la culture et de la culture d’interface utilisateur du thread appelant. Le comportement des applications qui ciblent les versions précédentes de .NET Framework, ou qui ne ciblent pas une version spécifique de .NET Framework, n’est pas affecté. Pour plus d’informations, consultez la section « Opérations asynchrones basées sur la culture et les tâches » de la rubrique de classe CultureInfo.

      La classe System.Threading.AsyncLocal<T> vous permet de représenter des données ambiantes locales à un flux de contrôle asynchrone donné, tel qu’une méthode async. Il peut être utilisé pour conserver des données entre les threads. Vous pouvez également définir une méthode de rappel qui est avertie chaque fois que les données ambiantes changent, car la propriété AsyncLocal<T>.Value a été explicitement modifiée, ou parce que le thread a rencontré une transition de contexte.

      Trois méthodes pratiques, Task.CompletedTask, Task.FromCanceledet Task.FromException, ont été ajoutées au modèle asynchrone basé sur les tâches (TAP) pour retourner les tâches terminées dans un état particulier.

      La classe NamedPipeClientStream prend désormais en charge la communication asynchrone avec sa nouvelle méthode ConnectAsync .

    • EventSource prend désormais en charge l’écriture dans le journal des événements

      Vous pouvez maintenant utiliser la classe EventSource pour consigner les messages administratifs ou opérationnels dans le journal des événements, en plus des sessions ETW existantes créées sur l’ordinateur. Dans le passé, vous deviez utiliser le package NuGet Microsoft.Diagnostics.Tracing.EventSource pour cette fonctionnalité. Cette fonctionnalité est désormais intégrée à .NET Framework 4.6.

      Le package NuGet et .NET Framework 4.6 ont été mis à jour avec les fonctionnalités suivantes :

      • événements dynamiques

        Autorise les événements définis « à la volée » sans créer de méthodes d’événement.

      • Charges utiles enrichies

        Permet aux classes et tableaux spécialement attribués ainsi qu’aux types primitifs d’être transmis en tant que charge utile

      • Suivi des activités

        Tous les événements entre les événements de début et de fin sont marqués avec un ID qui représente toutes les activités en cours.

      Pour prendre en charge ces fonctionnalités, la méthode Write surchargée a été ajoutée à la classe EventSource.

  • Windows Presentation Foundation (WPF)

    • Améliorations du HDPI

      La prise en charge de HDPI dans WPF est désormais meilleure dans .NET Framework 4.6. Des améliorations ont été apportées à l'arrondi de disposition pour réduire les instances de découpage dans les contrôles avec bordures. Par défaut, cette fonctionnalité est activée uniquement si votre TargetFrameworkAttribute est défini sur .NET Framework 4.6. Les applications qui ciblent des versions antérieures de l’infrastructure, mais qui s’exécutent sur .NET Framework 4.6, peuvent opter pour le nouveau comportement en ajoutant la ligne suivante à la section <runtime> du fichier app.config :

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

      Les fenêtres WPF qui s’étendent sur plusieurs moniteurs avec différents réglages DPI (configuration multi-DPI) sont maintenant entièrement affichées sans zones noires. Vous pouvez désactiver ce comportement en ajoutant la ligne suivante à la section <appSettings> du fichier app.config pour désactiver ce nouveau comportement :

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

      La prise en charge du chargement automatique du curseur approprié selon le paramètre DPI a été ajoutée à System.Windows.Input.Cursor.

    • Meilleure interaction tactile

      Les rapports clients sur Connect qui indiquent que le toucher produit un comportement imprévisible ont été traités dans le .NET Framework 4.6. Le seuil de double pression pour les applications du Windows Store et les applications WPF est désormais le même dans Windows 8.1 et versions ultérieures.

    • Prise en charge transparente des fenêtres enfants

      WPF dans .NET Framework 4.6 prend en charge les fenêtres enfants transparentes dans Windows 8.1 et versions ultérieures. Cela vous permet de créer des fenêtres enfants non rectangulaires et transparentes dans vos fenêtres de niveau supérieur. Vous pouvez activer cette fonctionnalité en définissant la propriété HwndSourceParameters.UsesPerPixelTransparency sur true.

  • Windows Communication Foundation (WCF)

    • Prise en charge de SSL

      WCF prend désormais en charge SSL version 1.1 et TLS 1.2, en plus de SSL 3.0 et TLS 1.0, lors de l’utilisation de NetTcp avec la sécurité de transport et l’authentification du client. Il est désormais possible de sélectionner le protocole à utiliser ou de désactiver les anciens protocoles moins sécurisés. Pour ce faire, définissez la propriété SslProtocols ou ajoutez ce qui suit à un fichier de configuration.

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

    • Envoyer des messages en utilisant différentes connexions HTTP

      WCF permet désormais aux utilisateurs de s’assurer que certains messages sont envoyés à l’aide de différentes connexions HTTP sous-jacentes. Il existe deux façons de procéder :

      • Utiliser un préfixe de nom de groupe de connexions

        Les utilisateurs peuvent spécifier une chaîne que WCF utilisera comme préfixe pour le nom du groupe de connexions. Deux messages avec des préfixes différents sont envoyés à l’aide de connexions HTTP sous-jacentes différentes. Vous définissez le préfixe en ajoutant une paire clé/valeur à la propriété Message.Properties du message. La clé est « HttpTransportConnectionGroupNamePrefix » ; la valeur est le préfixe souhaité.

      • Utilisation de différents générateurs de canaux

        Les utilisateurs peuvent également activer une fonctionnalité qui garantit que les messages envoyés à l’aide de canaux créés par différentes fabriques de canaux utilisent différentes connexions HTTP sous-jacentes. Pour activer cette fonctionnalité, les utilisateurs doivent définir les appSetting suivantes sur true:

        <appSettings>
    <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true" />
</appSettings>

  • Windows Workflow Foundation (WWF)

    Vous pouvez maintenant spécifier le nombre de secondes pendant lesquelles un service de workflow maintient une demande d'opération exceptionnelle quand il existe un signet « non-protocole » en attente avant l'expiration de la demande. Un signet « non-protocole » est un signet qui n'est pas lié à des activités de réception en attente. Certaines activités créent des signets non-protocole dans leur implémentation. Il est donc possible qu’il n’existe pas de signet non protocole. Il s'agit notamment de State et de Pick. Par conséquent, si vous avez un service de workflow mis en œuvre avec une machine à états ou contenant une activité de prélèvement, vous aurez probablement des signets non-protocole. Vous spécifiez l’intervalle en ajoutant une ligne comme suit à la section appSettings de votre fichier app.config :

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

    La valeur par défaut est de 60 secondes. Si value est défini sur 0, les requêtes hors ordre sont immédiatement rejetées par une erreur accompagnée d'un texte qui ressemble à ceci :

    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.

    C'est le même message que vous recevez en cas d'opération exceptionnelle et d'absence de signet non-protocole.

    Si la valeur de l’élément FilterResumeTimeoutInSeconds n’est pas zéro, il existe des signets non protocole et l’intervalle de délai d’expiration expire, l’opération échoue avec un message de délai d’expiration.

  • Transactions

    Vous pouvez maintenant inclure l’identificateur de transaction distribué pour la transaction qui a provoqué la levée d’une exception dérivée de TransactionException. Pour ce faire, ajoutez la clé suivante à la section appSettings de votre fichier app.config :

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

    La valeur par défaut est false.

  • Mise en réseau

    • Réutilisation du socket

      Windows 10 inclut un nouvel algorithme de mise en réseau haute scalabilité qui améliore l’utilisation des ressources de l’ordinateur en réutilisant les ports locaux pour les connexions TCP sortantes. .NET Framework 4.6 prend en charge le nouvel algorithme, ce qui permet aux applications .NET de tirer parti du nouveau comportement. Dans les versions précédentes de Windows, il y avait une limite de connexion simultanée artificielle (généralement 16 384, la taille par défaut de la plage de ports dynamiques), ce qui pouvait limiter l’extensibilité d’un service en provoquant l’épuisement des ports en cas de surcharge.

      Dans .NET Framework 4.6, deux API ont été ajoutées pour permettre la réutilisation des ports, ce qui supprime efficacement la limite de 64 Ko sur les connexions simultanées :

      Par défaut, la propriété ServicePointManager.ReusePort est false, sauf si la valeur HWRPortReuseOnSocketBind de la clé de Registre HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 est définie sur 0x1. Pour activer la réutilisation du port local sur les connexions HTTP, définissez la propriété ServicePointManager.ReusePort sur true. Ainsi, toutes les connexions de socket TCP sortantes de HttpClient et de HttpWebRequest utilisent une nouvelle option de socket Windows 10, SO_REUSE_UNICASTPORT, qui permet la réutilisation du port local.

      Les développeurs écrivant une application sockets uniquement peuvent spécifier l’option System.Net.Sockets.SocketOptionName lors de l’appel d’une méthode telle que Socket.SetSocketOption afin que les sockets sortants réutilisent les ports locaux pendant la liaison.

    • Support des noms de domaine internationaux et des PunyCode

      Une nouvelle propriété, IdnHost, a été ajoutée à la classe Uri pour mieux prendre en charge les noms de domaine internationaux et PunyCode.

  • Redimensionnement dans les contrôles Windows Forms.

    Cette fonctionnalité a été développée dans .NET Framework 4.6 pour inclure les types DomainUpDown, NumericUpDown, DataGridViewComboBoxColumn, DataGridViewColumn et ToolStripSplitButton et le rectangle spécifié par la propriété Bounds utilisée lors du dessin d’un UITypeEditor.

    Il s’agit d’une fonctionnalité d’adhésion. Pour l’activer, définissez l’élément EnableWindowsFormsHighDpiAutoResizing sur true dans le fichier de configuration de l’application (app.config) :

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

  • Prise en charge des codages de pages de codes

    .NET Core prend principalement en charge les encodages Unicode et, par défaut, fournit une prise en charge limitée des encodages de page de codes. Vous pouvez ajouter la prise en charge des encodages de page de codes disponibles dans .NET Framework, mais non pris en charge dans .NET Core en inscrivant des encodages de page de codes avec la méthode Encoding.RegisterProvider. Pour plus d’informations, consultez System.Text.CodePagesEncodingProvider.

  • .NET Native

Les applications de plateforme Windows universelle (UWP) écrites en C# ou Visual Basic peuvent tirer parti d’une nouvelle technologie qui compile les applications en code natif plutôt qu’en il. Cette technologie produit des applications qui ont des temps de démarrage et d’exécution plus rapides. Pour plus d’informations, consultez compilation d’applications avec .NET Native. Pour obtenir une vue d’ensemble de .NET Native qui examine la façon dont il diffère de la compilation JIT et du NGEN et de ce que cela signifie pour votre code, consultez .NET Native et Compilation.

Vos applications sont compilées en code natif par défaut lorsque vous les compilez avec Visual Studio 2015 ou version ultérieure. Pour plus d’informations, consultez Guide de démarrage avec .NET Native.

Pour prendre en charge le débogage d’applications .NET Native, plusieurs nouvelles interfaces et énumérations ont été ajoutées à l’API de débogage non managée. Pour plus d’informations, consultez la rubrique Débogage (Référence des API non managées).

  • Packages du .NET Framework open source

    Les packages .NET Core tels que les collections immuables, les API SIMD et les API réseau telles que celles trouvées dans l’espace de noms System.Net.Http sont désormais disponibles en tant que packages open source sur GitHub. Pour accéder au code, consultez .NET sur GitHub. Pour plus d’informations et comment contribuer à ces packages, consultez Présentation de .NET, page d’accueil .NET sur GitHub.

Nouveautés de .NET Framework 4.5.2

  • Nouvelles API pour les applications ASP.NET. Les nouvelles méthodes HttpResponse.AddOnSendingHeaders et HttpResponseBase.AddOnSendingHeaders vous permettent d’inspecter et de modifier les en-têtes de réponse et le code d’état lorsque la réponse est transmise à l’application cliente. Envisagez d’utiliser ces méthodes au lieu des événements PreSendRequestHeaders et PreSendRequestContent ; ils sont plus efficaces et plus fiables.

    La méthode HostingEnvironment.QueueBackgroundWorkItem vous permet de planifier de petits éléments de travail en arrière-plan. ASP.NET effectue le suivi de ces éléments et empêche IIS de mettre fin brusquement au processus de travail jusqu’à ce que tous les éléments de travail en arrière-plan soient terminés. Cette méthode ne peut pas être appelée en dehors d’un domaine d’application managée ASP.NET.

    Les nouvelles propriétés HttpResponse.HeadersWritten et HttpResponseBase.HeadersWritten retournent des valeurs booléennes qui indiquent si les en-têtes de réponse ont été écrits. Vous pouvez utiliser ces propriétés pour vous assurer que les appels aux API telles que HttpResponse.StatusCode (qui lèvent des exceptions si les en-têtes ont été écrits) réussissent.

  • Redimensionnement dans les contrôles Windows Forms. Cette fonctionnalité a été développée. Vous pouvez maintenant utiliser le paramètre PPP système pour redimensionner les composants des contrôles supplémentaires suivants (par exemple, la flèche déroulante vers le bas dans les zones de liste modifiable) :

    Il s’agit d’une fonctionnalité d’adhésion. Pour l’activer, définissez l’élément EnableWindowsFormsHighDpiAutoResizing sur true dans le fichier de configuration de l’application (app.config) :

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

  • Nouvelle fonctionnalité de flux de travail. Un gestionnaire de ressources qui utilise la méthode EnlistPromotableSinglePhase (et par conséquent l’implémentation de l’interface IPromotableSinglePhaseNotification) peut utiliser la nouvelle méthode Transaction.PromoteAndEnlistDurable pour demander ce qui suit :

    Cela peut être effectué dans le même domaine d’application et ne nécessite aucun code non managé supplémentaire pour interagir avec MSDTC pour effectuer la promotion. La nouvelle méthode peut uniquement être appelée quand il existe un appel en suspens de System.Transactions à la méthode IPromotableSinglePhaseNotificationPromote qui est implémentée par l’inscription pouvant être promue.

  • Améliorations du profilage. Les nouvelles API de profilage non managées suivantes fournissent un profilage plus robuste :

    Les implémentations précédentes d'ICorProfiler prenaient en charge le chargement tardif des assemblys dépendants. Les nouvelles API de profilage nécessitent que les assemblys dépendants qui sont injectés par le profileur soient chargeables immédiatement, au lieu d’être chargés une fois que l’application est entièrement initialisée. Cette modification n’affecte pas les utilisateurs des API ICorProfiler existantes.

  • Améliorations du débogage. Les nouvelles API de débogage non managées suivantes offrent une meilleure intégration à un profileur. Vous pouvez désormais accéder aux métadonnées insérées par le profileur, ainsi qu'aux variables locales et au code généré par les requêtes ReJIT du compilateur pendant le débogage de dump.

  • Modifications du suivi des événements. .NET Framework 4.5.2 permet le suivi d’activités basé sur ETW (Event Tracing for Windows) hors processus pour une plus grande étendue d'application. Cela permet aux fournisseurs de gestion avancée de l’énergie (APM) d'offrir des outils légers qui suivent avec précision les coûts des requêtes et des activités individuelles qui traversent les différents threads. Ces événements sont déclenchés uniquement lorsque les contrôleurs ETW les activent ; par conséquent, les modifications n’affectent pas le code ETW ou le code précédemment écrit qui s’exécute avec ETW désactivé.

  • Promouvoir une transaction et la convertir en inscription durable

    Transaction.PromoteAndEnlistDurable est une nouvelle API ajoutée à .NET Framework 4.5.2 et 4.6 :

    [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

    La méthode peut être utilisée par une inscription créée précédemment par Transaction.EnlistPromotableSinglePhase en réponse à la méthode ITransactionPromoter.Promote. Il demande à System.Transactions de promouvoir la transaction en une transaction MSDTC et de « convertir » l'enrôlement promouvable en enrôlement durable. Une fois cette méthode terminée, l’interface IPromotableSinglePhaseNotification ne sera plus référencée par System.Transactions, et toutes les notifications futures arriveront sur l’interface ISinglePhaseNotification fournie. L’inscription en question doit agir comme une inscription durable, prenant en charge la journalisation et la récupération des transactions. Pour plus d’informations, reportez-vous à Transaction.EnlistDurable. En outre, l'inscription doit prendre en charge ISinglePhaseNotification. Cette méthode peut être appelée seulement lors du traitement d’un appel ITransactionPromoter.Promote. Si tel n'est pas le cas, une exception TransactionException est levée.

Nouveautés de .NET Framework 4.5.1

avril 2014 met à jour:

  • Visual Studio 2013 Update 2 inclut des mises à jour des modèles de bibliothèque de classes portables pour prendre en charge ces scénarios :

    • Vous pouvez utiliser des API Windows Runtime dans des bibliothèques portables qui ciblent Windows 8.1, Windows Phone 8.1 et Windows Phone Silverlight 8.1.

    • Vous pouvez inclure du code XAML (types Windows.UI.XAML) dans des bibliothèques portables lorsque vous ciblez Windows 8.1 ou Windows Phone 8.1. Les modèles XAML suivants sont pris en charge : Page vide, Dictionnaire de ressources, Contrôle modèle et Contrôle utilisateur.

    • Vous pouvez créer un composant Windows Runtime portable (fichier .winmd) à utiliser dans les applications du Windows Store qui ciblent Windows 8.1 et Windows Phone 8.1.

    • Vous pouvez recibler une bibliothèque de classes du Windows Store ou du Windows Phone Store, par exemple une bibliothèque de classes portable.

    Pour plus d’informations sur ces modifications, consultez Bibliothèque de classes portable.

  • Le jeu de contenu .NET Framework inclut désormais la documentation de .NET Native, qui est une technologie de précompilation pour la création et le déploiement d’applications Windows. .NET Native compile vos applications directement en code natif, plutôt qu’en langage intermédiaire (IL), pour de meilleures performances. Pour plus d’informations, consultez compilation d’applications avec .NET Native.

  • La source de référence .NET Framework offre une nouvelle expérience de navigation et des fonctionnalités améliorées. Vous pouvez désormais parcourir le code source .NET Framework en ligne, télécharger la référence pour l’affichage hors connexion et parcourir les sources (y compris les correctifs et mises à jour) pendant le débogage. Pour plus d’informations, consultez l’article de blog Un nouveau look pour .NET Reference Source.

Les nouvelles fonctionnalités et améliorations apportées aux classes de base dans .NET Framework 4.5.1 sont les suivantes :

  • Redirection de liaison automatique des assemblys. À compter de Visual Studio 2013, lorsque vous compilez une application qui cible .NET Framework 4.5.1, les redirections de liaison peuvent être ajoutées au fichier de configuration d’application si votre application ou ses composants référencent plusieurs versions du même assembly. Vous pouvez également activer cette fonctionnalité pour les projets qui ciblent des versions antérieures de .NET Framework. Pour plus d’informations, consultez Guide pratique pour activer et désactiver la redirection de liaison automatique.

  • Possibilité de collecter des informations de diagnostic pour aider les développeurs à améliorer les performances des applications serveur et cloud. Pour plus d’informations, consultez les méthodes WriteEventWithRelatedActivityId et WriteEventWithRelatedActivityIdCore dans la classe EventSource.

  • Possibilité de compacter explicitement le tas d’objets volumineux (LOH) lors du ramassage des ordures. Pour plus d’informations, consultez la propriété GCSettings.LargeObjectHeapCompactionMode.

  • Améliorations supplémentaires des performances, telles que la suspension d'application ASP.NET, les améliorations JIT multicœurs, et un démarrage plus rapide de l'application après une mise à jour du .NET Framework. Pour plus d’informations, consultez l’article Annonce de .NET Framework 4.5.1 et le billet de blog ASP.NET app suspend.

Les améliorations apportées à Windows Forms sont les suivantes :

  • Redimensionnement des contrôles Windows Forms. Vous pouvez utiliser le paramètre PPP système pour redimensionner les composants des contrôles (par exemple, les icônes qui apparaissent dans une grille des propriétés) en choisissant de l'utiliser pour votre application grâce à une entrée dans le fichier de configuration de l'application (app.config). Cette fonctionnalité est actuellement prise en charge dans les contrôles Windows Forms suivants :

    Pour activer cette fonctionnalité, ajoutez un nouvel élément appSettings <> au fichier de configuration (app.config) et définissez l’élément EnableWindowsFormsHighDpiAutoResizing sur true:

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

Les améliorations apportées lors du débogage de vos applications .NET Framework dans Visual Studio 2013 sont les suivantes :

  • Valeurs de retour dans le débogueur Visual Studio. Lorsque vous déboguez une application managée dans Visual Studio 2013, la fenêtre Autos affiche les types de retour et les valeurs des méthodes. Ces informations sont disponibles pour les applications bureau, Windows Store et Windows Phone. Pour plus d’informations, consultez Examiner les valeurs de retour des appels de méthode.

  • Modifier et continuer pour les applications 64 bits. Visual Studio 2013 prend en charge la fonctionnalité Modifier et continuer pour les applications gérées 64 bits pour les applications de bureau, windows Store et Windows Phone. Les limitations existantes restent effectives pour les applications 32 bits et 64 bits (consultez la dernière section de l’article Modifications de code prises en charge (C#)).

  • Débogage asynchrone. Pour faciliter le débogage d’applications asynchrones dans Visual Studio 2013, la pile des appels masque le code d’infrastructure fourni par les compilateurs pour prendre en charge la programmation asynchrone, et enchaîne également des cadres parents logiques pour permettre de suivre plus clairement l'exécution logique du programme. Une fenêtre Tâches remplace la fenêtre Tâches parallèles et affiche les tâches liées à un point d’arrêt particulier, et affiche également toutes les autres tâches actuellement actives ou planifiées dans l’application. Vous pouvez en savoir plus sur cette fonctionnalité dans la section « Débogage asynchrone » de l’annonce .NET Framework 4.5.1.

  • Meilleure prise en charge des exceptions pour les composants Windows Runtime. Dans Windows 8.1, les exceptions qui proviennent des applications du Windows Store conservent des informations sur l’erreur qui a provoqué l’exception, même au-delà des limites linguistiques. Vous pouvez en savoir plus sur cette fonctionnalité dans la section « Développement d’applications du Windows Store » de l’annonce .NET Framework 4.5.1.

À compter de Visual Studio 2013, vous pouvez utiliser l’outil d’optimisation guidée des profils managés (Mpgo.exe) pour optimiser les applications du Windows 8.x Store ainsi que les applications de bureau.

Pour connaître les nouvelles fonctionnalités de ASP.NET 4.5.1, consultez ASP.NET et Web Tools pour Visual Studio 2013 Release Notes.

Nouveautés de .NET Framework 4.5

Classes de base

  • Possibilité de réduire les redémarrages du système en détectant et en fermant des applications .NET Framework 4 pendant le déploiement. Voir la section concernant la réduction des redémarrages du système pendant les installations de .NET Framework 4.5.

  • Prise en charge des tableaux dont la taille est supérieure à 2 gigaoctets (Go) sur les plateformes 64 bits. Cette fonctionnalité peut être activée dans le fichier de configuration de l’application. Consultez le <gcAllowVeryLargeObjects> élément, qui répertorie également d’autres restrictions sur la taille de l’objet et la taille du tableau.

  • Amélioration des performances par la collecte des déchets en arrière-plan pour les serveurs. Lorsque vous utilisez le ramasse-miettes de serveur dans le .NET Framework 4.5, le ramasse-miettes d'arrière-plan est automatiquement activé. Consultez la section Garbage collection de serveur en arrière-plan, dans la rubrique Notions de base du garbage collection.

  • Compilation juste-à-temps (JIT) en arrière-plan, disponible en option sur les processeurs multicœurs pour améliorer les performances de l'application. Voir ProfileOptimization.

  • Possibilité de limiter la durée pendant laquelle le moteur d’expression régulière tentera de résoudre une expression régulière avant d’expirer. Consultez la propriété Regex.MatchTimeout.

  • Possibilité de définir la culture par défaut d’un domaine d’application. Consultez la classe CultureInfo.

  • Prise en charge de la console pour l'encodage Unicode (UTF-16). Consultez la classe Console.

  • Prise en charge du versioning des données de classement et de comparaison des chaînes culturelles. Consultez la classe SortVersion.

  • Meilleures performances lors de la récupération des ressources. Consultez le package et déployez les ressources.

  • Améliorations apportées à la compression zip pour réduire la taille d’un fichier compressé. Consultez l’espace de noms System.IO.Compression.

  • Possibilité de personnaliser un contexte de réflexion pour remplacer le comportement de réflexion par défaut par le biais de la classe CustomReflectionContext.

  • Prise en charge de la version 2008 de la norme IDNA (Internationalized Domain Names in Applications) lorsque la classe System.Globalization.IdnMapping est utilisée sur Windows 8.

  • Délégation de la comparaison de chaînes au système d’exploitation, qui implémente Unicode 6.0, lorsque le .NET Framework est utilisé sur Windows 8. Lors de l’exécution sur d’autres plateformes, .NET Framework inclut ses propres données de comparaison de chaînes, qui implémentent Unicode 5.x. Consultez la classe String et la section Notes de la classe SortVersion.

  • Possibilité de calculer les codes de hachage pour les chaînes par domaine d’application. Voir <UseRandomizedStringHashAlgorithm,> élément.

  • Prise en charge de la réflexion de type fractionnée entre les classes Type et TypeInfo. Consultez Réflexion dans le .NET Framework pour les applications du Windows Store.

Framework d’extensibilité managée (MEF)

Dans .NET Framework 4.5, le Framework d’extensibilité managé (MEF) fournit les nouvelles fonctionnalités suivantes :

  • Prise en charge des types génériques.

  • Modèle de programmation basé sur des conventions qui vous permet de créer des parties basées sur des conventions d’affectation de noms plutôt que sur des attributs.

  • Portées multiples.

  • Sous-ensemble de MEF que vous pouvez utiliser lorsque vous créez des applications Windows 8.x Store. Ce sous-ensemble est disponible en tant que package téléchargeable à partir de la galerie NuGet. Pour installer le package, ouvrez votre projet dans Visual Studio, choisissez Gérer les packages NuGet dans le menu Project, puis recherchez en ligne le package Microsoft.Composition.

Pour plus d’informations, consultez Managed Extensibility Framework (MEF).

Opérations de fichier asynchrones

Dans .NET Framework 4.5, de nouvelles fonctionnalités asynchrones ont été ajoutées aux langages C# et Visual Basic. Ces fonctionnalités ajoutent un modèle basé sur des tâches pour effectuer des opérations asynchrones. Pour utiliser ce nouveau modèle, utilisez les méthodes asynchrones dans les classes d’E/S. Consultez E/S de fichier asynchrone.

Outils

Dans .NET Framework 4.5, le générateur de fichiers de ressources (Resgen.exe) vous permet de créer un fichier .resw à utiliser dans les applications du Windows 8.x Store à partir d’un fichier .resources incorporé dans un assembly .NET Framework. Pour plus d’informations, consultez Resgen.exe (Générateur de fichiers de ressources).

L'Optimisation guidée par profil managé (Mpgo.exe) vous permet d'améliorer le temps de lancement de l'application, l'utilisation de la mémoire (taille du jeu de travail) et le débit en optimisant les assemblages d'images natifs. L'outil en ligne de commande génère des données de profil pour les assemblies d'applications d'images natives. Consultez Mpgo.exe (Outil d’optimisation guidée du profil managé). À compter de Visual Studio 2013, vous pouvez utiliser Mpgo.exe pour optimiser les applications du Windows 8.x Store ainsi que les applications de bureau.

Calcul parallèle

.NET Framework 4.5 fournit plusieurs nouvelles fonctionnalités et améliorations pour l’informatique parallèle. Il s’agit notamment d’une amélioration des performances, d’un contrôle accru, d’une prise en charge améliorée de la programmation asynchrone, d’une nouvelle bibliothèque de flux de données et d’une prise en charge améliorée du débogage parallèle et de l’analyse des performances. Consultez l’entrée Nouveautés du parallélisme dans .NET Framework 4.5 dans le blog De programmation parallèle avec .NET.

Web

ASP.NET 4.5 et 4.5.1 ajoutent une liaison de modèles pour Web Forms, la prise en charge de WebSocket, des gestionnaires asynchrones, des améliorations de performances et de nombreuses autres fonctionnalités. Pour plus d’informations, consultez les ressources suivantes :

Réseaux

.NET Framework 4.5 fournit une nouvelle interface de programmation pour les applications HTTP. Pour plus d’informations, consultez les nouveaux espaces de noms System.Net.Http et System.Net.Http.Headers.

La prise en charge est également incluse pour une nouvelle interface de programmation pour accepter et interagir avec une connexion WebSocket à l’aide des classes existantes HttpListener et associées. Pour plus d’informations, consultez le nouvel espace de noms System.Net.WebSockets et la classe HttpListener.

De plus, .NET Framework 4.5 inclut les améliorations réseau suivantes :

  • Prise en charge des URI conformes aux normes RFC. Pour plus d’informations, consultez Uri et les classes associées.

  • Prise en charge de l’analyse des noms de domaine internationalisés (IDN). Pour plus d’informations, consultez Uri et les classes associées.

  • Prise en charge de l'internationalisation des adresses de messagerie. Pour plus d’informations, consultez l’espace de noms System.Net.Mail.

  • Prise en charge améliorée de IPv6. Pour plus d’informations, consultez l’espace de noms System.Net.NetworkInformation.

  • Prise en charge du socket en mode double. Pour plus d’informations, consultez les classes Socket et TcpListener.

Windows Presentation Foundation (WPF)

Dans .NET Framework 4.5, Windows Presentation Foundation (WPF) contient des modifications et des améliorations dans les domaines suivants :

  • Le nouveau contrôle Ribbon vous permet d’implémenter une interface utilisateur du ruban contenant une barre d’outils d’accès rapide, un menu d'application et des onglets.

  • Nouvelle interface INotifyDataErrorInfo, qui prend en charge la validation synchrone et asynchrone des données.

  • Nouvelles fonctionnalités pour les classes VirtualizingPanel et Dispatcher.

  • Amélioration des performances lors de l’affichage de grands ensembles de données groupées et en accédant à des regroupements sur des threads autres que l’interface utilisateur.

  • Liaison de données à des propriétés statiques, liaison de données à des types personnalisés qui implémentent l’interface ICustomTypeProvider et récupération d’informations de liaison de données à partir d’une expression de liaison.

  • Repositionnement des données à mesure que les valeurs changent (mise en forme dynamique).

  • Possibilité de vérifier si le contexte de données d’un conteneur d’éléments est déconnecté.

  • Possibilité de définir la durée qui doit s’écouler entre les modifications de propriété et les mises à jour de la source de données.

  • Prise en charge améliorée de l’implémentation de modèles d’événements faibles. En outre, les événements peuvent désormais accepter les extensions de balisage.

Windows Communication Foundation (WCF)

Dans .NET Framework 4.5, les fonctionnalités suivantes ont été ajoutées pour simplifier l’écriture et la gestion des applications Windows Communication Foundation (WCF) :

  • Simplification des fichiers de configuration générés.

  • Prise en charge du développement axé sur le contrat.

  • Possibilité de configurer ASP.NET mode de compatibilité plus facilement.

  • Modifications apportées aux valeurs de propriété de transport par défaut pour réduire la probabilité que vous devrez les définir.

  • Mises à jour de la classe XmlDictionaryReaderQuotas pour réduire la probabilité que vous deviez configurer manuellement des quotas pour les lecteurs de dictionnaire XML.

  • Validation des fichiers de configuration WCF par Visual Studio dans le cadre du processus de génération. Vous pouvez donc détecter les erreurs de configuration avant d’exécuter votre application.

  • Nouvelle prise en charge de la diffusion en continu asynchrone.

  • Nouveau mappage de protocole HTTPS pour faciliter l’exposition d’un point de terminaison via HTTPS avec Internet Information Services (IIS).

  • Possibilité de générer des métadonnées dans un seul document WSDL en ajoutant ?singleWSDL à l’URL du service.

  • Les websockets prennent en charge l’activation de la communication bidirectionnelle réelle sur les ports 80 et 443 avec des caractéristiques de performances similaires au transport TCP.

  • Prise en charge de la configuration des services dans le code.

  • Info-bulles de l'éditeur XML.

  • Prise en charge de la mise en cache de ChannelFactory.

  • Prise en charge de la compression d'encodage binaire.

  • Prise en charge d’un transport UDP qui permet aux développeurs d’écrire des services qui utilisent la messagerie « fire and forget ». Un client envoie un message à un service et attend aucune réponse du service.

  • Possibilité de prendre en charge plusieurs modes d’authentification sur un seul point de terminaison WCF lors de l’utilisation du transport HTTP et de la sécurité de transport.

  • Prise en charge des services WCF qui utilisent des noms de domaine internationalisés (IDN).

Pour plus d’informations, consultez Quoi de neuf dans Windows Communication Foundation.

Windows Workflow Foundation (WF)

Dans .NET Framework 4.5, plusieurs nouvelles fonctionnalités ont été ajoutées à Windows Workflow Foundation (WF), notamment :

  • Flux de travail d’ordinateur d’état, qui ont été introduits pour la première fois dans le cadre de .NET Framework 4.0.1 (.NET Framework 4 Platform Update 1). Cette mise à jour inclut plusieurs nouvelles classes et activités qui ont permis aux développeurs de créer des flux de travail d’ordinateur d’état. Ces classes et activités ont été mises à jour pour .NET Framework 4.5 afin d’inclure :

    • Possibilité de définir des points d’arrêt sur des états.

    • Possibilité de copier et coller des transitions dans le concepteur de flux de travail.

    • Prise en charge du concepteur pour la création de transitions de déclencheur partagées.

    • Activités de création de flux de travail de machine à états, notamment : StateMachine, State et Transition.

  • Fonctionnalités améliorées du Concepteur de flux de travail, telles que les suivantes :

    • Fonctionnalités de recherche de flux de travail améliorées dans Visual Studio, notamment recherche rapide et Rechercher dans les fichiers.

    • Possibilité de créer automatiquement une activité Sequence lorsqu’une deuxième activité enfant est ajoutée à une activité de conteneur et d’inclure les deux activités dans l’activité Séquence.

    • Support du défilement panoramique, qui permet de modifier la partie visible d’un flux de travail sans utiliser les barres de défilement.

    • Une nouvelle vue du plan de document qui affiche les composants d’un flux de travail en mode arborescence et vous permet de sélectionner un composant dans la vue du plan de document .

    • Possibilité d’ajouter des annotations aux activités.

    • Possibilité de définir et d'utiliser des délégués d'activité à l'aide du Concepteur de flux de travail.

    • Connexion automatique et insertion automatique des activités et des transitions dans les flux de travail de machine à états et d'organigramme.

  • Stockage des informations d’état d’affichage d’un flux de travail dans un seul élément du fichier XAML. Vous pouvez donc facilement localiser et modifier les informations d’état d’affichage.

  • Activité de conteneur NoPersistScope pour empêcher les activités enfants de devenir persistantes.

  • Prise en charge des expressions C# :

    • Les projets de flux de travail qui utilisent Visual Basic utilisent des expressions Visual Basic et les projets de flux de travail C# utilisent des expressions C#.

    • Les projets de flux de travail C# créés dans Visual Studio 2010 et qui ont des expressions Visual Basic sont compatibles avec les projets de flux de travail C# qui utilisent des expressions C#.

  • Améliorations du contrôle de version :

    • La nouvelle classe WorkflowIdentity, qui fournit un mappage entre une instance de flux de travail persistante et sa définition de flux de travail.

    • Exécution côte à côte de plusieurs versions de flux de travail dans le même hôte, y compris WorkflowServiceHost.

    • Dans La mise à jour dynamique, la possibilité de modifier la définition d’une instance de workflow persistante.

  • Développement de services de workflow « Contrat en premier », ce qui permet de générer automatiquement les activités correspondants à un contrat de service existant.

Pour plus d’informations, consultez Nouveautés de Windows Workflow Foundation.

.NET pour les applications du Windows 8.x Store

Les applications du Windows 8.x Store sont conçues pour des facteurs de forme spécifiques et tirent parti de la puissance du système d’exploitation Windows. Un sous-ensemble de .NET Framework 4.5 ou 4.5.1 est disponible pour créer des applications windows 8.x Store pour Windows à l’aide de C# ou Visual Basic. Ce sous-ensemble est appelé .NET pour les applications du Windows 8.x Store et est abordé dans une vue d’ensemble .

Bibliothèques de classes portables

Le projet bibliothèque de classes portable dans Visual Studio 2012 (et versions ultérieures) vous permet d’écrire et de générer des assemblys managés qui fonctionnent sur plusieurs plateformes .NET Framework. À l’aide d’un projet bibliothèque de classes portable, vous choisissez les plateformes (par exemple, Windows Phone et .NET pour les applications du Windows 8.x Store) à cibler. Les types et membres disponibles dans votre projet sont automatiquement limités aux types et membres communs sur ces plateformes. Pour plus d’informations, consultez Bibliothèque de classes portable.

Voir aussi