• Article

Août 2018

Volume 33, numéro 8

Cet article a fait l'objet d'une traduction automatique.

ASP.NET Core - quelles sont les nouveautés dans ASP.NET Core 2.1

Par Steve Smith

Microsoft a récemment publié ASP.NET Core 2.1 avec .NET Core 2.1 et Entity Framework (EF) Core 2.1. Combinés, ces versions offrent certaines améliorations de performances, ainsi que des fonctionnalités supplémentaires pour les développeurs .NET Core. Microsoft propose également de Long-Term prise en charge (LTS) avec cette version, ce qui signifie qu’il restera pris en charge pour les trois ans. Cet article fournit une vue d’ensemble des améliorations dans ASP.NET Core 2.1. Pour en savoir plus sur les nouveautés dans EF Core 2.1, l’extraction des Points de données de mois-ci ce par Julie Lerman, « Deep Dive dans EF Core HasData amorçage » et son article du mois dernier (msdn.com/magazine/mt847184) qui se plonge dans le nouveau EF Core 2.1 fonctionnalité de Type, ce qui vous permet plus facilement interroger une base de données sans avoir besoin d’entités trues avec les propriétés de clé pour utiliser les résultats de requête.

Améliorations des Pages Razor

Je vais commencer par parler des améliorations aux Pages Razor, une nouvelle fonctionnalité introduite dans ASP.NET Core 2.0, j’ai abordé dans le numéro de septembre 2017 (msdn.com/magazine/mt842512). Version 2.1 ajoute quelques fonctionnalités qui n’a pas dans la version 2.0, telles que la prise en charge pour les dossiers des Pages spécifiques rechercher des ressources partagées. Les actifs partagés courants sont les vues partielles et les fichiers de disposition. Par défaut, ils se trouvaient dans le dossier racine /Pages ASP.NET Core 2.0, bien que ASP.NET Core MVC serait les découvrir s’ils ont été placés dans un dossier /Views/Shared. Dans la version 2.1, les Pages Razor recherche maintenant ces fichiers partagés en recherchant les dans les emplacements suivants (dans l’ordre) :

  1. Le dossier de Pages actuel
  2. / Pages/Shared
  3. / Vues/Shared

Vous pouvez ainsi facilement substituer les actifs partagés où vous le souhaitez, mais si vous ajoutez les Pages Razor à une application existante basée sur MVC, vous pouvez continuer à tirer parti des ressources partagées existants dans son dossier /Views/Shared.

Une autre fonctionnalité qui était manquante lors de l’expédition initialement les Pages Razor a été prise en charge des zones. Avec ASP.NET Core 2.1, vous pouvez maintenant ajouter un dossier /Pages avec les Pages Razor pour toute zone située dans le dossier /Areas de votre application ASP.NET Core. Microsoft a également mis à jour le modèle d’Application Web de Visual Studio par défaut pour utiliser des zones pour les fonctionnalités d’identité lorsque vous choisissez « comptes d’utilisateur individuels ».

Ensemble, ces fonctionnalités rendent beaucoup plus facile organiser les Pages Razor dans le système de projet.

Bibliothèques partagées Razor

Une autre nouvelle fonctionnalité dans 2.1 est prise en charge pour le chargement des ressources de Razor à partir des packages ou des bibliothèques distinctes. Séparer les applications ASP.NET Core souvent partagent des ressources communes, telles que des fonctionnalités d’identité (connexion, Registre, oublié le mot de passe, etc.). En règle générale, ces fonctionnalités communes a entraîné un grand nombre de doublons de code des projets individuels, ce qui conduit à la dette technique accrue. La nouvelle bibliothèque de classes Razor (RCL) fonctionnalité prend en charge les fichiers Razor de création et de les déployer en tant que projets associés ou les packages NuGet que n’importe quel nombre d’applications ASP.NET Core peut consommer.

