2017-10-04

Septembre 2017

Volume 32, numéro 9

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

ASP .NET Core - Prise en main d’ASP.NET Core 2.0

Par Mike Rousos | Septembre 2017

ASP.NET Core rend faciles à créer des applications Web rapides, portables et multiplateforme. Cet article vous guide dans le développement d’un site ASP.NET Core Web simple et affichera le rôle de chaque fichier dans le projet s’exécute. Elle traite également des concepts importants ASP.NET Core tout au long du processus. Il y aura une attention particulière sur les modifications apportées dans ASP.NET Core 2.0 pour aider les lecteurs familiarisés avec ASP.NET Core 1.0 et 1.1 effectuer la transition vers la version 2.0.

Création d’un projet ASP.NET Core

Les projets ASP.NET Core peuvent être créés à partir de modèles à l’aide de Visual Studio ou le .NET Core interface de ligne (.NET). Visual Studio 2017 donne une grande expérience de développement .NET Core, avec le débogage de premier ordre, l’intégration de Docker et bien d’autres fonctionnalités, mais je vais utiliser la CLI de .NET et Visual Studio Code dans cette procédure pas à pas, au cas où certains d'entre vous souhaitez suivre la procédure sur un développement Mac ou Linux ordinateur.

La commande nouvelle dotnet est utilisée pour créer des projets .NET Core. En cours d’exécution dotnet nouveau sans arguments supplémentaires répertorie les modèles de projet disponibles, comme indiqué dans Figure 1. Si vous êtes familiarisé avec les versions précédentes de l’interface CLI .NET, vous remarquerez un nombre de nouveaux modèles disponibles dans la version 2.0.

nouveaux .NET Core modèles de projet

Figure 1 nouveaux .NET Core modèles de projet

Angulaire et React.js SPA modèles : Ces modèles créent une application ASP.NET Core qui fait Office d’une application de page unique (à l’aide de 4 angulaire ou React.js) son front-end. Les modèles incluent à la fois les applications front-end et back-end, ainsi qu’une configuration Webpack pour générer le serveur frontal (et les modifications csproj pour déclencher le Webpack générer chaque fois que la génération du projet ASP.NET Core).

Application Web ASP.NET Core Pages Razor : Pages Razor est une nouvelle fonctionnalité d’ASP.NET 2.0 de base qui vous permet de créer des pages qui gèrent les demandes directement (sans avoir besoin d’un contrôleur). Il s’agit d’une option intéressante pour les scénarios qui répondent à un modèle de programmation basé sur la page.

