Cet article a fait l'objet d'une traduction automatique.
ASP.NET 5
Runtime ASP.NET 5 en détail
En novembre dernier, Microsoft a annoncé ASP.NET 5 comme une nouvelle source ouverte et cadre de multi-plateforme pour créer des applications Web et cloud modernes à l'aide de Microsoft .NET Framework. Nous (l'équipe de développement ASP.NET , dont je fais partie) libéré ASP.NET 5 Preview avec aperçu Visual Studio 2015 à la fonction Connect() ; événement à New York. J'ai présenté vous le runtime ASP.NET 5 et son nouveau système de projet de Visual Studio dans l'article « Présentation de l'aperçu ASP.NET 5 » de ces diminutions spéciale. 15, 2014, numéro du MSDN Magazine (bit.ly/1K4PY4U). Étant donné que regarder dernière ASP.NET 5 en décembre, il y a deux plus aperçu communiqués de ASP.NET 5 : Beta2 avec Visual Studio 2015 CTP 5 et Beta3 avec CTP Visual Studio 2015 6. Avec chaque nouvelle version, le cadre continue à évoluer et à améliorer. Dans de nombreux cas, ces améliorations ont été généreusement contribuées par la communauté .NET à travers le projet public de ASP.NET sur GitHub (bit.ly/1DaY7Cd). Dans cet article, je vais jeter un oeil plus profondément sous le capot du nouveau runtime ASP.NET 5 pour voir ce qui a changé dans la version la plus récente.
L'environnement d'exécution de K (KRE)
Comme vous avez vu en décembre, ASP.NET 5 repose sur un hôte du runtime flexible, multi-plateforme qui peut héberger un des plusieurs CLR .NET. Vous pouvez exécuter des applications ASP.NET 5 sur le .NET Framework avec son API complète pour une compatibilité maximale. Vous pouvez également exécuter ASP.NET 5 sur le nouveau Core .NET, ce qui permet des déploiements side-by-side vrais que vous pouvez copier dans les environnements existants sans avoir à changer quoi que ce soit d'autre sur la machine. À l'avenir, vous serez également en mesure d'exécuter ASP.NET 5 multi-plateforme sur base de .NET, et il y a soutien communautaire pour la course multi-plateforme sur Mono aujourd'hui.
L'infrastructure d'hébergement runtime pour ASP.NET 5 est actuellement appelé le K Runtime environnement (KRE), qui est un nom générique espace réservé jusqu'à ce que nous avons finaliser le nom officiel. Le KRE fournit un environnement qui a tout ce qu'il faut exécuter une application .NET : un processus hôte, logique hébergement CLR, géré découverte point entrée et ainsi de suite. Le KRE a été construit pour l'exécution des applications .NET Web multi-plateformes, mais il peut exécuter des autres types d'applications .NET, aussi, comme les applications de console. Le KRE repose sur le même CLR de .NET et les développeurs de la classe de base bibliothèques .NET sont venus à connaître et à aimer, tout en permettant l'utilisation de multi-plateforme pour exécuter des applications .NET sur Windows, OS X et Linux.
Logiquement, le KRE a cinq couches de fonctionnalités. Je vais décrire chacune de ces couches et de leurs responsabilités.
Couche 1. Processus natif : le processus natif est une couche très mince avec la responsabilité de trouver et d'appeler l'hôte CLR natif, passant le long des arguments données au processus à utiliser par le reste de la pile. Sur Windows, c'est un exécutable natif (klr.exe) ; sur Mac ou Linux, c'est un script bash exécutable. S'exécutant sur IIS est accompli avec soit un nouveau module HTTP natif ou en utilisant le chargeur d'Helios. Le chargeur Helios s'appuie sur les crochets de l'extensibilité dans le .NET Framework 4.5.1 pour démarrer la KRE sans nécessiter l'installation de nouveaux modules d'IIS. Avec le module HTTP natif vous pouvez exécuter des applications Web à base de cœur de .NET sur IIS sans aucune dépendance sur le .NET Framework. Alors que le module HTTP natif n'est pas encore accessible au public, nous ne prévoyons pas de le rendre disponible dans un aperçu du futur.
Couches 2 et 3. Hôte CLR natifs et CLR : Les hôtes CLR natifs a trois responsabilités principales :
- Initialiser le Common Language Runtime. Comment cela dépend de la version du CLR. Par exemple, pour démarrer le noyau .NET implique le chargement coreclr.dll, configuration et démarrage du runtime, et créant l'AppDomain que tout le code managé s'exécute. Pour Mono et .NET Framework 4.5.1, le processus varie quelque peu, mais le résultat est le même.
- Appeler le point d'entrée managé, qui est la couche suivante.
- Lorsque le point d'entrée de l'hôte natif retourne, ce processus sera alors propre haut et fermé sur le CLR — c'est-à-dire, décharger le domaine d'application et arrêter l'exécution.
Couche 4 : Point d'entrée managé : Cette couche est la première couche, écrite en code managé. Elle est chargée de :
- Le chargement d'assemblys et de satisfaire les dépendances du dossier lib.
- Mise en place de la IApplicationEnvironment et l'infrastructure d'injection de dépendance base.
- Appeler le point d'entrée principal de l'application spécifiée ou l'application hôte.
Au niveau de cette couche, les assemblys sont chargés uniquement à partir de dossiers lib spécifié ou le chemin de base de demande. C'est la couche suivante qui ajoute des chargeurs supplémentaires pour résoudre les dépendances de paquets NuGet ou le même code compilé en cours d'exécution.
Layer 5: Application/application hôte : Si un développeur compile un ensemble de l'application aux assemblys sur le disque dans le dossier lib, cette couche est la demande — l'application de l'utilisateur final voit. Si vous voulez faire cela, vous pouvez compiler votre application et passez le nom de la DLL contenant un point d'entrée principal standard lors du lancement de couche 1.
Toutefois, dans la plupart des scénarios, vous utiliserez une application hôte pour aider à résoudre les dépendances d'applications et exécuter votre application. Microsoft.Framework.ApplicationHost est l'hôte d'application fourni dans la KRE et ses responsabilités incluent :
- Les dépendances dans la project.json et la mise en place de la fermeture de dépendances de marche l'application utilisera. La dépendance -logique de marche est décrite plus en détail à bit.ly/1y5lZEm.
- Ajout des chargeurs de rassemblement supplémentaire qui peuvent charger des assemblys à partir de diverses sources, telles qu'installé NuGet packages, sources compilés au moment de l'exécution à l'aide de Roslyn et ainsi de suite.
- Appeler le point d'entrée de l'assembly dont le nom a été donné comme argument lors du démarrage du processus natif. L'assembly peut être n'importe quoi avec un point d'entrée que le ApplicationHost sait comment charger. Le ApplicationHost qui vient avec la KRE sait comment trouver une méthode public void de Main. C'est le point d'entrée utilisé pour configurer le ASP.NET hébergement couche, qui sait comment trouver Startup.cs et exécuter la méthode Configure pour votre application Web.
Il faut remarquer que vous souhaitez apprendre sur la KRE, c'est qu'il s'agit d'une partie de bas niveau de la pile. Lorsqu'ils fonctionnent à l'échelle KRE, le monde est encore beaucoup à trouver et le chargement des bibliothèques de liens dynamiques (dll). C'est la KRE qui contient la logique pour vous permettre, au niveau de l'application, pour ne penser qu'à paquets et autres dépendances de niveau supérieur.
Outils multi-plateforme SDK
Le KRE est livré avec un kit de développement logiciel qui contient tout ce dont vous avez besoin pour créer des applications multi-plateformes .NET. Dans mon précédent article sur ASP.NET 5, j'ai décrit comment vous pouvez utiliser l'outil Gestionnaire de Version KRE (KVM) listent les KREs installés sur votre machine, installer de nouveaux et sélectionnez la KRE que vous souhaitez utiliser. Vous pouvez trouver des instructions pour l'installation de la KVM pour votre OS à bit.ly/1y5mqyi.
Le KVM installe KREs d'un NuGet nourrir configurés à l'aide de la variable d'environnement KRE_FEED. Les KREs ne sont pas des paquets NuGet au sens traditionnel qu'ils ne sont pas les paquets dont vous aurait jamais dépendent ; NuGet est simplement un moyen pratique de distribuer et version les KREs. Par défaut, une KRE est installé en copiant et en extrayant le fichier .zip KRE dans % USERPROFILE%\.k\runtimes.
J'ai également déjà introduit l'outil K Gestionnaire de package (KPM) pour l'installation, restauration et création de packages NuGet. Nous prévoyons de l'outil KPM et renommez-le nuget et l'aligner avec le client de NuGet existant. Dans le cadre de cet alignement, certaines commandes secondaires kpm ont déjà été renommés. Maintenant, vous utilisez la commande de bundle pour empaqueter une application pour l'édition et la commande de pack pour la construction et de création de packages NuGet pour un projet. La commande build mise à jour produit des sorties de génération brute sans emballage quoi que ce soit. Il y a aussi une nouvelle commande de pellicule qui permet d'outillage référencer un projet csproj existant dans project.json. Par défaut, les paquets sont maintenant installés dans le dossier %USERPROFILE%\.k\packages, mais vous pouvez contrôler cela en définissant un chemin de paquets dans votre fichier global.json.
Une application de Console multi-plateforme .NET
Je vais maintenant vous montrer comment créer une simple application de console .NET multi-plateforme à l'aide de la KRE. Tout d'abord, je dois créer une DLL avec le point d'entrée et je peux faire que l'utilisation du modèle de projet Application Console ASP.NET 5 en Visual Studio 2015. Le code devrait ressembler à ceci :
public class Program
{
public void Main(string[] args)
{
Console.WriteLine("Hello World");
Console.ReadLine();
}
}
Cela ressemble assez familier, mais notez que le point d'entrée est en fait une méthode d'instance. En plus d'un point d'entrée statique Program.Main, la KRE prend en charge les points d'entrée basée sur l'instance. Vous pouvez même faire de l'entrée principale point asynchrone et retourner une tâche. En faisant le point d'entrée principal à être une méthode d'instance, vous pouvez avoir injecté dans votre application par l'environnement d'exécution de services.
Vous pouvez exécuter cette application de Visual Studio Studio ou sur la ligne de commande en exécutant "k courir" à partir du répertoire contenant le fichier project.json pour l'application. La commande de K est vraiment juste un fichier de commandes simple, et la commande « k courir » peut être étendue dans ce qui suit :
klr.exe --appbase . Microsoft.Framework.ApplicationHost run
La commande K exécute le processus natif (klr.exe), spécifie la base de l'application dans le répertoire courant et puis spécifie l'hôte d'application par défaut. Le processus natif n'a aucune connaissance particulière de l'hôte d'application par défaut — simplement, il cherche un point d'entrée standard dans l'assembly Microsoft.Framework.ApplicationHost et remet en elle.
Si vous ne voulez pas utiliser l'hôte d'application par défaut, vous pouvez appeler la couche native pour appeler directement dans votre application. Pour ce faire, tout d'abord créer le projet pour générer la DLL d'application console. Assurez-vous que vous avez coché l'option « Produits extrants sur la build » dans les propriétés de génération du projet. Vous pouvez trouver la sortie de génération dans le répertoire d'artefacts dans votre dossier de solution. Accédez au répertoire contenant la DLL intégrée pour la saveur KRE vous utilisez et que vous appelez "klr.exe < nom de la DLL >" pour afficher la sortie de l'application console.
Appeler une DLL directement est un moyen très bas niveau et brut d'écrire une application. Vous n'utilisez pas l'hôte d'application par défaut donc vous renoncer project.json appui et soutenir la gestion améliorée axée sur les NuGet dépendance. Au lieu de cela, toutes les bibliothèques que vous dépendez sont simplement chargés des dossiers lib spécifié. Pour le reste de cet article, j'utiliserai l'hôte d'application par défaut.
Vous pouvez utiliser le service IServiceManifest pour énumérer tous les services qui sont disponibles dans l'environnement d'exécution. Vous n'avez pas à spécifier les dépendances supplémentaires pour utiliser cet assembly du tout parce que c'est une Interface de neutre Assemblée (ANI). ANIs sont des types qui sont identifiés uniquement par leur nom et espace de noms et ils sont une caractéristique de la KRE. Deux types de l'assembly neutre assemblys différents mais avec le même nom et espace de noms sont considérés comme équivalents. Cela signifie que les abstractions communes peuvent être simplement déclarées localement au lieu d'avoir à déclarer une dépendance sur un composant commun.
Vous pouvez définir votre propre interface de IServiceManifest Assemblée neutre dans votre application console comme ceci :
namespace Microsoft.Framework.DependencyInjection.ServiceLookup
{
[AssemblyNeutral]
public interface IServiceManifest
{
IEnumerable<Type> Services { get; }
}
}
Mais d'où vient la AssemblyNeutralAttribute ? Eh bien, c'est Assemblée neutre bien sûr ! Si vous la déclarez localement, trop :
namespace Microsoft.Net.Runtime
{
[AssemblyNeutral]
[AttributeUsage(AttributeTargets.All,
Inherited = false, AllowMultiple = true)]
public sealed class AssemblyNeutralAttribute : Attribute
{
}
}
Ces types de l'assembly neutre vont obtenir unifiées en cours d'exécution avec les mêmes types utilisés par le KRE.
Le code dans Figure 1 injecte le service IServiceManifest dans l'application en ajoutant un constructeur à la classe Program et parcourt ensuite les services.
Figure 1 injection de la fonction IServiceManifest dans l'Application
namespace ConsoleApp1
{
public class Program
{
public Program(IServiceManifest serviceManifest)
{
ServiceManifest = serviceManifest;
}
IServiceManifest ServiceManifest { get; }
public void Main(string[] args)
{
foreach (Type type in ServiceManifest.Services)
{
Console.WriteLine(type.FullName);
}
}
}
}
L'application hôte va activer le support de project.json, ajouter des résolveurs d'assemblys supplémentaires (pour traiter les paquets NuGet, les références de projet et les autres) et faire un certain nombre de services supplémentaires disponibles pour l'application avant d'appeler le point d'entrée pour l'application. Lorsque vous exécutez l'application console, la sortie devrait maintenant ressembler à ceci :
Microsoft.Framework.Runtime.IAssemblyLoaderContainer
Microsoft.Framework.Runtime.IAssemblyLoadContextAccessor
Microsoft.Framework.Runtime.IApplicationEnvironment
Microsoft.Framework.Runtime.IFileMonitor
Microsoft.Framework.Runtime.IFileWatcher
Microsoft.Framework.Runtime.ILibraryManager
Microsoft.Framework.Runtime.ICompilerOptionsProvider
Microsoft.Framework.Runtime.IApplicationShutdown
Il y a des services pour regarder des fichiers, traversant la structure des "bibliothèques" (projets, paquets, assemblys de l'application, obtenir les options de compilation utilisées,) et pour fermer l'application. ASP.NET 5 et étant le KRE toujours en avant-première et en cours de développement actif, la liste exacte des services que vous voyez peut-être différer.
Hébergement
ASP.NET hébergement couche s'exécute sur le dessus de la KRE et est responsable de trouver le serveur Web fonctionne sur, trouver la logique de démarrage de l'application, l'application sur le serveur d'hébergement et ensuite nettoyer lorsque l'application est arrêtée. Il fournit également un certain nombre d'autres services d'hébergement liés aux applications.
ASP.NET hébergement DLL (Microsoft.AspNet.Hosting, à bit.ly/1uB6ulW) a une entrée point de méthode qui est appelée par l'hôte d'application KRE. Vous pouvez configurer le serveur Web à utiliser en spécifiant l'option--serveur option de ligne de commande ou autres sources de données de configuration, comme variables d'environnement ou de config.json. La couche d'hébergement puis charge l'Assemblée/type de serveur spécifié pour trouver un IServerFactory qui peut être utilisé pour initialiser et démarrer le serveur. En règle générale, le serveur doit figurer dans vos dépendances à project.json afin qu'il peut être chargé.
Note que les commandes définies dans project.json sont vraiment juste définit des arguments de ligne de commande supplémentaires à klr.exe. Par exemple, le modèle de projet application Web Starter par défaut ASP.NET inclut un tas de commandes dans project.json qui ressemble à ceci :
"commands": {
/* Change the port number when you are self hosting this application */
"web": "Microsoft.AspNet.Hosting
--server Microsoft.AspNet.Server.WebListener
--server.urls http://localhost:5000",
"gen": "Microsoft.Framework.CodeGeneration",
"ef": "EntityFramework.Commands"
},
Donc, si vous deviez exécuter "web k", ce que vous êtes vraiment courir est :
klr.exe --appbase . Microsoft.Framework.ApplicationHost Microsoft.AspNet.Hosting
--server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5000
Démarrage
ASP.NET hébergement couche est également responsable de trouver la logique de démarrage de votre application. En règle générale, votre logique de démarrage d'application est défini dans une classe de démarrage, avec une méthode de configuration pour le paramétrage de votre pipeline de demande et une méthode ConfigureServices permettant de configurer les services nécessaires à votre application, tel qu'indiqué dans Figure 2.
Figure 2 la classe de démarrage
namespace WebApplication1
{
public class Startup
{
public void ConfigureService(IServiceCollection services)
{
// Add services for your application here
}
public void Configure(IApplicationBuilder app)
{
// Configure your application pipeline here
}
}
}
Dans votre méthode de configuration, vous utilisez l'interface IApplicationBuilder pour construire le pipeline de demande pour votre application. Le générateur d'application vous permet de « Utiliser » middleware, de créer des constructeurs application « Nouveau » et de « Construire » un délégué de la demande. Le délégué de la demande est la construction de runtime de noyau dans ASP.NET 5. Un délégué demande prend un HttpContext et fait quelque chose d'utile avec elle de façon asynchrone :
public delegate Task RequestDelegate(HttpContext context);
ASP.NET middleware 5 prend en entrée la prochaine requête déléguer dans le pipeline et fournit un délégué demande avec la logique de middleware. Le délégué demande retournée peut ou ne peut pas appeler le délégué prochain de la demande en cours. Il existe un raccourci pour exécuter la logique de middleware qui n'appelle pas le délégué demande suivant, vous pouvez utiliser la méthode d'extension Run sur IApplicationBuilder :
app.Run(async context => await context.Response.WriteAsync("Hello, world!"));
Ce serait la même que l'écriture le middleware inline suivant où le paramètre suivant est tout simplement ignoré :
app.Use(next => async context =>
await context.Response.WriteAsync("Hello, world!"));
Pour créer le middleware réutilisable, vous pouvez l'écrire comme une classe où, par convention, le délégué demande suivant est injecté dans le constructeur ainsi que tous les services additionnels ou paramètres que le middleware a besoin. Vous implémentez ensuite le délégué de la demande pour le middleware comme une méthode Invoke asynchrone, comme le montre Figure 3.
Figure 3 implémentation de Middleware comme une classe réutilisable
using Microsoft.AspNet.Builder;
using Microsoft.AspNet.Http;
using System.Threading.Tasks;
public class XHttpHeaderOverrideMiddleware
{
private readonly RequestDelegate _next;
public XHttpHeaderOverrideMiddleware(RequestDelegate next)
{
_next = next;
}
public Task Invoke(HttpContext httpContext)
{
var headerValue =
httpContext.Request.Headers["X-HTTP-Method-Override"];
var queryValue =
httpContext.Request.Query["X-HTTP-Method-Override"];
if (!string.IsNullOrEmpty(headerValue))
{
httpContext.Request.Method = headerValue;
}
else if (!string.IsNullOrEmpty(queryValue))
{
httpContext.Request.Method = queryValue;
}
return _next.Invoke(httpContext);
}
}
Vous pouvez utiliser middleware qui suit cette convention à l'aide de la UseMiddleware < T > méthode d'extension sur IApplicationBuilder. Autant d'options que vous passez à cette méthode va obtenir injectées dans le constructeur de middleware après la prochaine demande délégué ainsi que tout service injecté. Par convention, middleware devrait également définir sa propre méthode d'extension utilisation spécifique sur IApplicationBuilder, comme ceci :
public static class BuilderExtensions
{
public static IApplicationBuilder UseXHttpHeaderOverride(
this IApplicationBuilder builder)
{
return builder.UseMiddleware<XHttpHeaderOverrideMiddleware>();
}
}
Vous ajoutez ensuite le middleware pour le pipeline de demande, comme suit :
public class Startup
{
public void Configure(IApplicationBuilder app)
{
app.UseXHttpHeaderOverride();
}
}
ASP.NET 5 est livré avec un ensemble riche de middleware préconstruits. Il y a des intergiciels pour manipuler les fichiers statiques, routage, gestion des erreurs, diagnostics et sécurité. Vous pouvez trouver, télécharger et installer le middleware de Microsoft et la communauté en tant que packages NuGet sur nuget.org.
Configuration des Services
Comme avec tous les autres points d'entrée, vous avez vu dans cette pile, la classe de démarrage peut avoir injecté de la couche d'hébergement dans son constructeur ou en tant que paramètres supplémentaires sur les méthodes de configuration et ConfigureServices de services. Si vous énumérez les services disponibles au démarrage (à l'aide de IServiceManifest), vous voyez il y a maintenant encore plus services disponibles :
Microsoft.Framework.Runtime.IAssemblyLoaderContainer
Microsoft.Framework.Runtime.IAssemblyLoadContextAccessor
Microsoft.Framework.Runtime.IApplicationEnvironment
Microsoft.Framework.Runtime.IFileMonitor
Microsoft.Framework.Runtime.IFileWatcher
Microsoft.Framework.Runtime.ILibraryManager
Microsoft.Framework.Runtime.ICompilerOptionsProvider
Microsoft.Framework.Runtime.IApplicationShutdown
Microsoft.AspNet.Hosting.IHostingEnvironment
Microsoft.Framework.Runtime.IProjectResolver
Microsoft.Framework.Logging.ILoggerFactory
Microsoft.Framework.Runtime.ICache
Microsoft.Framework.Runtime.ICacheContextAccessor
Microsoft.Framework.DependencyInjection.ITypeActivator
Microsoft.Framework.Runtime.IAssemblyLoadContextFactory
Le IHostingEnvironment services vous donne qu'accès à la chemin d'accès de la racine Web pour votre application (généralement votre dossier www) et aussi une abstraction IFileProvider pour votre racine Web. Le IProjectrésolveur peut être utilisé pour trouver d'autres projets dans votre solution. Il y a exploitation forestière et la mise en cache des services et un activateur de type qui est orientée sur l'injection de dépendance. Le IAssemblyLoadContextFactory vous donne une abstraction permettant de créer de nouveaux contextes de chargement d'assembly.
Vous configurez les services existants et ajoutez de nouveaux pour votre application dans la méthode ConfigureServices dans votre classe de démarrage. La méthode ConfigureServices prend une IServiceCollection auquel vous pouvez ajouter des services supplémentaires ou modifier celles qui existent déjà. ASP.NET 5 est livré avec un conteneur IoC intégré simple qui est mis en place dans la couche de Point d'entrée managé afin d'amorcer le système, mais vous pouvez facilement remplacer le conteneur intégré avec votre conteneur de choix.
Les cadres offrent généralement une méthode d'extension Add pour ajouter leurs services à la IServiceCollection. Par exemple, voici comment ajouter les services utilisés par ASP.NET MVC 6 :
public void ConfigureServices(IServiceCollection services)
{
// Add MVC services to the services container
services.AddMvc();
}
Lorsque vous ajoutez des services à la collection de service, il peuvent s'agir de trois types : transitoire, étendue ou singleton. Services transitoires sont créés chaque fois qu'ils sont demandés dans le conteneur. Étendue de services sont créées que si elles n'existent pas déjà dans la portée actuelle. Pour les applications Web, une étendue de conteneur est créée pour chaque demande, donc vous pouvez penser à services étendues selon la demande. Services Singleton sont créés uniquement une fois.
Web.config et fichiers app.config System.Configuration-style ne sont pas pris en charge dans ASP.NET 5. Au lieu de cela, ASP.NET 5 est livré avec une API de Configuration nouvelle, simplifié (Microsoft.Framework.ConfigurationModel, à bit.ly/1yxC7gA) pour travailler avec des données de configuration. La nouvelle API de Configuration vous permet de récupérer et de manipuler les données de configuration d'une variété de sources. Fournisseurs de configuration par défaut sont fournis pour INI, JSON, XML, variables d'environnement et des paramètres de ligne de commande. Vous pouvez spécifier plusieurs fournisseurs et ils sont utilisés dans l'ordre de leur ajout. Par la prise en charge de configuration basé sur l'environnement, vous pouvez plus facilement déployer une application dans un environnement et l'ai ramasser les paramètres appropriés pour cet environnement.
Pour initialiser les données de configuration, ajoutez vos fournisseurs de configuration souhaitée à une nouvelle instance de la Configuration :
public Startup(IHostingEnvironment env)
{
Configuration = new Configuration()
.AddJsonFile("config.json")
.AddEnvironmentVariables();
}
Vous pouvez ensuite demander des valeurs de configuration par nom :
string user = Configuration.Get("user");
string password = Configuration.Get("password");
Vous pouvez rendre les données de configuration disponibles d'une manière fortement typée tout au long de votre application en utilisant le modèle d'options. Les options sont juste des classes c# objet POCO (Plain Old) qui ont un tas de propriétés utilisé pour la configuration. Vous faire des options disponibles dans votre application en appelant AjouterOptions, qui ajoute les IOptions < TOption > service au conteneur. Ce service peut être utilisé pour accéder aux options de types différents là où l'injection de dépendance est pris en charge.
Pour configurer les options, vous ajoutez IConfigureOptions < TOptions > services au conteneur. L'implémentation par défaut des IOptions < TOption > service va ramasser tous le IConfigureOptions < TOption > services et les utiliser pour configurer l'instance options avant de faire l'instance options disponibles aux consommateurs. Il existe un raccourci pour ajouter la logique de configuration options, vous pouvez utiliser la configuration < TOption > méthode, comme suit :
services.Configure<MvcOptions>(options => options.Filters.Add(
new MyGlobalFilter()));
Le modèle d'options et le modèle de configuration travaillent main -dans la main. Vous pouvez facilement lier les données de configuration à options, correspondant par le nom de la propriété en utilisant les surcharges de configurer qui prennent une instance de Configuration, comme cela :
services.Configure<MyOptions>(Configuration);
Traitement de la demande
Une fois le serveur Web est démarré, il commence écoute les demandes et en invoquant le pipeline de demande avec chaque demande. Les surfaces de serveur, chaque demandent comme un objet d'environnement de serveur qui expose un ensemble d'interfaces de fonctionnalité à grain fin. Il y a des interfaces de fonctionnalité pour l'envoi de fichiers, Web sockets, support de session, les certificats clients et plus. Vous pouvez voir la liste complète des interfaces de fonctionnalité pris en charge sur GitHub à bit.ly/1Dh7eBC. Par exemple, voici l'interface de fonctionnalité pour la requête HTTP :
[AssemblyNeutral]
public interface IHttpRequestFeature
{
string Protocol { get; set; }
string Scheme { get; set; }
string Method { get; set; }
string PathBase { get; set; }
string Path { get; set; }
string QueryString { get; set; }
IDictionary<string, string[]> Headers { get; set; }
Stream Body { get; set; }
}
Vous ne codez généralement directement contre les différentes fonctionnalité intervisages. Serveurs Web utilisent des interfaces de fonctionnalité pour exposer des fonctionnalités de bas niveau de la couche hôte. La couche d'hébergement encapsule ces interfaces de fonctionnalité dans un HttpContext fortement typée qui est ensuite transmis à l'application. Ce niveau de couplage lâche entre le serveur Web, la couche d'hébergement et des applications permet aux serveurs d'être mis en œuvre et réutilisés sans être lié à un modèle d'hébergement spécifique, et il permet aux applications d'être hébergé sur des serveurs différents. ASP.NET 5 est livré avec un support intégré pour s'exécutant sur IIS (Microsoft.AspNet.Server.IIS), directement sur un mince HTTP.Wrapper SYS (Microsoft.AspNet.Server.Webécouteur) et sur un nouveau serveur de Web multi-plateforme .NET appelé Kestrel (Microsoft.AspNet.Server.Kestrel).
L'Interface Web ouverte pour la communauté .NET (OWIN) standard (owin.org) partage des buts semblables, couplage faible pour les applications Web. OWIN standardise comment les applications et serveurs .NET doivent parler les uns aux autres. Prend en charge les 5 ASP.NET OWIN via le package Microsoft.AspNet.Owin (bit.ly/15IQwA5). Vous pouvez héberger ASP.NET 5 sur un serveur Web OWIN (bit.ly/1DaU4FZ), et vous pouvez utiliser OWIN middleware dans le pipeline ASP.NET 5 (bit.ly/1EqmoIB).
Le projet de Katana (katanaproject.codeplex.com) était l'effort initial de Microsoft d'implémenter un support pour OWIN, et bon nombre des idées et des concepts dans ASP.NET 5 étaient issues. Katana avait un modèle similaire pour construire un pipeline de middleware et d'hébergement sur plusieurs serveurs. Cependant, contrairement à Katana, qui exposés les abstractions OWIN bas niveau directement au développeur, ASP.NET 5 plutôt ponts de OWIN à des abstractions plus pratiques et plus conviviales. Avec un peu de code supplémentaire, vous pouvez toujours utiliser Katana middleware dans ASP.NET 5 en utilisant le pont OWIN (voir un exemple de comment faire cela à bit.ly/1BpaXe2).
Récapitulation
Le runtime ASP.NET 5 a été construit dès le départ pour la prise en charge des applications Web multi-plateforme. ASP.NET 5 a une architecture en couches souple qui s'exécutent sur le .NET Framework, .NET Core ou même multi-plateforme sur Mono (et à l'avenir sur base de .NET ainsi!). Le nouveau modèle d'hébergement ASP.NET 5 le rend facile de composer des applications et l'héberger sur le serveur Web de votre choix. Le runtime entier est construit pour soutenir l'injection de dépendance et d'être facile à configurer. J'espère que vous avez aimé apprendre la nouvelle ASP.NET runtime 5 ! Vos commentaires et vos contributions sont les bienvenus dans notre projet GitHub à github.com/aspnet/home.
Daniel Roth est responsable de programme senior dans l'équipe ASP.NET travaille actuellement sur ASP.NET 5. Ses passions sont les clients de développement et de ravir .NET en faisant des cadres simples et faciles à utiliser.
Remercie les experts techniques Microsoft suivants pour avoir relu cet article : Glenn Condron, David Fowler, Murat Girgin et Chris Ross