Avec l’ajout de cette fonctionnalité, le compilateur générera actifs Razor, recherche automatiquement pour les ressources associées dans les bibliothèques référencées et les packages. Auparavant, les ressources de Razor n’ont pas été générés jusqu'à une fois qu’ils ont été déployés et demandés. ASP.NET Core 2.1 intègre compilation Razor dans le processus de génération, ce qui entraîne également les heures de début application plus rapides.

Ressources de Razor dans RCLs peuvent être remplacées, pour éviter de perdre la possibilité de personnaliser certains aspects sur une base par projet si vous les utilisez pour partager des ressources communes entre des projets. RCLs briller pour les application problèmes transversaux comme la disposition, la navigation et l’authentification. En fait, la fonctionnalité intégrée de ASP.NET Core Identity est en mesure de tirer parti de cette prise en charge pour devenir plus facilement réutilisable entre des projets, ainsi.

Mises à jour du modèle de projet

Le modèle de projet d’Application Web par défaut inclut quelques changements pas précédemment mentionnés. La boîte de dialogue Nouveau projet inclut désormais une case à cocher pour spécifier s’il faut appliquer le protocole HTTPS. Nouvelle prise en charge pour général règlement de Protection des données (RGPD) étant inclus par défaut, les projets incluent désormais les pages de confidentialité par défaut et des vues partielles Razor de consentement de cookie. Notez que ces documents sont simplement des espaces réservés, il vous incombe à ajouter la stratégie réelle de votre organisation. Figure 1 montre un tout nouveau projet ASP.NET Core 2.1, qui a été configuré pour utiliser l’identité pour les comptes d’utilisateur individuels.

Nouvelle Structure de projet d’Application Web dans ASP.NET Core 2.1
Figure 1 nouvelle Structure de projet Web Application dans ASP.NET Core 2.1

Identité sous la forme d’un module complémentaire

Si vous souhaitez tirer parti des fonctionnalités ASP.NET Core Identity dans votre application avant la version 2.1, vous deviez généralement prendre la décision pour ajouter la prise en charge lors de la création de votre projet d’application Web. Si vous souhaitez ajouter ultérieurement de prise en charge de l’identité, généralement le processus consisterait à créer un tout nouveau projet d’application Web avec la prise en charge appropriée (par exemple, « comptes d’utilisateur individuels »), puis copiez les fichiers à partir de la nouvelle application dans votre application existante. Cela n’était pas une solution idéale.

Il a toujours été un sérieux défi technique pour ASP.NET Core (et ASP.NET, trop) pour prendre en charge de prise en charge des identités ajout à une application existante, en partie parce que cette prise en charge inclus des ressources frontales de Razor qui n’a pas pu être empaquetées séparément et à déployer de nouvelles ressources dans un une application existante peut échouer pour un ordinateur hôte de raisons. Avec l’ajout de prise en charge RCL, ajout de Qu'identité à une application existante devient beaucoup plus facile que le processus n’est plus doit ajouter les nouveaux fichiers Razor à l’application existante.

Vous pouvez utiliser la prise en charge de la génération de modèles automatique dans Visual Studio pour ajouter l’identité pour les applications existantes. Nouvelles applications générées avec les derniers modèles seront appuieront sur les actifs partagés Razor plutôt que notamment liées à l’identité pages/affichages dans le projet lui-même. L’avantage de cette approche est moins de fichiers de code réutilisable dans vos nouveaux projets, mais sans perte de fonctionnalité ou de votre capacité à personnaliser le comportement. Vous l’avez vu dans Figure 1 que par défaut prise en charge de l’identité uniquement ajoute une zone avec un fichier unique _ViewStart.cshtml qu’il contient. Vous pouvez personnaliser le comportement de certains fichiers en cliquant sur le projet, en cliquant sur Ajouter | Nouvel élément structuré, puis en choisissant identité. Sélectionnez les pages que vous souhaitez générer automatiquement des modèles et de spécifier la classe DbContext et autres options.

Vous verrez comment je vais personnaliser ces fichiers quand pourrais-je prendre SignalR.

Prise en charge améliorée de HTTPS