Pour cette procédure pas à pas, nous pouvons commencer avec le nouveau modèle de Pages Razor en exécutant razor de nouveau dotnet. Dès que le projet a été créé, vous devez être en mesure de l’exécuter en exécutant dotnet exécuter. Dans les versions précédentes du .NET Core, il serait avez été nécessaire pour exécuter la restauration dotnet tout d’abord pour installer les packages NuGet. Mais à partir de .NET Core 2.0, la commande restore est désormais exécuter automatiquement les commandes CLI qui en dépendent. Continuez et tester le site Web de modèle arrière en exécutant dotnet exécuter et en accédant à l’URL sur laquelle l’application est à l’écoute (probablement http://localhost : 5000). Vous devez voir l’application Web rendue (comme dans Figure 2).

Simple ASP.NET Core application en cours d’exécution

Figure 2 Simple ASP.NET Core application en cours d’exécution

Félicitations pour le lancement de votre première application ASP.NET Core 2.0 ! Maintenant que vous avez une application Web simple en cours d’exécution, examinons le contenu du projet pour obtenir une meilleure compréhension du fonctionnement de ASP.NET Core.

Dépendances, des Sources et des ressources

Le premier fichier à examiner est le fichier projet, le fichier .csproj. Ce fichier indique comment générer le projet à MSBuild, les packages il dépend, quelle version de .NET Core cible, et ainsi de suite. Si vous avez consulté les fichiers .csproj dans le passé, vous remarquerez que ce fichier projet est beaucoup plus petit. Une grande quantité de travail a été mis à rendre les fichiers .csproj plus courtes et plus lisible. Un changement notable peut permettre de réduire le fichier projet est cette source de fichiers n’ont plus besoin être répertorié explicitement. Au lieu de cela, le Kit de développement .NET Core compilera automatiquement tous les fichiers .cs en regard du fichier projet ou dans les répertoires sous le répertoire de la .csproj. De même, tous les fichiers .resx sont incorporés comme ressources. Si vous préférez ne pas avoir tous ces fichiers .cs compilés, vous pouvez les supprimer de l’élément ItemGroup compiler ou désactiver des éléments de compilation par défaut entièrement en définissant la propriété EnableDefaultCompileItems sur false.

L’application à exécuter par rapport à la version du .NET est spécifiée par l’élément < TargetFramework >. Cela est défini sur netcoreapp2.0 pour tirer parti des nouvelles fonctionnalités d’ASP.NET 2.0 de base et la quantité supérieure .NET Core 2.0 surface d’exposition.

L’élément < PackageReference > au milieu du fichier .csproj indique un package NuGet dont dépend le projet. Vous remarquerez dans ASP.NET Core 2.0 maintenant inclure des seul métadonnées--package par défaut (Microsoft.AspNetCore.All). Ce package inclut tous les autres packages Microsoft.AspNetCore dans une seule référence concise et rend les fichiers de projet ASP.NET Core 2.0 beaucoup plus petite que les fichiers projet des versions précédentes. Dépendances de NuGet supplémentaires peuvent être ajoutés en ajoutant plusieurs éléments < PackageReference >, à l’aide de l’interface utilisateur de gestion de NuGet Package de Visual Studio, ou avec l’infrastructure du langage commun .NET dotnet ajouter la commande.

Si vous utilisez un modèle SPA (angulaire, réagissent ou reactredux), il serait également cibles personnalisées définies dans le fichier .csproj pour vous assurer que Webpack a été exécuté lors de la génération du projet.

Création et exécution de l’hôte Web

Program.cs représente le point d’entrée de l’application. Applications ASP.NET Core sont des applications console, comme toutes les applications de la console, ils ont une méthode Main qui démarre lorsque l’application s’exécute.

Le contenu des méthodes de principal de ces modèles ASP.NET Core 2.0 est assez simple, créer un objet IWebHost et les appeler exécuter sur celui-ci.

Si vous avez utilisé précédemment ASP.NET Core 1.0, vous remarquerez que ce fichier est un peu plus simple que le fichier program.cs à partir de ces modèles plus anciens. La raison est la nouvelle méthode WebHost.CreateDefaultBuilder. Auparavant, la méthode Main de l’application ASP.NET Core configurez un WebHostBuilder afin de créer l’instance IWebHost. Cette configuration inclure les étapes telles que la spécification d’un serveur Web, le chemin d’accès racine du contenu et activer l’intégration des services Internet.

La nouvelle méthode CreateDefaultBuilder simplifie les choses en créant un IWebHost prêt-à-go avec la configuration la plus courante est déjà faite. En plus de spécifier les éléments répertoriés précédemment, CreateDefaultBuilder se charge aussi de certains le programme d’installation qui a été traité précédemment dans Startup.cs (définition des informations de configuration et l’enregistrement des fournisseurs de journalisation par défaut). Étant donné que ASP.NET Core est open source, vous pouvez voir tous les détails de ce que fait CreateDefaultBuilder en affichant sa source sur GitHub (bit.ly/2uR1Dar) si vous voulez intéressez.

Brièvement Examinons les plus importantes pour les appels effectués dans CreateDefaultBuilder et leur effet. Ils sont tous effectués pour vous (par CreateDefaultBuilder), mais il est toujours en bon état de comprendre ce qui se passe en arrière-plan.

UseKestrel Spécifie que votre application doit utiliser Kestrel, un serveur Web inter-plateformes libuv. L’autre option ici serait d’utiliser des HttpSys que le serveur Web (UseHttpSys). HttpSys est pris en charge uniquement sur Windows (Windows 7/2008 R2 et versions ultérieures), mais présente les avantages de ce qui permet l’authentification Windows et qui est sécurisée pour s’exécuter directement exposés à Internet (Kestrel, quant à eux, doit-elle se situent derrière un proxy inverse, comme IIS, Nginx ou Apache Si elle recevra des demandes à partir d’Internet).

UseContentRoot Spécifie le répertoire racine de l’application où ASP.NET Core pourra trouver le contenu à l’échelle du site tels que les fichiers de configuration. Notez que cela n’est pas identique à la racine Web (où les fichiers statiques seront traitées par), bien que par défaut, le site Web racine est basée sur la racine du contenu ([ContentRoot] / wwwroot).

ConfigureAppConfiguration crée l’objet de configuration de que l’application utilisera pour lire des paramètres au moment de l’exécution. Lorsqu’elle est appelée à partir de CreateDefaultBuilder, cela lisent les paramètres de configuration d’application de fichier appsettings.json, un fichier spécifique à l’environnement .json (le cas échéant), les variables d’environnement et les arguments de ligne de commande. Si, dans un environnement de développement, il utilise également des secrets de l’utilisateur. Cette méthode est nouvelle dans ASP.NET 2.0 de noyaux et je vais l’étudier plus en détail ultérieurement.

ConfigureLogging définit la journalisation de l’application. Lorsqu’elle est appelée à partir de CreateDefaultBuilder, console et les fournisseurs de journalisation de débogage sont ajoutés. Comme ConfigureAppConfiguration, cette méthode est nouvelle et sujet est abordée plus ultérieurement.

UseIISIntegration configure l’application s’exécute dans IIS. Notez que UseKestrel est toujours nécessaire. IIS joue le rôle de proxy inverse et Kestrel est toujours utilisé en tant que l’ordinateur hôte. En outre, UseIISIntegration n’aura aucun effet si l’application n’est pas en cours d’exécution derrière IIS, il est possible d’appeler la même si l’application est exécutée dans les scénarios non-IIS.

Dans de nombreux cas, la configuration par défaut fournie par CreateDefaultBuilder seront suffisante. Au-delà, tout ce qui est nécessaire que l’appel est pour spécifier la classe de démarrage pour votre application avec un appel à UseStartup < T >, où T est le type de démarrage.

Si CreateDefaultBuilder ne répond pas aux besoins de votre scénario, vous pouvez continuer à personnaliser la façon dont le IWebHost est en cours de création. Si vous devez apporter de petits ajustements uniquement, vous pouvez appeler CreateDefaultBuilder et ensuite modifier le WebHostBuilder est retourné (par exemple, en appelant ConfigureAppConfiguration, par exemple, pour ajouter d’autres sources de configuration). Si vous avez besoin d’apporter des modifications plus grandes à la IWebHost, vous pouvez ignorer CreateDefaultBuilder appelant complètement et simplement construire un WebHostBuilder vous-même, comme vous disposez avec ASP.NET Core 1.0 ou 1.1. Même si vous choisissez cette méthode, vous pouvez toujours tirer parti des nouvelles méthodes ConfigureAppConfiguration et ConfigureLogging. Plus d’informations sur la configuration de l’hôte Web sont disponibles sur bit.ly/2uuSwwM.

Environnements de ASP.NET Core

Quelques actions CreateDefaultBuilder prend dépendent de l’environnement dans lequel votre application est en cours d’exécution de ASP.NET Core. Le concept d’environnements n’est pas nouveau dans la version 2.0, mais il est important de revoir brièvement les parce qu’il provient souvent.

Dans ASP.NET Core, l’environnement de qu'exécution d’une application est indiqué par la variable d’environnement ASPNETCORE_ENVIRONMENT. Vous pouvez le définir à toute valeur que vous le souhaitez, mais les valeurs de développement, intermédiaire et Production sont généralement utilisées. Par conséquent, si vous définissez la variable ASPNETCORE_ENVIRONMENT au développement avant d’appeler dotnet exécuter (ou si vous définissez cette variable d’environnement dans un fichier launchSettings.json), votre application s’exécutera en mode de développement (au lieu de Production, qui est la valeur par défaut sans aucun les variables définies). Cette valeur est utilisée par plusieurs fonctionnalités ASP.NET Core (je vais faire référence pour aborder la Configuration et de journalisation, plus loin) pour modifier le comportement d’exécution et sont accessibles dans votre propre code à l’aide du service IHostingEnvironment. Plus d’informations sur les environnements de ASP.NET Core est disponible dans la documentation d’ASP.NET Core (bit.ly/2eICDMF).

Configuration d’ASP.NET Core

ASP.NET Core utilise l’interface de IConfiguration du package Microsoft.Extensions.Configuration de fournir des paramètres de configuration de runtime. Comme mentionné précédemment, CreateDefaultBuilder lisent les paramètres de variables d’environnement et les fichiers .json. Le système de configuration est extensible, bien qu’et peut lire les informations de configuration à partir d’une large gamme de fournisseurs (fichiers .json, les fichiers .xml, fichiers .ini, variables d’environnement, Azure Key Vault et ainsi de suite).

Lorsque vous travaillez avec des objets IConfiguration et IConfigurationBuilder, n’oubliez pas que l’ordre que les fournisseurs sont ajoutés est important. Ultérieures fournisseurs peuvent remplacer les paramètres de fournisseurs précédents, afin que vous souhaitez ajouter des fournisseurs de base communes tout d’abord, puis, ultérieurement, les fournisseurs spécifiques à l’environnement qui peuvent se substituer à certains paramètres.

Paramètres de configuration dans ASP.NET Core sont hiérarchiques. Dans le nouveau projet créé, par exemple, appsettings.json (consultez Figure 3) contient un élément de journalisation de niveau supérieur avec sous paramètres situés sous celui-ci. Ces paramètres indiquent la priorité minimale de messages à enregistrer (via les paramètres « LogLevel ») et indique si l’étendue de logique de l’application à la fois que le message est enregistré doit être enregistré (via IncludeScopes). Pour récupérer les paramètres imbriquées comme celles-ci, vous pouvez utiliser la méthode IConfiguration.GetSection pour récupérer une section de la configuration ou de spécifier le chemin d’accès complet d’un paramètre particulier, délimité par des deux-points. Par conséquent, la valeur de IncludeScopes dans le projet peut être récupérée sous forme :

Figure 3 fichier des paramètres ASP.NET Core

{
  "Logging": {
    "IncludeScopes": false,
    "Debug": {
      "LogLevel": {
        "Default": "Warning"
      }
    },
    "Console": {
      "LogLevel": {
        "Default": "Warning"
      }
    }
  }
}

Configuration["Logging:IncludeScopes"]

Lorsque vous définissez les paramètres de configuration avec les variables d’environnement, le nom de variable d’environnement doit inclure tous les niveaux de la hiérarchie et permettre être délimité par un signe deux-points ( :) ou un double trait de soulignement (_). Par exemple, une variable d’environnement appelée Logging__IncludeScopes remplace le paramètre IncludeScopes de l’exemple de fichier dans Figure 3, en supposant que le fournisseur de variables d’environnement est ajouté après le fichier de paramètres, tels que Il est dans le cas de CreateDefaultBuilder.

Étant donné que WebHost.CreateDefaultBuilder est lecture de la configuration à partir de fichiers spécifiques à l’environnement .json et appsettings.json, vous remarquerez que les changements de comportement de journalisation lorsque vous modifiez des environnements (appsettings. Development.JSON remplace les paramètres de LogLevel du appsettings.json la valeur par défaut avec des niveaux plus détaillés de « debug » et « informations »). Si vous définissez l’environnement de développement avant d’appeler dotnet exécuter, vous devez remarquer une quantité raisonnable de journalisation qui passe à la console (qui est très pratique, car il est utile pour le débogage). En revanche, si vous définissez l’environnement de Production, vous n’aurez aucun journal de console à l’exception des erreurs et des avertissements (qui est également très pratique car l’enregistrement de la console est lente et doit être conservé au minimum en production).

Si vous avez une expérience avec ASP.NET Core 1.0 et 1.1, vous remarquerez que la méthode ConfigureAppConfiguration est nouveau pour la version 2.0. Auparavant, il était courant de créer une IConfiguration dans le cadre de la création du type de démarrage. À l’aide de la nouvelle méthode ConfigureAppConfiguration constitue une alternative utile, car elle met à jour l’objet IConfiguration stockée dans le conteneur d’injection (DI) de l’application pour une récupération ultérieure facile et rend les paramètres de configuration disponibles même plus haut dans la durée de vie de votre application.

Enregistrement d’ASP.NET Core

Comme avec le programme d’installation de configuration, si vous êtes familiarisé avec les versions antérieures d’ASP.NET Core vous pourrez vous rappeler journalisation de l’installation en cours d’exécution dans Startup.cs au lieu de dans le fichier Program.cs. Dans ASP.NET 2.0 de base, le programme d’installation de journalisation maintenant faire lors de la création d’un IWebHost via la méthode ConfigureLogging.

Il est toujours possible de configurer l’enregistrement de démarrage (à l’aide des services. Add-Logging dans Startup.ConfigureServices), mais par la configuration de la journalisation lors de la création de l’hôte Web, le type de démarrage est rationalisé et la journalisation est disponible même dans le processus de démarrage d’application.

Également comme configuration, ASP.NET Core journalisation est extensible. Fournisseurs différents sont inscrits pour vous connecter à différents points de terminaison. De nombreux fournisseurs sont disponibles immédiatement avec une référence à Microsoft.AspNetCore.All et même plus sont disponibles à partir de la Communauté de développeurs .NET.

Comme indiqué dans le code source de WebHost.CreateDefaultBuilder, vous pouvez ajouter des fournisseurs de journalisation en appelant des méthodes d’extension de fournisseur spécifique comme AddDebug ou AddConsole sur ILoggingBuilder. Si vous utilisez WebHost.CreateDefaultBuilder mais que vous souhaitez inscrire des fournisseurs autres que par défaut débogage et celles de Console de journalisation, il est possible de le faire avec un appel supplémentaire à ConfigureLogging sur le IWebHostBuilder retourné par CreateDefaultBuilder

Une fois la journalisation a été configurée et les fournisseurs inscrits, ASP.NET Core enregistrera automatiquement les messages concernant son travail pour traiter les demandes entrantes. Vous pouvez également enregistrer vos propres messages de diagnostic en demandant un objet ILogger via l’injection de dépendances (plus d’informations dans la section suivante). Les appels à ILogger.Log et variantes de niveau spécifique (comme LogCritical, LogInformation et ainsi de suite) sont utilisés pour enregistrer les messages.

Le Type de démarrage

Maintenant que vous avez étudié Program.cs pour savoir comment l’hôte Web est créé, nous allons accédez à Startup.cs. Le type de démarrage que votre application doit utiliser est indiqué par l’appel à UseStartup lors de la création de la IWebHost. Pas a beaucoup modifiée dans Startup.cs dans ASP.NET Core 2.0 (à l’exception qu’elle devienne la plus simple, car la journalisation et configuration sont définies dans le fichier Program.cs), mais je vais examiner brièvement les deux méthodes d’importantes du type de démarrage, car elles sont un rôle central dans une application ASP.NET Core.

La méthode du type du démarrage de l’Injection de dépendance ConfigureServices ajoute des services au conteneur d’injection de dépendance de l’application. Toutes les applications ASP.NET Core ont un conteneur d’injection de dépendance par défaut pour stocker les services pour une utilisation ultérieure. Cela permet aux services à disposition sans couplage étroit des composants qui en dépendent. Vous avez déjà vu quelques exemples : ConfigureAppConfiguration et ConfigureLogging ajoutera des services vers le conteneur pour une utilisation ultérieure dans votre application. Au moment de l’exécution, si une instance d’un type est appelée, ASP.NET Core récupère automatiquement l’objet dans le conteneur d’injection de dépendance si possible.

Par exemple, la classe de démarrage de votre projet ASP.NET Core 2.0 a un constructeur qui accepte un paramètre IConfiguration. Ce constructeur est appelé automatiquement, lorsque votre IWebHost commence à s’exécuter. Lorsque cela se produit, ASP.NET Core fournira l’argument IConfiguration requis à partir du conteneur d’injection de dépendance.

Autre exemple, si vous souhaitez enregistrer les messages à partir d’une Page Razor, vous pouvez demander un objet de l’enregistreur d’événements en tant que paramètre au constructeur du modèle de page (par exemple, la façon dont le démarrage demande un objet IConfiguration) ou dans cshtml avec le @ injecter la syntaxe, comme indiqué ci-dessous :

@using Microsoft.Extensions.Logging
@inject ILogger<Index_Page> logger

@functions {
  public void OnGet()
    {
      logger.LogInformation("Beginning GET");
    }
}

Quelque chose de similaire peut être fait pour récupérer un objet IConfiguration ou tout autre type qui a été inscrit en tant que service. De cette façon, le type de démarrage, les Pages Razor, contrôleurs, etc., peut dépendre faiblement services fournis dans le conteneur d’injection de dépendance.

Comme mentionné au début de cette section, les services sont ajoutés pour le conteneur d’injection de dépendance dans la méthode Startup.ConfigureServices. Le modèle de projet que vous avez utilisé pour créer votre application a déjà a un seul appel de ConfigureServices : services. AddMvc. En effet, les services requis par l’infrastructure MVC est inscrit.

Un autre type de service qui est courant de voir inscrit dans la méthode ConfigureServices est Entity Framework Core. Bien qu’il n’est pas utilisé dans cet exemple, les applications qui utilisent généralement Entity Framework Core inscrire le DbContexts besoin pour travailler avec les modèles Entity Framework à l’aide des appels aux services. AddDbContext.

Vous pouvez également enregistrer vos propres types et les services ici en appelant des services. AddTransient, services. AddScoped ou services. AddSingleton (en fonction de la durée de vie requise pour les objets fournis par l’injection de dépendance). L’inscription en tant que singleton entraîne une seule instance du service qui est renvoyé à chaque fois que son type est demandé, alors que l’enregistrement temporaire entraîne une nouvelle instance à créer pour chaque demande. L’ajout de comme portée entraîne une seule instance d’un service à utiliser dans le traitement d’une requête HTTP. Plus d’informations sur l’injection de dépendances dans ASP.NET Core sont disponibles à bit.ly/2w7XtJI.

Pipeline de traitement des demandes HTTP et d’intergiciel (middleware) l’autre méthode importante dans le type de démarrage est la méthode de configuration. C’est là le cœur de l’application ASP.NET Core, son pipeline de traitement des demandes HTTP — est configuré. Dans cette méthode, les différents éléments d’un intergiciel (middleware) sont inscrits que sera act sur HTTP entrant demande pour générer des réponses.

Dans Startup.Configure, les composants d’intergiciel (middleware) sont ajoutés à un IApplicationBuilder pour former le pipeline de traitement. Lorsqu’une demande arrive, la première partie de l’intergiciel (middleware) enregistré est appelée. Cet intergiciel (middleware) effectue la logique, il lui faut puis appeler la partie suivante de l’intergiciel (middleware) dans le pipeline ou, si elle a traité complètement la réponse, revenir à l’élément précédent de l’intergiciel (middleware) (s’il a été précédemment) afin qu’il peut exécuter une la logique nécessaire après qu’une réponse a été préparée. Ce modèle de l’appel de composants d’intergiciel (middleware) dans l’ordre lorsqu’une demande arrive et ensuite dans l’ordre inverse après qu’il a été gérée est illustrée dans Figure 4.

Pipeline de traitement de la figure 4 ASP.NET Core intergiciel (middleware)

Pipeline de traitement de la figure 4 ASP.NET Core intergiciel (middleware)

Pour prendre un exemple concret, Figure 5 affiche la méthode de configuration à partir du projet de modèle. Lorsqu’une nouvelle demande arrive, elle passe tout d’abord à l’intergiciel (middleware) DeveloperExceptionPage ou de l’intergiciel (middleware) ExceptionHandler, selon votre environnement (comme précédemment, il est configuré avec la variable d’environnement ASPNETCORE_ENVIRONMENT). Ces composants d’intergiciel (middleware) ne sont pas agir quantité initialement, mais après l’intergiciel (middleware) suivant a été exécuté et que la demande a été envoyé hors de l’intergiciel (middleware) de pipeline, ils surveiller et gérer les exceptions.

Figure 5 ASP.NET Core Startup.Configure méthode configure le Pipeline de l’intergiciel (middleware)

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
  if (env.IsDevelopment())
  {
    app.UseDeveloperExceptionPage();
  }
  else
  {
    app.UseExceptionHandler("/Error");
  }

  app.UseStaticFiles();

  app.UseMvc(routes =>
  {
    routes.MapRoute(
      name: "default",
      template: "{controller=Home}/{action=Index}/{id?}");
  });
}

