Nouveautés de .NET Framework

  • Article

Notes

.NET Framework 4.8 est la dernière version du .NET Framework. .NET Framework fait l’objet d’une maintenance mensuelle avec des correctifs des bogues de sécurité et de fiabilité. .NET Framework continuera d’être fourni avec Windows, et il n’est pas prévu de l’en supprimer. Vous n’avez pas besoin de migrer vos applications .NET Framework, mais pour un nouveau développement, utilisez .NET 5 ou une version ultérieure.

Cet article résume les principales nouvelles fonctionnalités et améliorations des versions suivantes de .NET Framework :

Cet article ne fournit pas d'informations complètes sur chacune des nouvelles fonctionnalités et peut faire l'objet de modifications. Pour obtenir des informations générales sur .NET Framework, consultez Prise en main. Pour connaître les plateformes prises en charge, consultez Configuration requise. Pour obtenir des liens de téléchargement et des instructions d’installation, consultez Guide d’installation.

Notes

L’équipe .NET Framework publie aussi des fonctionnalités hors plage, utilisant NuGet, pour étendre la prise en charge des plateformes et introduire des nouveauté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

.NET Framework 4.8 repose sur les versions précédentes de .NET Framework 4.x, auxquelles il ajoute un grand nombre de 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 de 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. Le programme d’installation web constitue la méthode recommandée pour la plupart des utilisateurs.

Vous pouvez cibler .NET Framework 4.8 dans Visual Studio 2012 ou ultérieur en installant .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 :

L’amélioration de l’accessibilité, pour qu’une application puisse fournir une expérience appropriée aux utilisateurs de technologies d’assistance, reste un objectif majeur de .NET Framework 4.8. Pour plus d’informations sur les améliorations apportées à .NET Framework 4.8 dans le domaine de l’accessibilité, consultez Nouveautés de .NET Framework dans le domaine de l’accessibilité.

Classes de base

Impact FIPS réduit sur le chiffrement. Dans les versions précédentes de .NET Framework, des classes de fournisseur de services de chiffrement managées telles que SHA256Managed levaient une exception CryptographicException lorsque les bibliothèques de chiffrement du système étaient configurées en « mode FIPS ». Ces exceptions étaient levées car les versions managées des classes de fournisseur de services de chiffrement, contrairement aux bibliothèques de chiffrement du système, ne disposaient pas de la certification de normes FIPS (Federal Information Processing Standard) 140-2. Peu de développeurs disposant de machines de développement en mode FIPS, les exceptions étaient généralement levées dans des systèmes de production.

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

Ces classes redirigent plutôt les opérations de chiffrement vers une bibliothèque de chiffrement du système. Cette modification supprime efficacement une différence pouvant potentiellement prêter à confusion entre les environnements de développement et les environnements de production, et permet d’exécuter les composants natifs et les composants managés 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 d’une version mise à jour de ZLib

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

Windows Communication Foundation (WCF)

Présentation de ServiceHealthBehavior

Les points de terminaison d’intégrité sont couramment utilisés par les outils d’orchestration pour gérer les services en fonction de leur état d’intégrité. Des vérifications de l’intégrité peuvent également être utilisées par les outils d’analyse 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 l’état d’intégrité 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. Des informations spécifiques du service, y compris l’état du service, le nombre de limitations et la capacité, peuvent être affichées à l’aide d’une requête HTTP/GET avec la chaîne de requête ?health. Il est important de pouvoir accéder facilement à ces informations lors de la résolution des problèmes liés à un service WCF se comportant anormalement.

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. 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 de l’un des répartiteurs 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, un code de réponse 350 est retourné.

    • Sinon, un code de réponse 200 est retourné.

L’état d’intégrité du service peut être affiché au format HTML en spécifiant une chaîne de requête telle que https://contoso:81/Service1?health ou au format XML en spécifiant une chaîne de requête telle que 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 High DPI Desktop Application Development on Windows (Développement d’applications de bureau haute résolution sur Windows) pour plus d’informations sur le développement de la haute résolution.

.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 type de contenu hébergé n’est pas restitué à la résolution native ; 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 de .NET Framework 4.8 comprend les nouvelles modifications et améliorations suivantes :

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

Améliorations apportées à 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 aux 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. Les assemblys chargés à partir d’autres sources, via la méthode Assembly.Load(Byte[]) par exemple, ne sont toutefois pas analysés et sont susceptibles de contenir des programmes malveillants non détectés. À compter de .NET Framework 4.8 exécuté sur Windows 10, le runtime déclenche une analyse via des 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 apporte de nouvelles fonctionnalités dans les domaines suivants :

.NET Framework 4.7.2 met l’accent sur l’amélioration de l’accessibilité pour qu’une application puisse fournir une expérience appropriée aux utilisateurs de technologies d’assistance. Pour plus d’informations sur les améliorations apportées à .NET Framework 4.7.2 dans le domaine de l’accessibilité, consultez Nouveautés de .NET Framework dans le domaine de l’accessibilité.

Classes de base

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

Nouvelles surcharges de RSA.Create et DSA.Create

Les méthodes DSA.Create(DSAParameters) et RSA.Create(RSAParameters) permettent d’indiquer des paramètres de clés en cas d’instanciation d’une nouvelle clé DSA ou RSA. Elles vous permettent de remplacer du code tel que le suivant :

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

par du code comme celui-ci :

// 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 de clés. Au lieu d’utiliser SHA-1, les développeurs doivent utiliser un algorithme HMAC basé sur SHA-2, tel que SHA-256, comme indiqué 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 ignorant le disque dur. Quand 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 sont chargées en tant que clés éphémères. Cela empêche que les clés soient 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 pour être ajoutés à un X509Store.

  • Les clés chargées de cette manière le sont presque toujours par Windows CNG. Ainsi, 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.

  • Puisque 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 aux clés éphémères.

Création par programmation de demandes de signature de certification PKCS#10 et de 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, ce qui permet de générer une demande de certificat dans des outils existants. C’est souvent utile dans les scénarios de test.

Pour plus d’informations et des exemples de code, consultez « Programmatic creation of PKCS#10 certification signing requests and X.509 public key certificates » sur le Blog .NET.

Nouveaux membres SignerInfo

À compter de .NET Framework 4.7.2, la classe SignerInfo expose davantage 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 afin d’obtenir une copie de la signature de chiffrement pour ce signataire.

Laisser un flux encapsulé ouvert après la suppression de CryptoStream

À compter de .NET Framework 4.7.2, la classe CryptoStream a un constructeur supplémentaire qui permet à Dispose de ne pas fermer le flux wrappé. Pour laisser le flux wrappé ouvert après la suppression de l’instance CryptoStream, 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 de la classe DeflateStream a été changée de façon à utiliser des API Windows natives par défaut. En règle générale, s’ensuit une amélioration sensible 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 du .NET Framework mais qui s’exécutent sur .NET Framework 4.7.2 peuvent adopter ce comportement en ajoutant le commutateur AppContext suivant au fichier de configuration d’application :

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

API de collection supplémentaires

.NET Framework 4.7.2 ajoute de nouvelles API aux types SortedSet<T> et HashSet<T>. Il s’agit notamment des paramètres suivants :

La classe ConcurrentDictionary<TKey,TValue> comprend de nouvelles surcharges des méthodes AddOrUpdate et GetOrAdd pour récupérer une valeur à partir du dictionnaire ou l’ajouter si elle est introuvable, et pour ajouter une valeur au dictionnaire ou la mettre à jour si elle 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 Web Forms

L’injection de dépendances dissocie les objets et leurs dépendances afin qu’il ne soit plus obligatoire de modifier le code d’un objet simplement parce qu’une dépendance a changé. Lors du développement d’applications ASP.NET qui ciblent .NET Framework 4.7.2, vous pouvez :

Prise en charge des cookies du même site

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 prise en charge de 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 des cookies FormsAuthentication et System.Web.SessionState en modifiant le fichier de configuration web :

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

Mise en réseau

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 et de l’authentification multifacteur Azure Active Directory

Face aux exigences croissantes de conformité et de sécurité, de nombreux clients se voient obligés d’utiliser l’authentification multifacteur (MFA). De plus, les bonnes pratiques en vigueur n’encouragent pas la saisie 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. Quand 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. De plus, le processus d’authentification demande un mot de passe utilisateur afin de respecter les bonnes pratiques de sécurité.

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

Pour plus d’informations et pour obtenir un exemple, consultez « SQL -- Azure AD Universal and Multi-factor Authentication Support » sur le Blog .NET.