Si vous n’utilisez pas déjà HTTPS pour vos applications Web, vous devez sans doute. Moteurs de recherche et les navigateurs sont maintenant activement promotion de sites qui utilisent le protocole HTTPS et ceux qui ne traitant comme potentiellement non sécurisées. RGPD exige que les sites utilisent HTTPS pour protéger la confidentialité des utilisateurs. ASP.NET Core 2.1 vient renforcer la prise en charge pour développer et tester des applications à l’aide de HTTPS, y compris faire beaucoup plus facile à utiliser HTTPS localement lors de la création d’applications.

Après avoir installé le SDK .NET Core 2.1, la première fois que vous l’exécutez, il installera un certificat de développement. Vous pouvez gérer ce certificat en utilisant le nouvel outil dev-certs dotnet, qui est installé avec le Kit de développement. Une fois que le certificat de développement est approuvé, vous serez en mesure de développer et tester vos applications ASP.NET Core 2.1 localement à l’aide de HTTPS comme protocole par défaut, mise en miroir plus près de votre environnement de production (où évidemment vous utilisez HTTPS).

Votre application peut améliorer sa sécurité en signalant aux navigateurs qu’il prend en charge HTTP Strict Transport Security (HSTS). HSTS vous aide à empêcher certains types d’attaques, telles que les attaques de « l’homme au milieu », en signalant aux navigateurs que toutes les réponses pour une demande donnée doivent utiliser des connexions HTTPS au lieu de HTTP brut. Sans HSTS, même une page qui est pris en charge par le biais de HTTPS peut inclure des ressources qui utilisent toujours HTTP. Ces ressources peuvent être facilement remplacées ou modifiées par les routeurs entre l’utilisateur et les serveurs qui hébergent le contenu, car ils sont non protégés par chiffrement. HSTS empêche ce vecteur d’attaque.

HSTS est implémentée avec un en-tête de réponse dans la réponse HTTPS de la ressource d’origine. Par exemple :

Strict-Transport-Security: max-age=16070400; includeSubDomains

HSTS est activée pour vos applications ASP.NET Core à l’aide d’intergiciel (middleware), configuré par défaut dans le fichier de Startup.cs du modèle d’application. Il n’est pas recommandé d’utiliser HSTS sur localhost, donc le comportement par défaut inclut uniquement l’intergiciel (middleware) lorsque le projet est en cours d’exécution dans un environnement de production.

En plus de HSTS, vous pouvez également exiger HTTPS pour votre application à l’aide de l’intergiciel (middleware) UseHttpsRedirection nouveau. La plus simple, vous activez cela en ajoutant la ligne suivante à votre méthode Configure dans Startup.cs :

App.UseHttpsRedirection();

Microsoft recommande cela pour toutes les applications ASP.NET Core, et il est la valeur par défaut dans les modèles d’application Web. Cet intergiciel (middleware) redirige automatiquement les demandes qui aboutissent sur HTTP vers HTTPS. Elle utilise des conventions pour découvrir le port HTTPS approprié, en supposant qu’un seul est utilisé par l’application. Alternativement, vous pouvez configurer en définissant la variable d’environnement ASPNETCORE_HTTPS_PORT (ou une clé de configuration http_port) ou en spécifiant des options dans le code dans ConfigureServices :

services.AddHttpsRedirection(options => options.HttpsPort = 5555);

Modèles de mise à jour

Les modèles d’application pour les Applications à Page unique (SPA) ont été mis à jour pour utiliser les dernière version approches recommandées pour les applications Angular et React. Plus précisément, le modèle Angular est désormais basé sur l’interface de ligne de commande Angular (CLI), et les modèles de React reposent sur react créer application (ARC). Ces frameworks SPA expédier les mises à jour fréquemment, afin de la mise à jour des modèles intégrés à l’une des approches plus récente permet de garantir nouvelles applications générées avec les utilisera les bonnes pratiques en vigueur pour chaque framework associé.

SignalR