Ensuite, StaticFiles intergiciel (middleware) est appelé, ce qui peut répondre à la requête en fournissant un fichier statique (une image ou le style de feuille, par exemple). Dans ce cas, il arrêtera le pipeline et retourner le contrôle à l’intergiciel (middleware) précédent (les gestionnaires d’exceptions). Si l’intergiciel (middleware) StaticFiles ne peut pas fournir une réponse, il appelle la partie suivante de l’intergiciel (middleware), l’intergiciel (middleware) MVC. Cet intergiciel (middleware) tente de router la demande à un contrôleur MVC (ou une Page de Razor) pour l’exécution, en fonction des options de routage spécifié.

L’ordre que les composants d’intergiciel (middleware) sont inscrits est très important. Si UseStaticFiles est fourni après UseMvc, l’application serait tente de router toutes les demandes pour les contrôleurs MVC avant de rechercher des fichiers statiques. Que peut dégrader le résultat dans une performance notable ! Si l’intergiciel (middleware) de gestion des exceptions est fourni plus loin dans le pipeline, il serait en mesure de gérer les exceptions qui se produisent dans les composants d’intergiciel (middleware) précédente.

Pages Razor

Outre les .csproj, program.cs et les fichiers startup.cs, votre projet ASP.NET Core contient également un dossier de Pages contenant des Pages de l’application Razor. Les pages sont similaires aux vues MVC, mais les demandes peuvent être acheminés directement vers une Page Razor sans recourir à un contrôleur distinct. Cela rend possible de simplifier les applications basées sur la page et conserver les vues et afficher les modèles. Le modèle de prise en charge de la page peut être inclus dans la page cshtml directement (dans une directive @functions), ou dans un fichier de code distinct, qui est référencé avec la directive @model.