Prise en charge d’Always Encrypted version 2

.NET Framework 4.7.2 ajoute la prise en charge d’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. Avec Always Encrypted basé sur enclave, le client peut s’il le souhaite envoyer les clés de chiffrement à une enclave sécurisée, qui est une entité de calcul sécurisée pouvant ê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 enclave, .NET Framework 4.7.2 ajoute les types et membres suivants à l’espace de noms System.Data.SqlClient :

Le fichier de configuration d’application spécifie ensuite une implémentation concrète de la classe System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider abstraite qui fournit la fonctionnalité pour le fournisseur d’enclave. 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 enclave 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éés à partir d’un URI source donné (cette fonctionnalité est destinée aux Assistants de diagnostic, non aux applications de production). Un Assistant de diagnostic, tel que la fonctionnalité « Modifier et continuer » de Visual Studio, permet à l’utilisateur de modifier un ResourceDictionary avec l’intention d’appliquer les modifications à l’application en cours d’exécution. Dans ce but, l’une des étapes consiste à trouver tous les ResourceDictionaries créés par l’application en cours d’exécution à 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 trouver le dictionnaire. La fonctionnalité est implémentée par une nouvelle méthode statique, ResourceDictionaryDiagnostics.GetResourceDictionariesForSource. L’Assistant de 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 un énumérable vide, sauf si VisualDiagnostics est activé et que la variable d’environnement ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO est définie.

Recherche de propriétaires de ResourceDictionary

À compter de .NET Framework 4.7.2, un Assistant de diagnostic peut localiser les propriétaires d’un ResourceDictionary donné. (Cette fonctionnalité est destinée aux Assistants de diagnostic, non aux applications de production.) Chaque fois qu’un ResourceDictionary est modifié, WPF détecte automatiquement toutes les références DynamicResource susceptibles d’être affectées par la modification.

Un Assistant de diagnostic, tel que la fonctionnalité « Modifier et continuer » de Visual Studio, peut souhaiter étendre cette fonctionnalité afin de gérer les références StaticResource. La première étape de ce processus consiste à rechercher les propriétaires du dictionnaire, autrement dit à rechercher tous les objets dont la propriété Resources fait référence au dictionnaire (directement ou indirectement par le biais de 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 un é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 maintenant recevoir une notification chaque fois qu’une référence StaticResource est résolue. (Cette fonctionnalité est destinée aux Assistants de diagnostic, non aux applications de production.) Un Assistant de diagnostic, tel que la fonctionnalité « Modifier et continuer » de Visual Studio, peut souhaiter mettre à jour toutes les utilisations d’une ressource quand sa valeur dans un ResourceDictionary change. WPF le fait automatiquement pour les références DynamicResource, mais il ne le fait pas (intentionnellement) pour les références StaticResource. À compter de .NET Framework 4.7.2, l’Assistant de 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 ainsi que la clé ResourceDictionary utilisée 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 avec prise en charge HDPI pour Windows Forms, WPF (Windows Presentation Foundation) et VSTO (Visual Studio Tools pour Office) peuvent toutes être déployées à l’aide de ClickOnce. Si l’entrée suivante est détectée dans le manifeste d’application, le déploiement réussit dans .NET Framework 4.7.2 :

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

Pour une application Windows Forms, la solution de contournement précédente consistant à définir la prise en charge DPI dans le fichier de configuration d’application plutôt que dans le manifeste d’application n’est plus nécessaire à la réussite du déploiement ClickOnce.

Nouveautés du .NET Framework 4.7.1

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

.NET Framework 4.7.1 met également l’accent sur l’amélioration de l’accessibilité pour qu’une application puisse fournir une expérience appropriée aux utilisateurs de technologies d’assistance. Pour plus d’informations sur les améliorations apportées à .NET Framework 4.7.1 dans le domaine de l’accessibilité, consultez Nouveautés de .NET Framework dans le domaine de l’accessibilité.

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 prenant en charge cette version de la norme. .NET Framework 4.7.1 prend entièrement en charge .NET Standard 2.0 et ajoute 200 API environ qui sont définies dans .NET Standard 2.0 et qui ne figurent pas 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 support .NET Standard supplémentaires sont également déployés sur le système cible.) Pour plus d’informations, consultez « BCL - .NET Standard 2.0 Support » dans le billet de blog .NET Framework 4.7.1 Runtime and Compiler Features.

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 dynamiquement des paramètres de configuration pour les applications au moment de l’exécution. Des générateurs de configuration personnalisés peuvent être utilisés pour modifier des données existantes dans une section de configuration ou générer une section de configuration entièrement nouvelle. Sans les générateurs de configuration, les fichiers .config sont statiques, et leurs paramètres sont définis avant le lancement d’une application.

Pour créer un générateur de configuration personnalisé, dérivez votre générateur de la classe abstraite ConfigurationBuilder et substituez ConfigurationBuilder.ProcessConfigurationSection et ConfigurationBuilder.ProcessRawXml. Vous pouvez également définir vos générateurs dans votre fichier .config. Pour plus d’informations, consultez la section « Configuration Builders » dans le billet de blog .NET Framework 4.7.1 ASP.NET and Configuration Features.

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