SignalR est une bibliothèque populaire qui le rend très simple d’ajouter des fonctionnalités Web en temps réel aux applications ASP.NET. ASP.NET Core SignalR est une nouvelle version de SignalR qui est fourni avec ASP.NET Core 2.1. Il comprend un certain nombre d’améliorations par rapport aux versions précédentes :

  • Ne dépend pas côté client jQuery
  • Protocole binaire MessagePack
  • En fonction de Microsoft.AspNetCore.Sockets (pas Http)
  • Prend en charge plusieurs formats (de même point de terminaison)

Les composants côté serveur de SignalR sont inclus dans le package NuGet de Microsoft.AspNetCore.SignalR. Ce package est inclus dans le métapackage Microsoft.AspNetCore.App, généralement ne devrait pas être nécessaire ajouter séparément à votre projet ASP.NET Core (en supposant que vous référencez Microsoft.AspNetCore.App version 2.1 ou ultérieure). SignalR prend en charge plusieurs clients, notamment JavaScript des pages Web et un client .NET pour les applications .NET. La méthode recommandée pour ajouter le client JavaScript à votre projet est via npm. En supposant que vous avez installé de npm, vous pouvez exécuter les commandes suivantes pour ajouter le client à votre projet :

npm init –y
npm install @aspnet/signalr

La première commande Initialise un fichier packages.config pour votre projet, vous devez uniquement exécuter cette commande si vous n’utilisez pas déjà de npm. La deuxième commande télécharge le client SignalR JavaScript dans votre dossier node_modules. Vous devrez copier le fichier signalr.js node_modules vers un emplacement approprié dans le dossier de wwwroot de votre application ASP.NET Core afin de faire référence à partir de votre application.

Démonstration de SignalR : Notifications toast

Pour montrer combien il est facile à configurer avec SignalR, tout en montrant également comment personnaliser le comportement du nouveau package d’identité, j’ai créé une démonstration simple. Il s’affiche une notification dans le navigateur chaque fois qu’un utilisateur inscrit ou qu’il se connecte dans ou hors de l’application. Cette notification doit apparaître n’importe où sur le site, je vais modifier le fichier _Layout.cshtml pour inclure les scripts côté client nécessaires. Ajoutez le code suivant au bas du fichier _Layout.cshtml :

<script src="//cdnjs.cloudflare.com/ajax/libs/toastr.js/latest/js/
  toastr.min.js"></script>
<script src="~/lib/signalr/signalr.js"></script>
<script src="~/js/site.js" asp-append-version="true"></script>

La première référence est dans une bibliothèque de notification simple appelée toastr que je vais utiliser pour afficher les notifications. Le second est le fichier signalr.js copié à partir de node_modules dans le dossier de l’application wwwroot/lib/signalr. La dernière est le fichier site.js existant qui est créé dans le cadre d’un nouveau projet ASP.NET Core. L’ordre de ces scripts est important.

L’étape suivante consiste à modifier les site.js pour ajouter le code JavaScript nécessaire pour afficher les messages lorsqu’une demande est reçue à partir du serveur. Il existe trois étapes impliquées dans ce processus. Tout d’abord, une connexion doit être créée, à l’aide de la signalR.HubConnectionBuilder. Ce type utilise le modèle de conception du Générateur de rapports pour configurer la connexion avec tous les paramètres nécessaires, et puis la connexion est retournée à partir de la méthode de génération. Ensuite, configurez les gestionnaires de messages à l’aide de la méthode .sur sur la connexion. Créez un gestionnaire nommé pour chaque comportement que vous souhaitez que le serveur pour être en mesure d’établir. Enfin, vous lancez la connexion en appelant sa méthode de démarrage :

const userUpdatesConnection = new signalR.HubConnectionBuilder()
  .withUrl("/userUpdates")
  .build();
userUpdatesConnection.on("ReceiveSignIn", (user) => {
  toastr.options.escapeHtml = true;
  const message = user + " logged in.";
  toastr.info(message, "New Login!");
});
// Additional handlers omitted
userUpdatesConnection.start().catch(err => console.error(err.toString()));