Pour en savoir plus sur les Pages Razor, consultez l’article de Steve Smith, « Plus simple MVC applications avec Razor Pages ASP.NET, » également dans ce problème.

Pour résumer

Nous espérons que cette procédure pas à pas explique comment créer une nouvelle application Web ASP.NET Core 2.0 et démystifie le contenu des nouveaux modèles de projet. J’ai révisé le contenu du projet à partir du fichier .csproj simplifiée, pour le point d’entrée application et la configuration de l’hôte Web dans le fichier Program.cs, à l’inscription de service et d’intergiciel (middleware) dans Startup.cs.

Pour conserver les examiner plus en détail ce qui est possible avec ASP.NET Core, il peut être utile de créer certains des projets à l’aide de certains des autres modèles, comme le modèle de l’API Web ou peut-être que certains des nouveaux modèles SPA. Vous pouvez souhaiter également essayer le déploiement de votre application ASP.NET Core dans Azure en tant qu’une application de Service d’applications Web ou l’emballage de l’application comme une image Linux ou Windows Docker. Et, bien entendu, veuillez consulter la documentation complète sur docs.microsoft.com/aspnet/core pour plus d’informations sur les rubriques abordées dans cet article et bien plus encore.

Mike Rousos est un ingénieur principal de l’équipe de réussite du client .NET. Rousos est un membre de l’équipe .NET depuis 2004, vous travaillez sur des technologies, notamment la sécurité de traçage, managée, d’hébergement et plus récemment, .NET Core.

Grâce aux experts techniques Microsoft suivants ayant révisé cet article : Glenn Condron et Ryan Nowak

Discussion sur cet article sur le forum MSDN Magazine

Partager via