La classe System.Runtime.CompilerServices.RuntimeFeature fournit un mécanisme pour 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 l’existence d’un champ spécifié pour déterminer si la fonctionnalité est prise en charge. Dans l’affirmative, il peut émettre du code qui exploite cette fonctionnalité. Au moment de l’exécution, une application peut appeler la méthode RuntimeFeature.IsSupported avant d’émettre du code. Pour plus d’informations, consultez Ajouter une méthode d’assistance 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érialisables, ce qui permet une 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 et variables locales ref (Guide C#) et Valeurs de retour de référence (Visual Basic).

Common Language Runtime (CLR)

Amélioration des performances du garbage collection

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 -- GC Performance Improvements » dans le billet de blog .NET Framework 4.7.1 Runtime and Compiler Features.

Mise en réseau

Prise en charge de SHA-2 pour Message.HashAlgorithm

Dans .NET Framework 4.7 et versions antérieures, la propriété Message.HashAlgorithm prenait uniquement en charge les valeurs HashAlgorithm.Md5 et HashAlgorithm.Sha. À compter de .NET Framework 4.7.1, les valeurs HashAlgorithm.Sha256, HashAlgorithm.Sha384 et HashAlgorithm.Sha512 sont également prises en charge. MSMQ détermine si cette valeur est utilisée ou non, puisque l’instance de Message n’effectue elle-même aucun hachage et passe simplement les 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 les applications ASP.NET

ASP.NET traite les demandes dans un pipeline prédéfini comprenant 23 événements. ASP.NET exécute chaque gestionnaire d’événements sous forme d’étape d’exécution. Dans les versions d’ASP.NET jusqu’à .NET Framework 4.7, ASP.NET ne peut pas passer le contexte d’exécution en raison de la commutation entre threads natifs et threads managés. Au lieu de cela, ASP.NET passe uniquement HttpContext de manière sélective. À 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 préoccupées par le traçage, le profilage, les diagnostics ou les transactions qui, par exemple, tiennent compte du 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 comprend une nouvelle méthode, HttpCookie.TryParse, qui offre un moyen normalisé de créer un objet HttpCookie à partir d’une chaîne et d’affecter avec précision des valeurs de cookie telles que la date d’expiration et le chemin. Pour plus d’informations, consultez « ASP.NET HttpCookie parsing » dans le billet de blog .NET Framework 4.7.1 ASP.NET and Configuration Features.

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 permettait aux développeurs de stocker les informations d’identification des utilisateurs avec des mots de passe hachés dans des fichiers de configuration en utilisant MD5 ou SHA-1. À compter de .NET Framework 4.7.1, ASP.NET prend en charge de nouvelles options de hachage SHA-2 sécurisées, notamment SHA256, SHA384 et SHA512. SHA1 reste la valeur par défaut, et un algorithme de hachage autre que celui par défaut peut être défini dans le fichier de configuration web. Par exemple :

<system.web>
    <authentication mode="Forms">
        <forms loginUrl="~/login.aspx">
          <credentials passwordFormat="SHA512">
            <user name="jdoe" password="6D003E98EA1C7F04ABF8FCB375388907B7F3EE06F278DB966BE960E7CBBD103DF30CA6D61F7E7FD981B2E4E3A64D43C836A4BEDCA165C33B163E6BCDC538A664" />
          </credentials>
        </forms>
    </authentication>
</system.web>

Nouveautés de .NET Framework 4.7

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

Pour obtenir la liste des nouvelles API ajoutées à .NET Framework 4.7, consultez la page Changements au niveau des API de .NET Framework 4.7 sur GitHub. Pour obtenir la liste des fonctionnalités améliorées et des correctifs de bogues apportés à .NET Framework 4.7, consultez la page Liste des changements de .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 chiffrement à courbe elliptique (ECC)*

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

.NET Framework 4.7 ajoute également la prise en charge de courbes supplémentaires (notamment la série de courbes Brainpool) et intègre des définitions prédéfinies pour faciliter la création via les nouvelles méthodes de fabrique 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 cette fonctionnalité doit être activée pour les applications qui s’exécutent sous .NET Framework 4.7 mais qui ciblent une version antérieure de .NET Framework. Pour plus d’informations, consultez la section Compatibilité des applications.

Mise en réseau

.NET Framework 4.7 ajoute les fonctionnalités liées au réseau suivantes :

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

La pile TLS, qui est utilisée par System.Net.Security.SslStream et les composants au-dessus de la pile, comme 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 propose les nouvelles fonctionnalités suivantes :

Extensibilité du cache d’objets

À compter de .NET Framework 4.7, ASP.NET ajoute un nouvel ensemble d’API permettant aux développeurs de remplacer les implémentations 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 maintenant remplacer un des trois composants suivants si l’implémentation ASP.NET n’est pas appropriée :

  • Object Cache Store. À l’aide de la nouvelle section de configuration des fournisseurs de cache, les développeurs peuvent incorporer de nouvelles implémentations d’un cache d’objets pour une application ASP.NET en utilisant 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 approchent la limite en octets privés définie pour le processus, ou lorsque la machine manque de mémoire RAM physique disponible. Lorsque ces limites sont proches, des 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 opportunes. Les développeurs peuvent désormais écrire leurs propres moniteurs de mémoire pour remplacer le moniteur par défaut en utilisant la propriété ApplicationMonitors.MemoryMonitor.

  • Memory Limit Reactions. Par défaut, ASP.NET tente de tronquer le cache d’objets et appelle régulièrement GC.Collect quand la limite en octets privés du processus est proche. Pour certaines applications, la fréquence des appels à GC.Collect ou la quantité de mémoire cache tronquée 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 les modifications suivantes :

Possibilité de configurer les paramètres de sécurité de message par défaut avec 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 en tant que protocole de sécurité de message par défaut. Il s’agit d’un paramètre à activer ; pour cela, vous devez ajouter l’entrée suivante à votre fichier de configuration d’application :

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

Amélioration de la fiabilité des applications WCF et de la sérialisation WCF

WCF inclut plusieurs modifications du code qui éliminent la concurrence critique, améliorant ainsi les performances et la fiabilité des options de sérialisation. Il s’agit notamment des paramètres suivants :

  • Meilleure prise en charge pour le mélange de code synchrone et asynchrone dans les appels à SocketConnection.BeginRead et à SocketConnection.Read.
  • Meilleure fiabilité lors de l’abandon d’une connexion avec SharedConnectionListener et DuplexChannelBinder.
  • Meilleure 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 pour les moniteurs à haute résolution.

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 de la haute résolution améliore la disposition et l’apparence des formulaires et des contrôles sur les moniteurs à haute résolution. La haute résolution dynamique change la disposition et l’apparence des formulaires et contrôles lorsque l’utilisateur modifie la haute résolution ou le facteur d’échelle d’affichage d’une application en cours d’exécution.

La prise en charge de la haute résolution 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 de la haute résolution et de la haute résolution dynamique à votre application Windows Forms, consultez Prise en charge de la haute résolution dans Windows Forms.

Windows Presentation Foundation (WPF)

Dans .NET Framework 4.7, WPF propose 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é à activer dans .NET Framework. Pour plus d’informations, consultez la section Compatibilité des applications.

Nouvelle implémentation pour l’impression d’API 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 connaître 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 apporte de nouvelles fonctionnalités dans les domaines suivants :

Pour obtenir la liste des nouvelles API ajoutées à .NET Framework 4.6.2, consultez la page Changements au niveau des API de .NET Framework 4.6.2 sur GitHub. Pour obtenir la liste des fonctionnalités améliorées et des correctifs de bogues apportés à .NET Framework 4.6.2, consultez la page Liste des changements de .NET Framework 4.6.2 sur GitHub. Pour plus d’informations, consultez Announcing .NET Framework 4.6.2 sur le blog .NET.

ASP.NET

Dans .NET Framework 4.6.2, ASP.NET propose 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’annotations de données vous permettent d’effectuer une 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 les conditions suivantes sont réunies :

  1. L’élément 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 se présente sous la forme DataAnnotation.Localization.{nom}.resx, où nom est le nom de culture au format code_languepays-code_région ou code_langue.

  4. Le nom de clé de la ressource est la chaîne assignée à l’attribut ValidationAttribute.ErrorMessage, et sa valeur correspond au 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 note 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 localisé en français (fr) :

Nom Valeur
The rating must be between 1 and 10. La note doit être comprise entre 1 et 10.

De plus, la localisation des annotations de données est extensible. Les développeurs peuvent incorporer leur propre fournisseur de localisation 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 magasins d’état de session, ASP.NET propose une nouvelle interface, System.Web.SessionState.ISessionStateModule, qui hérite de IHttpModule et permet aux développeurs d’implémenter leurs propres fournisseurs de modules d’état de session et de magasins de sessions asynchrones. L’interface se définit 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

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

Prise en charge asynchrone pour les fournisseurs de cache de sortie

À compter de .NET Framework 4.6.2, il est possible d’utiliser des méthodes qui retournent des tâches avec les fournisseurs de cache de sortie de façon à profiter de la scalabilité des opérations asynchrones. Les fournisseurs qui implémentent ces méthodes réduisent le blocage de threads sur un serveur web et améliorent la scalabilité d’un service ASP.NET.

Les API suivantes ont été ajoutées pour assurer la prise en charge des fournisseurs de cache de sortie asynchrones :

Catégories de caractères

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

La prise en charge d’Unicode 8.0 se limite à la classification des caractères de la classe CharUnicodeInfo et aux types et méthodes qui en dépendent. 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’expressions régulières du .NET Framework. La comparaison et le tri des caractères et des chaînes ne sont pas affectés par cette évolution et continuent de s’appuyer sur le système d’exploitation sous-jacent ou bien, dans le cas des systèmes Windows 7, sur les données de caractères fournies par .NET Framework.

Pour en savoir plus sur l’évolution des catégories de caractères entre Unicode 6.0 et Unicode 7.0, consultez l’article traitant de la norme Unicode, version 7.0.0 sur le site web du consortium Unicode. Pour en savoir plus sur les changements intervenus entre Unicode 7.0 et Unicode 8.0, consultez l’article traitant de la norme Unicode, version 8.0.0 sur le site web du consortium Unicode.

Chiffrement

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 de 1024 bits de la norme FIPS 186-2.

En plus de prendre en charge les clés plus volumineuses de FIPS 186-3, .NET Framework 4.6.2 autorise le calcul de signatures à l’aide des algorithmes de hachage de la famille SHA-2 (SHA256, SHA384 et SHA512). La prise en charge de FIPS 186-3 est assurée par la nouvelle classe System.Security.Cryptography.DSACng.

Dans la logique des récentes évolutions de la classe RSA de .NET Framework 4.6 et de la classe ECDsa de .NET Framework 4.6.1, la classe de base abstraite DSA de .NET Framework 4.6.2 propose des méthodes supplémentaires qui permettent aux appelants d’utiliser cette fonctionnalité sans opération de cast. Vous pouvez appeler la méthode d’extension DSACertificateExtensions.GetDSAPrivateKey pour signer des données, comme le montre 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 le montre 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

La prise en charge de l’accord d’échange de clés Curve Diffie-Hellman basé sur les courbes elliptiques avait été ajoutée à .NET Framework 3.5 avec trois routines de fonction de dérivation de clés (KDF) différentes. Les entrées à destination de ces routines, tout comme les routines proprement dites, étaient configurées via les propriétés de 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 afin de représenter plus clairement ces routines KDF et leurs entrées :

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

HASH(secretPrepend || x || secretAppend)

HASH(secretPrepend OrElse x OrElse secretAppend)

où x représente le résultat du calcul de l’algorithme EC Diffie-Hellman.
DeriveKeyFromHmac(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[], Byte[]) Dérive le matériel de clé à l’aide de la formule

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

HMAC(hmacKey, secretPrepend OrElse x OrElse secretAppend)

où x représente le résultat du calcul de l’algorithme EC Diffie-Hellman.
DeriveKeyTls(ECDiffieHellmanPublicKey, Byte[], Byte[]) Dérive le matériel de clé à l’aide de l’algorithme de dérivation de la fonction pseudo-aléatoire (PRF) TLS.

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 de l’utilisation des clés symétriques stockées sur du matériel, et .NET Framework 4.6.2 a permis aux développeurs d’utiliser cette fonctionnalité. Sachant que la notion de noms de clés et de fournisseurs de clés est spécifique à l’implémentation, cette fonctionnalité impose l’utilisation du constructeur des types d’implémentation concrets plutôt que l’approche par défaut privilégiée (comme l’appel de Aes.Create).

La prise en charge du chiffrement symétrique des clés persistantes 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 d’URI sont toutes exposées dans SignedXml :

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

Les programmes qui ont inscrit un gestionnaire SignatureDescription personnalisé dans CryptoConfig dans le but d’ajouter la prise en charge de ces algorithmes continueront de fonctionner comme par le passé. Cependant, comme il y a désormais les valeurs par défaut de la 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 expirations de délai avec les bases de données Azure SQL

Quand le regroupement de connexions est activé et qu’une expiration de délai ou toute autre erreur de connexion se produit, une exception est mise en cache ; cette exception mise en cache est levée chaque fois qu’une nouvelle tentative de connexion intervient entre 5 secondes et 1 minute après. Pour plus d’informations, consultez Regroupement de connexions SQL Server (ADO.NET).

Ce comportement n’est pas souhaitable quand il s’agit d’établir des connexions à des bases de données Azure SQL Database, car les tentatives de connexion peuvent échouer avec des erreurs transitoires qui sont en général récupérées rapidement. Pour des nouvelles tentatives de connexion plus abouties, le comportement de période de blocage de pool de connexions est supprimé quand les connexions aux bases de données Azure SQL Database échouent.

L’ajout du nouveau mot clé PoolBlockingPeriod vous permet de sélectionner la période de blocage qui convient le mieux à votre application. Ces valeurs comprennent :

Auto

La période de blocage de pool de connexions d’une application qui se connecte à une base de données Azure SQL Database est désactivée, pendant que celle d’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 de point de terminaison d’un serveur se termine par l’un des éléments suivants, il est considéré comme une base de données Azure SQL Database :

  • .database.windows.net

  • .database.chinacloudapi.cn

  • .database.usgovcloudapi.net

  • .database.cloudapi.de

AlwaysBlock

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

NeverBlock

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

Améliorations pour Always Encrypted

SQLClient inaugure 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 sont désormais mises en cache pour les paramètres des requêtes. Dans la mesure où la propriété SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled est définie sur true (valeur par défaut), si une même requête est appelée plusieurs fois, le client ne récupère les métadonnées des paramètres qu’une seule fois sur le serveur.

  • Les entrées de clés de chiffrement de colonnes présentes dans le cache de clés sont désormais supprimées au bout d’un délai configurable, qui est défini à 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 se limite à l’utilisation de certificats avec une clé publique dont l’exposant ne dépasse pas 32 bits de longueur. Quand 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 les 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"
/>

Vous pouvez en faire autant par programmation avec un code de ce type :

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 à l’heure 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 même un fuseau horaire. Il est nécessaire d'accepter cette fonctionnalité. Pour l’activer, ajoutez le paramètre suivant à votre fichier app.config :

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

Quand cette fonctionnalité est activée, un objet DataContractJsonSerializer utilise le type TimeZoneInfo à la place du type TimeZone pour désérialiser les données de date et d’heure. TimeZoneInfo prend en charge plusieurs règles d’ajustement, permettant ainsi d’utiliser des données de fuseau horaire historiques, ce qui n’est pas le cas de TimeZone.

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

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. Dans la mesure où ce paramètre d’application est défini sur false (valeur par défaut), les clients utilisant NetNamedPipeBinding peuvent tenter de se connecter à un service écoutant 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. Si ce paramètre d’application est défini sur false, le client tente de se connecter au mauvais service. Une fois le paramètre d’application défini sur true, le client se connecte systématiquement au service le plus approprié.

Notes

Les clients qui utilisent NetNamedPipeBinding recherchent les services à partir de leur adresse de base (s’ils en ont une) et non de l’adresse complète du point de terminaison. Pour faire en sorte que ce paramètre fonctionne toujours, le service doit utiliser une adresse de base unique.

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

Quand vous utilisez NetTcp avec la sécurité du transport et un type d’informations d’identification de certificat, SSL 3.0 n’est plus le protocole utilisé par défaut quand il s’agit de négocier une connexion sécurisée. Dans la majorité des cas, cela ne devrait pas avoir de conséquences sur les applications existantes, car TLS 1.0 est inclus dans la liste de protocoles pour NetTcp. Tous les clients existants doivent pouvoir négocier une connexion en utilisant au moins TLS 1.0. Si Ssl3 est exigé, 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 les données peut désormais déclarer explicitement le mode de tri des groupes. Le tri explicite résout le problème du classement non intuitif qui se produit quand une application ajoute ou supprime dynamiquement des groupes ou quand elle modifie la valeur de propriétés d’élément impliquées dans le regroupement. Il peut aussi améliorer l’efficacité de la création de groupes en comparant les propriétés de regroupement non pas au niveau du tri de la collection complète mais du tri des groupes.

Pour prendre en charge le tri des groupes, les nouvelles propriétés GroupDescription.SortDescriptions et GroupDescription.CustomSort décrivent le mode de tri de la collection de groupes produite par l’objet GroupDescription. Ce comportement est analogue à la façon dont les propriétés ListCollectionView de même nom décrivent le mode de tri des éléments de données.

Il est possible d’utiliser les deux nouvelles propriétés statiques de la classe PropertyGroupDescription, CompareNameAscending et CompareNameDescending, pour les cas les plus courants.

Par exemple, le code XAML suivant regroupe les données par âge, trie les groupes d’âge par ordre croissant, puis regroupe les éléments de chaque groupe d’âge par nom de famille.

<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 des claviers tactiles permet d’assurer le suivi du focus dans des applications WPF en appelant et en masquant automatiquement le clavier tactile dans Windows 10 dès lors que 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. Pour savoir comment permettre à votre application WPF de prendre en charge la résolution par moniteur, consultez les exemples et le guide du développeur sur GitHub.

Dans les versions précédentes de .NET Framework, les applications WPF prennent en charge la résolution au niveau du système. En d’autres termes, l’interface utilisateur de l’application est éventuellement mise à l’échelle par le système d’exploitation, en fonction de la résolution 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 changements de résolution par moniteur dans les applications WPF en ajoutant une instruction de configuration à la section <runtime> du fichier de configuration de votre 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 les domaines suivants :

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 de 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 autorise la présence du Concepteur de flux de travail dans une application extérieure à 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 de .NET Framework antérieures à la version 4.6.2, la fonctionnalité IntelliSense du concepteur WF est inopérante quand un client recrée 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 donne accès à IntelliSense.

Les applications Workflow V1 pour lesquelles le suivi de flux de travail est activé s’exécutent désormais en mode FIPS

Les ordinateurs pour lesquels le mode de conformité FIPS est activé peuvent désormais exécuter correctement une application de type Workflow version 1 en ayant le suivi de flux de travail activé. Pour permettre ce cas de figure, vous devez apporter la modification suivante à votre fichier app.config :

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

Si ce scénario n’est pas autorisé, 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 pour les plateformes Windows ».

Amélioration de flux de travail quand la mise à jour dynamique est utilisée 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 antérieures à .NET Framework 4.6.2, le fait de charger un fichier XAML dans Visual Studio pour un workflow enregistré après avoir appelé DynamicUpdateServices.PrepareForUpdate peut occasionner les problèmes suivants :

  • Le Concepteur de flux de travail ne peut pas charger le fichier XAML correctement (quand ViewStateData.Id est en fin de ligne).

  • Le Concepteur d’activités d’organigramme ou les autres Concepteurs d’activités de flux de travail peuvent afficher tous les objets à leurs emplacements par défaut plutôt que les valeurs de propriétés 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 exigé ; aucune mesure supplémentaire n’est à prendre dans l’application ClickOnce pour activer la prise en charge de TLS 1.1 et 1.2.

Conversion d’applications Windows Forms et WPF en applications UWP

Windows permet désormais de porter les applications de bureau Windows, dont les applications WPF et Windows Forms, sur la plateforme Windows universelle (UWP). Cette technologie fait office de pont en vous permettant de migrer progressivement votre base de code existante vers UWP, et ainsi de porter votre application sur tous les appareils Windows 10.

Les applications de bureau converties obtiennent une identité d’application comparable à celle des applications UWP, ce qui rend les API UWP accessibles pour activer certaines fonctionnalités, telles que les vignettes dynamiques et les notifications. L’application continue de se comporter comme auparavant et s’exécute comme une application entièrement approuvée. Une fois l’application convertie, un processus de conteneur d’application peut être ajouté au processus d’approbation complète existant pour ajouter une interface utilisateur adaptative. Quand toutes les fonctionnalités sont déplacées vers le processus de conteneur d’application, le processus d’approbation complète 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 favoriser ce scénario, les API ci-dessous ont été ajoutées à l’API de débogage non managé.

Nouveautés de .NET Framework 4.6.1

.NET Framework 4.6.1 apporte 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 l’algorithme ECDSA

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

ECDSA offre de meilleures performances et constitue un algorithme de chiffrement plus sécurisé que RSA. Il constitue un excellent choix quand les performances et la scalabilité de la sécurité de la couche de transport (TLS) constituent une préoccupation. L’implémentation du .NET Framework encapsule les appels dans les fonctionnalités Windows existantes.

L’exemple de code suivant montre combien il est facile de générer une signature pour un flux d’octets à l’aide de la nouvelle prise en charge des certificats X509 ECDSA 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 contraste fortement 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é Chiffrement intégral pour les clés matérielles protégées

ADO.NET prend désormais en charge le stockage des clés principales de colonnes Toujours chiffré en mode natif dans les modules de sécurité matériels (HSM, Hardware Security Modules). 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 fabricant des modules HSM ou les fournisseurs de magasin de clés CNG sur les serveurs d’applications ou les ordinateurs clients pour accéder aux données Always Encrypted protégées par des clés principales de colonnes stockées dans un module HSM.

Amélioration du comportement de connexion de MultiSubnetFailover pour AlwaysOn

Désormais, SqlClient fournit automatiquement une connexion plus rapide à un groupe de disponibilité AlwaysOn. Il détecte de façon transparente si votre application se connecte à un groupe de disponibilité AlwaysOn sur un autre sous-réseau, détecte rapidement le serveur actif actuel et fournit une connexion au serveur. Avant cette mise en production, une application devait définir la chaîne de connexion à inclure "MultisubnetFailover=true" pour indiquer qu’elle était connectée à 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.

performances améliorées

Le retard de déclenchement d’é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 de la vérification orthographique

Le vérificateur orthographique de WPF a été mis à jour sur Windows 8.1 et les versions ultérieures pour tirer parti de la prise en charge, par le système d’exploitation, de la vérification orthographique de langues supplémentaires. Aucune fonctionnalité n’a été modifiée sur les versions de Windows antérieures à Windows 8.1.

Comme dans les versions précédentes de .NET Framework, la langue d’un contrôle TextBox ou d’un bloc RichTextBox est détectée 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 linguistique 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 le .NET Framework 4.6.1, WPF reconnaît les dictionnaires personnalisés qui sont inscrits de manière globale. Cette fonctionnalité est disponible en plus de la possibilité de les inscrire par contrôle.

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

  • Les fichiers doivent avoir l’extension .dic (pour les mots ajoutés), .exc (pour les mots exclus) ou .acl (pour la correction automatique).

  • Les fichiers doivent être en texte brut UTF-16 LE qui commence par la marque d’ordre d’octet.

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

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

Notes

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

Exemples

Vous trouverez des exemples WPF dans le dépôt GitHub Microsoft/WPF-Samples. Aidez-nous à améliorer nos exemples en nous envoyant une requête d’extraction ou en ouvrant un problème GitHub.

Extensions DirectX

WPF inclut un package NuGet qui fournit de nouvelles implémentations de D3DImage facilitant l’interaction avec du contenu DX10 et Dx11. Le code de ce package a été mis en open source et est disponible sur GitHub.

Windows Workflow Foundation : Transactions

La méthode Transaction.EnlistPromotableSinglePhase peut maintenant utiliser un gestionnaire de transactions distribuées 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, des limitations sont placées 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 elles requièrent une promotion vers MSDTC :

Une fois qu’un promoteur de transaction non MSDTC est inscrit, il doit être utilisé pour les futures inscriptions durables en utilisant les 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 d’octets (Byte qui représente le jeton promu. Une application peut obtenir le jeton promu pour une transaction non MSDTC promue à l’aide de 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, la compilation des assemblys en mémoire par Roslyn est beaucoup plus courante. Pour les développeurs qui créent des outils de profilage, cela signifie que les fichiers PDB qui étaient historiquement sérialisés sur le disque risquent de ne plus être présents. Les outils de profilage utilisent souvent des fichiers PDB pour remapper du 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 inclut désormais deux nouvelles méthodes, ICorProfilerInfo7::GetInMemorySymbolsLength et ICorProfilerInfo7::ReadInMemorySymbols, qui permettent de fournir ces outils de profilage avec un accès aux données PDB en mémoire. En utilisant les nouvelles API, un profileur peut obtenir le contenu d’un fichier PDB en mémoire sous la forme d’un 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 maintenant modifier certaines métadonnées. Précédemment, ces outils pouvaient instrumenter le langage intermédiaire à 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 des modifications de métadonnées après le chargement du module, notamment en ajoutant de nouveaux enregistrements AssemblyRef, TypeRef, TypeSpec, MemberRef, MemberSpec et UserString. Cette modification permet une plus large gamme d’instrumentations instantanées possibles.

Fichiers PDB du générateur d’images natives (NGen)

Le suivi d’événements entre ordinateurs permet aux clients de profiler un programme sur l’Ordinateur A et d’examiner les données de profilage avec le mappage des lignes sources sur l’Ordinateur B. Avec les versions antérieures de .NET Framework, l’utilisateur devait copier tous les modules et les images natives de l’ordinateur profilé vers l’ordinateur d’analyse qui contenait le fichier PDB en langage intermédiaire pour créer le mappage du code source au code natif. Ce processus peut fonctionner correctement lorsque les fichiers sont relativement petits, comme pour les applications de téléphone. Toutefois, les fichiers peuvent être très volumineux sur des systèmes de bureau et leur copie peut prendre beaucoup de temps.

Avec les fichiers PDB de NGen, NGen peut créer un fichier PDB qui contient le mappage du langage intermédiaire au code natif sans dépendance sur le fichier PDB en langage intermédiaire. 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 le fichier PDB de l’image native est beaucoup plus petit que l’ensemble des modules et images natives, le processus de copie de l’Ordinateur A vers l’Ordinateur B est beaucoup plus rapide.

Nouveautés du .NET 2015

.NET Framework 2015 introduit .NET Framework 4.6 et .NET Core. Certaines nouvelles fonctionnalités s'appliquent aux deux infrastructures, alors que d'autres sont spécifiques au .NET Framework 4.6 ou au .NET Core.

  • ASP.NET Core

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

    MVC, les API web et les pages web sont unifiés dans une infrastructure unique appelée MVC 6. Vous créez des applications ASP.NET Core via les outils de Visual Studio 2015 ou ultérieur. Vos applications existantes fonctionneront sur le nouveau .NET Framework. Toutefois, pour générer une application qui utilise MVC 6 ou SignalR 3, vous devez utiliser le système de projet de Visual Studio 2015 ou ultérieur.

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

  • Mises à jour d’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 de réponse asynchrone, HttpResponse.FlushAsync, qui autorise les réponses à être vidées de façon asynchrone à l'aide du support async/await de votre langue.

    • La liaison de modèle prend en charge les méthodes qui retournent des tâches

      Dans .NET Framework 4.5, ASP.NET a ajouté une fonctionnalité de liaison de modèle qui autorise une approche extensible, axée sur le code pour les opérations de données CRUD dans les contrôles utilisateur et les pages Web Forms. 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 de Web Forms d'obtenir les avantages de la scalabilité du modèle asynchrone et la simplicité du système de liaison de données lorsqu'ils utilisent les versions plus récentes des ORM, y compris l'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>

      Sur les applications qui ciblent .NET Framework 4.6, sa valeur par défaut est true. Sur les applications s’exécutant sur .NET Framework 4.6 qui ciblent une version antérieure de .NET Framework, sa valeur par défaut est false. Son activation s'obtient en définissant le paramètre de configuration avec la valeur true.

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

      HTTP/2 est une nouvelle version du protocole HTTP qui offre une bien meilleure utilisation de la connexion (moins d’allers-retours entre le client et le serveur), ce qui réduit la latence pendant le chargement des pages web pour les utilisateurs. Ce sont les pages web (par opposition aux services) qui profitent le plus de HTTP/2, car le protocole optimise les demandes de plusieurs artefacts dans 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 les fonctionnalités réseau existent sur plusieurs couches, de nouvelles fonctionnalités ont dû être rajoutées dans Windows, IIS et ASP.NET pour activer HTTP/2. Vous devez exécuter Windows 10 pour utiliser HTTP/2 avec ASP.NET.

      HTTP/2 est également pris en charge et activé par défaut sur les applications UWP Windows 10 qui utilisent l'API System.Net.Http.HttpClient.

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

      Notes

      Alors qu’ASP.NET Core prend 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 de tâches lourdes à effectuer 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 tel est le cas de votre serveur.

    • 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. Cette approche part du principe que les jetons d’authentification (dans le cache de votre navigateur) peuvent être volés et utilisés par des personnes mal intentionnées pour accéder à des ressources sécurisées (par exemple, votre compte bancaire) sans avoir besoin de connaître votre mot de passe ou toute autre information confidentielle. Le nouveau protocole vise à contenir ce problème.

      Le protocole de liaison de jeton sera implémenté dans Windows 10 en tant que fonctionnalité du navigateur. Les applications ASP.NET participeront au protocole, en validant les jetons d'authentification pour qu'ils soient légitimes. Les implémentations côté client et 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. Cependant, il n'est pas pris en charge par ASP.NET en raison de certaines fonctionnalités ASP.NET fondées sur un code de hachage stable. Dans le .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 la fonctionnalité Always Encrypted, SQL Server peut effectuer des opérations sur des données chiffrées, et surtout, la clé de chiffrement est stockée avec l’application à l’intérieur de l’environnement approuvé du client, et non pas sur le serveur. Always Encrypted sécurise les données client pour 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 de données se produit de manière transparente au niveau du pilote, ce qui réduit des modifications à apporter 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 le code managé

    .NET Framework 4.6 propose une nouvelle version du compilateur JIT 64 bits (anciennement RyuJIT). Le nouveau compilateur 64 bits offre des améliorations significatives des performances par rapport à l'ancien compilateur JIT 64 bits. Le nouveau compilateur 64 bits est activé pour les processus 64 bits qui s’exécutent au-dessus de .NET Framework 4.6. Votre application s'exécute dans un processus 64 bits s'il est compilé en mode 64 bits ou AnyCPU, et s'exécute sur un système d'exploitation 64 bits. Bien que toutes les mesures nécessaires aient été prises pour que la transition vers le nouveau compilateur soit aussi transparente que possible, des modifications du comportement sont possibles.

    Le nouveau compilateur JIT 64 bits inclut également des fonctionnalités d'accélération matérielle SIMD en cas d'association aux types SIMD de l'espace de noms System.Numerics, ce qui peut produire une bonne amélioration des 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 réduit la mémoire virtuelle, ce qui est particulièrement utile pour les grandes applications 32 bits (tels que Visual Studio), et économise aussi la mémoire physique.

  • Changements des bibliothèques de classes de base

    Plusieurs nouvelles API ont été ajoutées au .NET Framework 4.6 pour des scénarios clés. Vous remarquerez les changements et les ajouts suivants :

    • Implémentations d’IReadOnlyCollection<T>

      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 du thread actuel définie par la propriété Thread.CurrentThread.CurrentCulture et la culture du thread d'interface utilisateur actuel définie par les propriétés Thread.CurrentThread.CurrentUICulture changent également.

    • Améliorations du nettoyage de la mémoire (GC)

      La classe GC inclut désormais les méthodes TryStartNoGCRegion et EndNoGCRegion, qui vous permettent d'interdire le garbage collection durant l'exécution d'un chemin 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 SIMD

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

      Comme le nouveau compilateur JIT 64 bits inclut également des fonctionnalités d'accélération matérielle SIMD, il en découle une amélioration des performances particulièrement significative lorsque vous utilisez les types SIMD avec le nouveau compilateur JIT 64 bits.

    • Mises à jour du chiffrement

      L’API System.Security.Cryptography est mise à jour pour prendre en charge les API de chiffrement CNG de Windows. Jusqu’à présent, le .NET Framework reposait entièrement sur une version antérieure des API de chiffrement Windows comme base d’implémentation de System.Security.Cryptography. Nous avons reçu des demandes pour la prise en charge de l’API CNG, car elle prend en charge les algorithmes de chiffrement modernes, qui sont importants pour certaines catégories d’applications.

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

      • Un 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 retourne une implémentation CNG plutôt qu'une implémentation CAPI lorsque cela est possible. (Certaines cartes à puce, etc., nécessitent toujours CAPI, et les API gèrent le secours).

      • La 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 opérations courantes ne nécessitent plus de conversion. Par exemple, le chiffrement des données utilisant un objet X509Certificate2 nécessite un code comme celui qui suit dans les versions antérieures 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 la conversion.

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

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

    • Commutateurs de compatibilité

      La classe AppContext ajoute une fonctionnalité de compatibilité qui permet aux auteurs de bibliothèque de fournir un mécanisme de désactivation uniforme des nouvelles fonctionnalités pour les utilisateurs. Elle établit un contrat souple entre les composants pour la communication des demandes de désactivation. Cette fonctionnalité est particulièrement importante quand une modification est apportée aux fonctionnalités existantes. À l'inverse, il existe déjà une activation implicite des 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 qu'ils aient un impact sur le comportement de la bibliothèque. Par défaut, les bibliothèques fournissent la nouvelle fonctionnalité et ne peuvent la modifier (c'est-à-dire fournir la version antérieure) que 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) définie par une bibliothèque dépendante. Le commutateur a toujours implicitement la valeur false. En définissant le commutateur avec la valeur true, vous l'activez. En définissant explicitement le commutateur avec la valeur 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 et s'il l'utilise ensuite correctement.

      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 préférable d'utiliser un format homogène pour les commutateurs, car ils constituent un contrat formel exposé par une bibliothèque. Voici les deux formats évidents.

      • Commutateur.espace de noms.nom_commutateur

      • Commutateur.bibliothèque.nom_commutateur

    • Changements apportés 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 antérieures 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 « Culture et opérations asynchrones basées sur les tâches » de la rubrique relative à la classe CultureInfo.

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

      Trois méthodes pratiques, Task.CompletedTask, Task.FromCanceled et Task.FromException, ont été ajoutées au modèle asynchrone basé sur des 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 enregistrer les messages administratifs ou opérationnels dans le journal des événements, en plus des sessions ETW existantes créées sur l'ordinateur. Par le passé, vous deviez utiliser le package Microsoft.Diagnostics.Tracing.EventSource NuGet pour cette fonctionnalité. Cette fonctionnalité est désormais intégrée à .NET Framework 4.6.

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

      • Événements dynamiques

        Permet que les événements soient définis « à la volée », sans créer de méthodes d'événement.

      • Charges utiles enrichies

        Permet que les tableaux et les classes avec attributs spécifiques, ainsi que les types primitifs, soient transmis comme 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 HDPI

      La prise en charge HDPI dans WPF est désormais mieux assurée 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 a la valeur .NET Framework 4.6. Les applications qui ciblent les versions antérieures du framework mais qui s’exécutent sur .NET Framework 4.6 peuvent adopter 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 chevauchant plusieurs écrans avec différents paramètres DPI (programme d'installation multi-DPI) sont à présent restituées entièrement sans zones obscurcies. Vous pouvez désactiver ce comportement en ajoutant la ligne suivante à la section <appSettings> du fichier app.config :

      <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 de clients sur Connect selon lesquels l’interaction tactile produisait un comportement imprévisible ont été traités dans .NET Framework 4.6. Le seuil de double appui pour les applications du Windows Store et les applications WPF est maintenant le même que 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 désactiver cette fonctionnalité en affectant à la propriété HwndSourceParameters.UsesPerPixelTransparency la valeur true.

  • Windows Communication Foundation (WCF)

    • Prise en charge SSL

      WCF prend désormais en charge la version TLS 1.1 et TLS 1.2 de SSL, en plus de SSL 3.0 et TLS 1.0, lorsque vous utilisez NetTcp avec l'authentification client et la sécurité de transport. Il est désormais possible de sélectionner le protocole à utiliser, ou de désactiver les anciens protocoles moins sécurisés. Cela peut être effectué en définissant la propriété SslProtocols ou en ajoutant le code suivant à 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>

    • Envoi de messages à l’aide de 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 d'effectuer cette opération :

      • Utilisation d’un préfixe de nom de groupe de connexion

        Les utilisateurs peuvent spécifier une chaîne que WCF utilisera comme préfixe du nom de groupe de connexion. Deux messages avec des préfixes différents sont envoyés à l'aide de différentes connexions HTTP sous-jacentes. 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érentes fabriques de canaux

        Les utilisateurs peuvent aussi activer une fonctionnalité qui permet de s'assurer 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 la propriété appSetting suivante avec la valeur 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. Comme certaines activités créent des signets non-protocole dans leur implémentation, il peut ne pas être évident qu'un signet non-protocole existe. Ceux-ci incluent État et Prélèvement. 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 la ligne suivante à la section appSettings de votre fichier app.config :

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

    La valeur par défaut est 60 secondes. Si value a la valeur 0, les demandes exceptionnelles sont immédiatement rejetées comme erreur avec un texte tel que le suivant :

    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 est différente de zéro, il existe des signets non-protocole, l'intervalle de délai d'attente expire et l'opération échoue avec un message d'expiration.

  • Transactions

    Vous pouvez maintenant inclure l'identificateur de transaction distribuée pour la transaction ayant 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 de 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, permettant aux applications .NET de tirer parti du nouveau comportement. Dans les précédentes versions de Windows, il y avait une limite artificielle de connexions simultanées (généralement 16 384, taille par défaut de la plage de ports dynamiques), ce qui pouvait limiter la scalabilité d'un service en provoquant l'épuisement du port sous charge.

      Dans .NET Framework 4.6, deux API ont été ajoutées pour permettre la réutilisation de port, ce qui supprime 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 de port local sur les connexions HTTP, définissez la propriété ServicePointManager.ReusePort avec la valeur true. Toutes les connexions de socket TCP sortantes de HttpClient et HttpWebRequest sont alors contraintes d’utiliser une nouvelle option de socket Windows 10, SO_REUSE_UNICASTPORT, qui permet la réutilisation du port local.

      Les développeurs écrivant une application de 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 lors de la liaison.

    • Prise en charge des noms de domaine internationaux et 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, ainsi que le rectangle spécifié par la propriété Bounds utilisée durant le dessin de UITypeEditor.

    Il est nécessaire d'accepter cette fonctionnalité. Pour l'activer, affectez à l'élément EnableWindowsFormsHighDpiAutoResizing la valeur true dans le fichier de configuration de l'application (app.config) :

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

  • Prise en charge des encodages de pages de codes

    .NET Core prend en charge principalement les codages Unicode, et fournit par défaut une prise en charge limitée des codages de pages de codes. Vous pouvez ajouter la prise en charge des encodages de pages de codes disponibles dans .NET Framework, mais non pris en charge dans .NET Core, en inscrivant les encodages de pages 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 désormais tirer parti d’une nouvelle technologie qui compile les applications en code natif plutôt qu’en code IL (Intermediate Language). Cette technologie produit des applications dont les temps de démarrage et d’exécution sont plus rapides. Pour plus d’informations, consultez Compilation d’applications avec .NET Native. Pour obtenir une vue d’ensemble de .NET Native illustrant sa différence par rapport à la compilation JIT et NGEN, et pour connaître ses implications au niveau de votre code, consultez Compilation et .NET Native.

Vos applications sont compilées en code natif par défaut dans Visual Studio 2015 ou ultérieur. Pour plus d’informations, consultez Prise en main de .NET Native.

Pour permettre la prise en charge du débogage des applications .NET Native, un certain nombre de nouvelles interfaces et d'é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).

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 au moment où la réponse est vidée dans l'application cliente. Envisagez d'utiliser ces méthodes au lieu des événements PreSendRequestHeaders et PreSendRequestContent ; elles sont plus efficaces et fiables.

    La méthode HostingEnvironment.QueueBackgroundWorkItem vous permet de planifier des 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 brutalement au processus de traitement tant que tous les éléments de travail en arrière-plan ne sont pas 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 d'API comme HttpResponse.StatusCode (qui lèvent des exceptions si les en-têtes ont été écrits) vont réussir.

  • Redimensionnement dans les contrôles Windows Forms. Cette fonctionnalité a été étendue. 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 est nécessaire d'accepter cette fonctionnalité. Pour l'activer, affectez à l'élément EnableWindowsFormsHighDpiAutoResizing la valeur 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 qui implémente donc l'interface IPromotableSinglePhaseNotification) peut utiliser la nouvelle méthode Transaction.PromoteAndEnlistDurable pour demander :

    Ces demandes peuvent être faites au sein du même domaine d'application et ne nécessitent pas de 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 proposent 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 ont besoin que les assemblys dépendants soient injectés par le profileur pour qu'ils puissent être chargés immédiatement, plutôt qu'une fois que l'application est entièrement initialisée. Cette modification ne concerne pas les utilisateurs des API ICorProfiler existantes.

  • Améliorations du débogage. Les nouvelles API de débogage non managées suivantes améliorent l'intégration à un profileur. Vous pouvez à présent accéder aux métadonnées insérées par le profileur ainsi qu'aux variables locales et au code produit par les demandes ReJIT du compilateur pendant le débogage de dump.

  • Changements du suivi d’événements. .NET Framework 4.5.2 permet le traçage des activités de type Suivi d’événements pour Windows (ETW) hors processus pour une surface d’exposition plus importante. Ce dernier permet aux fournisseurs de gestion avancée de l'alimentation (APM) de fournir des outils légers qui suivent avec précision les coûts des demandes et activités individuelles qui traversent les threads. Ces événements sont déclenchés uniquement quand les contrôleurs ETW les autorisent ; par conséquent, les modifications ne concernent pas le code ETW écrit auparavant ni le code qui s'exécute avec la fonctionnalité ETW désactivée.

  • Promotion d’une transaction et sa conversion en une 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 précédemment créée par Transaction.EnlistPromotableSinglePhase en réponse à la méthode ITransactionPromoter.Promote. Elle demande à System.Transactions de promouvoir la transaction en une transaction MSDTC et de « convertir » l'inscription à promouvoir en une inscription durable. Après que la méthode s'est terminée avec succès, l'interface IPromotableSinglePhaseNotification n'est plus référencée par System.Transactions et toutes les futures notifications parviennent sur l'interface ISinglePhaseNotification fournie. L'inscription en question doit agir comme inscription durable, en prenant en charge la récupération et la journalisation des transactions. Consultez Transaction.EnlistDurable pour plus d'informations. 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

Mises à jour d’avril 2014 :

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

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

    • Vous pouvez inclure du code XAML (type Windows.UI.XAML) dans les bibliothèques portables quand vous ciblez Windows 8.1 ou Windows Phone 8.1. Les modèles XAML suivants sont pris en charge : Page vierge, Dictionnaire de ressources, Contrôle basé sur un 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 contenus du .NET Framework inclut à présent la documentation relative à .NET Native, une technologie de précompilation qui permet de générer et déployer des applications Windows. .NET Native compile directement vos applications en code natif, plutôt qu'en langage intermédiaire, pour de meilleures performances. Pour plus d’informations, consultez Compilation d’applications avec .NET Native.

  • Le site .NET Framework Reference Source propose une nouvelle expérience de navigation et des fonctionnalités améliorées. Vous pouvez à présent parcourir le code source .NET Framework en ligne, télécharger la référence à des fins de consultation hors connexion et parcourir les sources (notamment les correctifs et mises à jour) pendant le débogage. Pour plus d’informations, consultez l’entrée de blog qui présente le nouvel aspect de la source de référence .NET.

Les nouvelles fonctionnalités et améliorations des classes de base de .NET Framework 4.5.1 incluent les suivantes :

  • Redirection de liaison automatique des assemblys. Depuis Visual Studio 2013, lorsque vous compilez une application qui cible .NET Framework 4.5.1, il est possible d’ajouter des redirections de liaison au fichier de configuration de l’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.

  • Capacité à 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 de la classe EventSource.

  • Capacité à compacter explicitement le tas d'objets volumineux (LOH) pendant un garbage collection. Pour plus d'informations, consultez la propriété GCSettings.LargeObjectHeapCompactionMode.

  • Autres améliorations des performances, telles que la suspension d'application ASP.NET, les améliorations JIT multicœurs et le démarrage accéléré des applications 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 incluent :

  • Redimensionnement dans les 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 affectez la valeur true à l’élément EnableWindowsFormsHighDpiAutoResizing :

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

Les améliorations lors du débogage de vos applications .NET Framework dans Visual Studio 2013 incluent :

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

  • Modifier & Continuer pour applications 64 bits. Visual Studio 2013 prend en charge la fonctionnalité Modifier & Continuer pour les applications managées 64 bits pour le 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 simplifier le débogage des applications asynchrones dans Visual Studio 2013, la pile d'appels masque le code d'infrastructure fourni par les compilateurs pour prendre en charge la programmation asynchrone. Elle chaîne également les trames parentes logiques afin que vous puissiez 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 relatives à un point d'arrêt particulier, ainsi que toutes les autres tâches qui sont actuellement actives ou planifiées dans l'application. Vous pouvez en savoir plus sur cette fonctionnalité en lisant la section sur le débogage asynchrone de l’annonce relative à .NET Framework 4.5.1.

  • Meilleure prise en charge des exceptions pour les composants Windows Runtime. Dans Windows 8.1, une exception qui provient des applications Windows Store conserve les informations sur l'erreur qui a provoqué l'exception, même au-delà des limites du langage. Vous pouvez en savoir plus sur cette fonctionnalité en lisant la section sur le développement d’applications du Windows Store dans l’annonce relative au .NET Framework 4.5.1.

Depuis Visual Studio 2013, vous pouvez utiliser Mpgo.exe (Outil d'optimisation guidée par profil managé) pour optimiser les applications Windows 8.x Store, ainsi que les applications de bureau.

Pour les nouvelles fonctionnalités dans ASP.NET 4.5.1, consultez Notes de mise à jour ASP.NET et Web Tools pour Visual Studio 2013.

Nouveautés de .NET Framework 4.5

Classes de base

  • Capacité à réduire les redémarrages du système en détectant et en fermant les applications .NET Framework 4 pendant le déploiement. Consultez Réduction des redémarrages système durant les installations de .NET Framework 4.5.

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

  • Meilleures performances via une opération garbage collection en arrière-plan pour les serveurs. Lorsque vous utilisez le garbage collection de serveur dans .NET Framework 4.5, le garbage collection en 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. Consultez ProfileOptimization.

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

  • Capacité à 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 l'extraction des ressources. Consultez Empaqueter et déployer des ressources.

  • Améliorations de la compression Zip pour réduire la taille d'un fichier compressé. Voir 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 l'intermédiaire 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 dans Windows 8.

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

  • Possibilité de calculer les codes de hachage des 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.

Managed Extensibility Framework (MEF)

Dans .NET Framework 4.5, le package Managed Extensibility Framework (MEF) fournit les nouvelles fonctionnalités suivantes :

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

  • Modèle de programmation basé sur les conventions qui permet de créer des parties basées sur les conventions d'appellation, plutôt que sur les attributs.

  • Portées multiples.

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

Pour plus d’informations, consultez Vue d’ensemble de Managed Extensibility Framework.

Opérations asynchrones sur les fichiers

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 les tâches pour exécuter 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, l’outil Resource File Generator (Resgen.exe) vous permet de créer un fichier .resw à utiliser dans les applications Windows 8.x Store à partir d’un fichier .resources incorporé dans un assembly .NET Framework. Pour plus d’informations, consultez Resgen.exe (Resource File Generator).

L'outil d'optimisation guidée par profil managé (Mpgo.exe) vous permet d'améliorer le temps de démarrage de l'application, l'utilisation de la mémoire (taille du jeu de travail) et le débit en optimisant les assemblys d'image natifs. L'outil en ligne de commande génère des données de profil pour les assemblys natifs d'application graphique. Consultez Mpgo.exe (Outil d’optimisation guidée par profil managé). Depuis Visual Studio 2013, vous pouvez utiliser Mpgo.exe pour optimiser les applications 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 le calcul parallèle. Il s'agit notamment de performances améliorées, d'un contrôle accru, d'une prise en charge améliorée pour la programmation asynchrone, d'une nouvelle bibliothèque de flux de données et d'une prise en charge améliorée pour le débogage parallèle et l'analyse des performances. Consultez l’entrée relative aux nouveautés en matière de parallélisme dans .NET Framework 4.5 dans le blog consacré à la programmation parallèle avec .NET.

Web

ASP.NET 4.5 et 4.5.1 ajoutent la liaison de modèle pour Web Forms, la prise en charge de WebSocket, les gestionnaires asynchrones, les 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 d'une nouvelle interface de programmation permettant d'accepter et d'interagir avec une connexion de WebSocket à l'aide de la classe HttpListener existante et des classes associées est également incluse. Pour plus d'informations, consultez le nouvel espace de noms System.Net.WebSockets et la classe HttpListener.

En outre, .NET Framework 4.5 inclut les améliorations de mise en réseau suivantes :

  • Prise en charge URI conforme aux documents RFC. Pour plus d'informations, consultez Uri et les classes associées.

  • Prise en charge des analyses du nom de domaine international (IDN, Internationalized Domain Name). 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 d'IPv6 améliorée. 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 la classe Socket et TcpListener.

Windows Presentation Foundation (WPF)

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

  • Le nouveau contrôle Ribbon, qui vous permet d'implémenter une interface utilisateur de type ruban hébergeant une barre d'outils Accès rapide, un menu d'application et des onglets.

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

  • Nouvelles fonctionnalités des classes VirtualizingPanel et Dispatcher.

  • Performances améliorées lors de l'affichage de grands ensembles de données groupées et lors de l'accès aux collections sur les threads autres que ceux d'interface utilisateur.

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

  • Repositionnement des données au fur et à mesure du changement des valeurs (mise en forme active).

  • 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 pour implémenter des modèles d'événement faible. De plus, les événements peuvent maintenant accepter des extensions de balisage.

Windows Communication Foundation (WCF)

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

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

  • Prise en charge du développement Contrat en premier.

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

  • Modifications des valeurs de propriété de transport par défaut pour réduire la probabilité d'avoir à les définir.

  • Mises à jour de la classe XmlDictionaryReaderQuotas afin de réduire la probabilité d'avoir à configurer manuellement les 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, afin que vous puissiez 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 simplifier l'exposition d'un point de terminaison via HTTPS à l'aide des services Internet (IIS).

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

  • Prise en charge Websockets pour activer une véritable communication bidirectionnelle sur les ports 80 et 443 avec des caractéristiques de performances semblables à celles du 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 une messagerie de type « Fire and Forget » (déclenché et oublié). Un client envoie un message à un service et n'attend aucune réponse de ce dernier.

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

  • Prise en charge des services WCF qui utilisent des noms IDN.

Pour plus d’informations, consultez Nouveautés 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 de la machine à états, qui ont été introduits pour la première fois dans le cadre de .NET Framework 4.0.1 (Mise à jour 1 de la plateforme .NET Framework 4). Cette mise à jour comprenait plusieurs classes et activités nouvelles qui permettaient aux développeurs de créer des flux de travail de machine à états. Ces classes et activités ont été mises à jour pour que .NET Framework 4.5 inclue les fonctionnalités suivantes :

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

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

    • 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, dont notamment :

    • Fonctions 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é de séquence lorsqu'une deuxième activité enfant est ajoutée à une activité de conteneur, et d'inclure les deux activités dans l'activité de séquence.

    • Prise en charge des panoramiques, ce qui permet à la partie visible d'un flux de travail d'être modifiée sans utiliser les barres de défilement.

    • Nouvelle vue Structure du document qui affiche les composants d’un flux de travail en mode Plan sous forme d’arborescence et vous permet de sélectionner un composant dans la vue Structure du 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 pour un flux de travail dans un élément unique du fichier XAML, afin que vous puissiez facilement localiser et modifier les informations sur l'é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 utiliseront les expressions Visual Basic et les projets de flux de travail C# utiliseront les expressions C#.

    • Les projets de flux de travail C# qui ont été créés dans Visual Studio 2010 et qui possèdent 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 :

    • Nouvelle classe WorkflowIdentity, qui fournit un mappage entre une instance de flux de travail rendue 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 une mise à jour dynamique, capacité à modifier la définition d'une instance de flux de travail rendue 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 Windows 8.x Store

Les applications 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 générer des applications Windows 8.x Store pour Windows à l’aide de C# ou de Visual Basic. Ce sous-ensemble s’appelle .NET pour les applications Windows 8.x Store et est décrit dans une vue d’ensemble.

Bibliothèques de classes portables

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

Voir aussi