Ce code s’exécutera sur chaque page qui utilise _Layout.cshtml. Maintenant je configure l’extrémité du serveur de la connexion, en commençant dans Startup.cs. Vous devez modifier la méthode ConfigureServices pour inclure de SignalR (généralement après l’appel de services. AddMvc) :

services.AddSignalR();

Ensuite, dans la méthode Configure, vous devez configurer les itinéraires SignalR, juste avant d’appeler l’application. UseMvc :

app.UseSignalR(routes =>
{
  routes.MapHub<UsersHub>("/userUpdates");
});
app.UseMvc();

Il est maintenant temps d’ajouter la classe UsersHub que j’ai mentionnée précédemment. Vous pouvez placer cette classe dans un dossier de Hubs, qui est une approche courante, ou vous pouvez considérer sur l’utilisation de plus d’une approche de dossier de fonctionnalités, comme j’ai décrit dans mon article de septembre 2016, « Fonctionnalité tranches pour ASP.NET Core MVC » (msdn.com/magazine/mt763233) et placer le Hub avec les Pages/contrôleurs avec lequel il fonctionne. Dans tous les cas, pour ce scénario, étant donné que le client n’est pas effectuer des appels au concentrateur, la classe n’a pas besoin n’importe quelle implémentation réelle. Il a juste besoin d’hériter de Microsoft.AspNetCore.SignalR.Hub :

public class UsersHub : Hub
{
}

Enfin, à utiliser le Hub pour communiquer avec des clients connectés depuis un autre emplacement dans l’application, vous utilisez l’injection de dépendances pour injecter IHubContext < THub > à la classe qui en a besoin. Dans ce cas, les classes de PageModel pour Login, Logout and Register chaque ont une instance de IHubContext < UsersHub > injecté dans leurs constructeurs.

Pour envoyer un message, utilisez l’instance HubContext pour accéder à sa propriété Clients et envoyer un message à un gestionnaire nommé particulier. Figure 2 illustre l’implémentation de la méthode Logout PageModel OnPost.

Figure 2 implémentation de la méthode de OnPost PageModel déconnexion

public async Task<IActionResult> OnPost(string returnUrl = null)
{
  string username = User.Identity.Name;
  await _signInManager.SignOutAsync();
  _logger.LogInformation("User logged out.");
  await _usersHubContext.Clients.All.SendAsync("ReceiveSignOut", username);
  if (returnUrl != null)
  {
    return LocalRedirect(returnUrl);
  }
  else
  {
    return Page();
  }
}

Avec ces éléments en place, vous pouvez exécuter l’application et ouvrir des différents navigateurs pour afficher l’application. Dans un, inscrire et connecter entrant et sortant de l’application. Vous devez voir apparaître dans les autres navigateurs des notifications. La moitié gauche de Figure 3 affiche une notification apparaissant dans un navigateur Chrome, une fois un utilisateur connecté vers et depuis un navigateur Microsoft Edge sur la droite.

ASP.NET Core SignalR envoi de Notifications à partir du serveur pour les navigateurs connectés
Figure 3 ASP.NET Core SignalR envoi de Notifications à partir du serveur pour les navigateurs connectés

Améliorations de Test d’intégration

ASP.NET Core a eu une aide appréciable pour les tests de la pile complet en mémoire depuis 1.0 d’intégration. Toutefois, une chose nécessitant une installation personnalisée pour atteindre a été configuration le TestServer avec le chemin d’accès racine de contenu approprié, afin qu’il pu localiser correctement les ressources telles que des vues au sein de l’application Web. ASP.NET Core 2.1 introduit un nouveau type, WebApplicationFactory < T >, ce qui le rend plus facile de créer un TestServer et un objet HttpClient qui s’y connecte. Pour utiliser la fabrique au sein d’une classe de test Xunit, vous implémentez l’interface IClassFixture < WebApplicationFactory < démarrage >>, où le démarrage est le point d’entrée pour l’application ASP.NET Core que vous souhaitez tester. Puis, dans le constructeur de classe, vous allez injecter un WebApplicationFactory < démarrage > et utiliser sa méthode createclient utile pour obtenir une instance d’un client. Dans vos tests, vous pouvez ensuite utiliser le client pour effectuer des requêtes à l’application et vérifiez que la réponse correcte est renvoyée, comme suit :

[Fact]
public async Task Get_HomePageReturnSuccessAndCorrectContentType()
{
  var response = await _client.GetAsync("/");
  response.EnsureSuccessStatusCode(); // Status Code 200-299
  Assert.Equal("text/html; charset=utf-8",
    response.Content.Headers.ContentType.ToString());
}

Si vous avez besoin personnaliser l’application pour le test, telles que la modification à laquelle les services sont utilisés ou ajout de données d’amorçage qui seront utilisées pour le test, vous pouvez hériter WebApplicationFactory < T > et ensuite utiliser votre fabrique personnalisée dans vos tests.

Autres améliorations

Cette version voit également les améliorations apportées à plusieurs autres parties d’ASP.NET Core 2.1, y compris le serveur Kestrel intégré. Kestrel utilise désormais les sockets gérés pour sa couche de transport par défaut, au lieu de libuv. Cette modification doit être transparente, mais si elle provoque des problèmes, les développeurs peuvent configurer toujours de libuv pour une utilisation avec Kestrel.

Une autre nouveauté pour le composant d’hébergement d’ASP.NET Core est celui du type HostBuilder, que vous utilisez pour configurer les parties non Web d’un ordinateur hôte. HostBuilder est très similaire au WebHostBuilder existant, mais ne vous permet de spécifier une classe de démarrage à partir d’un projet Web. Il est conçu pour vous permettre de configurer les préoccupations communes telles que l’injection de dépendances, configuration et la journalisation pour les scénarios non Web tels que les services hébergés ou les applications console.

Enfin, si vous écrivez des points de terminaison API dans votre application ASP.NET Core, vous pouvez tirer parti de certaines améliorations ajoutées dans 2.1. Tout d’abord, vous pouvez ajouter l’attribut [ApiController] à un de vos contrôleurs qui exposent des API. Cela ajoute un certain nombre de fonctionnalités aux points de terminaison définis sur ces contrôleurs, tels que :

  • Erreurs de validation de modèle retourne automatiquement BadRequest(ModelState)
  • Sources de liaison (par exemple, [FromBody]) automatiquement déduits pour les paramètres d’action
  • Chargements de fichiers à l’aide de [FromForm] automatiquement déduisent le type de contenu multipart/form-data
  • Routage par attributs est requis

Un autre ajout est un nouveau type de retour, ActionResult < T >. Ce type de retour est utilisé à la place de IActionResult et permet des informations de type à inclure dans la signature de méthode. Outils tels que Swashbuckle peuvent utiliser ces informations pour générer la documentation de OpenAPI/Swagger. Sans ce type de retour, vous devez annoter des méthodes qui simplement retourné IActionResult avec l’attribut [ProducesResponseType] pour exposer ces informations.

Étapes suivantes

Si vous n’utilisez pas déjà ASP.NET Core 2.1, je vous recommande la mise à niveau dès que possible. Vous pouvez obtenir le SDK à microsoft.com/net/download/windows ou exécuter les outils à l’aide de Docker à partir d’une des images à dockr.ly/2MAaiEF. Le code source mis à jour pour cet exemple est disponible à l’adresse bit.ly/2JXdHeV.

Steve Smithest consultant, mentor et formateur indépendant. À l’adresse ardalis.com et fournit des conseils de développement par courrier électronique et de podcast à WeeklyDevTips.com. Consultez son cours sur Pluralsight pour apprendre à développer plus propre, applications de meilleure qualité. Vous pouvez le suivre sur Twitter : @ardalis.

Discuter de cet article sur le forum MSDN Magazine