翻訳者からの紹介
この記事は
、ASP.NET 5-ASP.NET 5ランタイムの詳細-DNXアーキテクチャとその上に構築されたASP.NET 5の概要です。元の記事は2015年3月にASPの時代に書かれたものです。 NET 5はまだ活発に開発されており（およそベータ3）、その多くは時代遅れでした。 したがって、すべての情報を翻訳してASP.NET 5（RC1）の現在のバージョンに更新すると、関連リソース（主にdocs.asp.net）およびGitHubのソースコードへのリンクも追加されました（実装に興味がある場合のみ参照） ） 素敵なダイビングを！
.NETランタイム環境（DNX）
ASP.NET 5は、さまざまな.NET CLR（.NET Core CLR、Mono CLR、.NET Framework CLR）で動作できる柔軟なクロスプラットフォームランタイムに基づいています。 完全な.NET Frameworkを使用してASP.NET 5を実行するか、新しい
.NET Core docsの使用を開始できます。これにより、必要なすべてのライブラリをアプリケーションと共に既存の環境にコピーできます。 .NET Coreを使用すると、
Linux ドキュメントおよび
Mac OS ドキュメントで ASP.NET 5クロスプラットフォームを実行することもできます。
ASP.NET 5アプリケーションを実行および実行できるインフラストラクチャは、
.NETランタイム環境 ドキュメント、または略してDNXと呼ばれ
ます 。 DNXは、ホストプロセス、CLRホスティングロジック、管理対象エントリポイントの検出など、.NETアプリケーションの実行に必要なすべてを提供します。
論理的に、DNXアーキテクチャには5つの層があります。 これらの各レイヤーとその責任について説明します。
DNX構造 wiki記事からの画像
レイヤー1：ネイティブプロセス
ネイティブプロセス（オペレーティングシステムプロセスを意味します）は、ネイティブCLRホストを見つけて呼び出す義務があり、プロセス自体に渡された引数を渡します。 Windowsでは、これはdnx.exeです（％YOUR_PROFILE％/。Dnx / runtimes /％CHOOSEN_RUNTIME％にあります）。 MacおよびLinuxでは、これは実行可能なbashスクリプト（dnxとも呼ばれます）です。
IIS ドキュメントでの 起動は、IISにインストールされているネイティブHTTPモジュールである
HTTPPlatformHandler （最終的にはdnx.exeも実行します）を使用して行われます。 HTTPPlatformHandlerを使用すると、.NET Frameworkに依存せずにIIS上でWebアプリケーションを実行できます（当然、完全な.NET Frameworkではなく.NET Coreを対象とするWebアプリケーションを起動する場合）。
注：DNXアプリケーション（ASP.NET 5コンソールとWebアプリケーションの両方）は、このネイティブプロセスのアドレス空間で実行されます。 これからは、「ネイティブプロセス」の下で、dnx.exeと他のオペレーティングシステムの類似物を意味します。
レイヤー2および3：ネイティブCLRホストおよびCLR
彼らには3つの主な責任があります。
- CLRを実行します。 これを実現する方法は、使用するCLRのバージョンによって異なりますが、結果は1つになります。
- CLRで4番目のレイヤーコード（エントリポイント管理）の実行を開始します。
- ネイティブCLRホストが制御を返すと、「それ自体をクリーンアップ」し、CLRをオフにします。
レイヤー4：エントリポイント管理
注：一般に、このレイヤーのロジックはMicrosoft.DNX.Host githubアセンブリ内にあります 。 このレイヤーのエントリポイントは、 RuntimeBootstrapper githubと見なすことができます。
これは、DNXアプリケーションの作業がマネージコードの実行に進む最初の層です（そのため）。 彼は責任があります：
- ILoadersのコンテナーであるLoaderContainer github を作成します。 ILoaderは、アセンブリの読み込みを担当します。 CLRがLoaderContainerにアセンブリの提供を要求すると、ILRを使用してこれを行います。
- 選択したdnxランタイムのbinフォルダーから必要なアセンブリをロードするルート github ILoaderの作成 ：％YOUR_PROFILE％/。Dnx / runtimes /％CHOOSEN_RUNTIME％/ bin /および
--libパラメーターを使用してネイティブプロセスの開始時に提供される追加のパス： dnx --lib <LIB_PATHS> ）。 - github IApplicationEnvironmentおよびDependency Injectionシステムのコアインフラストラクチャを構成します。
- アプリケーションの起動時にネイティブプロセスに渡されるパラメーターに応じて、特定のアプリケーションのエントリポイント githubまたはMicrosoft.DNX.ApplicationHost github の呼び出し 。
レイヤー5：アプリケーションホスト
Microsoft.DNX.ApplicationHost githubは、DNXに付属のアプリケーションホストです。 彼の責任は次のとおりです。
- インストールされたNuGetパッケージやRoslynを使用してランタイムにコンパイルされたソースなど、さまざまなソースからアセンブリをロードできるgitCon追加アセンブリローダー（ILoaders）をLoaderContainerに追加します。
- project.jsonで指定された依存関係を表示してダウンロードします。 依存関係トラバーサルロジックについては、 Dependency-Resolution wikiで詳しく説明されています 。
- コンソールアプリケーションの場合はアセンブリのエントリポイント githubを 呼び出し 、Webアプリケーションの場合はエントリポイントMicrosoft.AspNet.Hosting githubを呼び出します。 アセンブリは、ApplicationHost が github を呼び出す方法を知っているエントリポイントを持つものであれば何でもかまいません。 DNX ApplicationHostを使用すると、 github
public static void Mainメソッドを見つける方法がわかります 。
クロスプラットフォームSDKツール
DNXには、クロスプラットフォームの.NETアプリケーションの構築に必要なすべてを含むSDKが付属しています。
DNVM -DNXバージョンマネージャー wiki 。 コンピューターにインストールされているDNXを表示し、新しいものをインストールして、使用するものを選択できます。
ドキュメントを インストールしたら、コマンドラインからDNVMを使用できます。dnvmと入力するだけ
dnvm 。
DNVMは、DNX_FEED環境変数を使用するように構成されたNuGetフィードからDNXを設定します。 DNXは、伝統的な意味でのNuGetパッケージではありません。依存関係として参照できるパッケージです。 NuGetは、DNXを提供およびバージョン管理する便利な方法です。 デフォルトでは、DNXは、アーカイブをDNXから「％USERPROFILE％/。Dnx」にコピーおよびアンパックすることにより設定されます。
DNU -DNXユーティリティ wiki 。 NuGetパッケージをインストール、復元、作成するツール。 デフォルトでは、パッケージは「％USERPROFILE％/。Dnx / packages」にインストールされますが、global.jsonファイルに別のパスを設定することでこれを変更できます（プロジェクトのSolution Itemsフォルダーにあります）。
DNUを使用するには、コマンドプロンプトで
dnuと入力します。
.NETのクロスプラットフォームコンソールアプリケーション
次に、DNXを使用してシンプルなクロスプラットフォームの.NETコンソールアプリケーションを作成する方法を示します。
エントリポイントでDLLを作成する必要があり、Visual Studio 2015の「コンソールアプリケーション（パッケージ）」テンプレートを使用してこれを行うことができます。
アプリケーションのコード：
namespace ConsoleApp { public class Program { public static void Main(string[] args) { Console.WriteLine("Hello World"); Console.ReadLine(); } } }
コードは、通常のコンソールアプリケーションとまったく同じに見えます。
このアプリケーションは、Visual Studioまたはコマンドラインから起動できます。コマンドラインで
dnx runと入力し、起動するアプリケーションのproject.jsonファイル（プロジェクトルート）が含まれるフォルダーに移動します。
dnx runは単なる省略形であり、ネイティブプロセスは実際にコマンドに展開します。
dnx.exe --appbase . Microsoft.DNX.ApplicationHost run
パターンに一致するもの：
dnx.exe --appbase < > <, entry point> <, >
展開されたコマンドを分析しましょう：
dnx.exeはネイティブプロセスです。--appbase . -起動したプロジェクトのフォルダーへのパスを指定します。 値は「 . 」です-現在のディレクトリを示します。Microsoft.DNX.ApplicationHostエントリポイントを持つアセンブリ。 デフォルトでは、Microsoft.DNX.ApplicationHostが使用されます。4番目のレイヤー（4番目のレイヤー：マネージエントリポイント、 4番目の責任 ）を引き起こすのは彼のエントリポイントです。 4番目の層には、Microsoft.DNX.ApplicationHostに関する特別な知識はありません。 彼は単に提供されたアセンブリのエントリポイントを探して呼び出し、パラメーターを渡します（この例では、「 run 」がパラメーターとして渡されます）。runエントリポイントを持つアセンブリに渡されるパラメーター。 Microsoft.DNX.ApplicationHostは、 runを--appbaseパラメーターで指定されたパスでプロジェクトのエントリポイントを見つけて呼び出すように指示するコマンドとしてrunを解釈しrun 。 runコマンドの代わりに、エントリポイントでアセンブリの名前を渡すことができ、ApplicationHostはそれを呼び出します。 以下のWebアプリケーションホスティングセクションでは、この例を見ていきます。
ApplicationHostを使用しない場合。 アプリケーションに直接渡すことで、ネイティブ層を呼び出すことができます。 これを行うには：
- アプリケーションのビルドを実行してDLLを生成します（プロジェクトのプロパティの[ビルド]セクションにある[ビルド時に出力を生成する]チェックボックスをオンにします）。 ソリューションフォルダーのルートにあるアーティファクトディレクトリで結果を見つけることができます（プロジェクトのproject.jsonファイルを含むフォルダーに入力することで、
dnu buildではなくdnu build使用することもできます）。 - コマンド
dnx <_______>ます。
DLLを直接呼び出すことは、アプリケーションを作成するためのかなり低レベルのアプローチです。 Microsoft.DNX.ApplicationHostを使用しないため、project.jsonファイルと改良されたNuGetベースの依存関係管理メカニズムの使用を拒否します。 代わりに、依存するライブラリは、
--libパラメーターを使用してネイティブプロセスを開始するときに指定されたディレクトリからロードされます。 この記事の最後まで、Microsoft.DNX.ApplicationHostを使用します。
Microsoft.DNX.ApplicationHost-DNXの最後の層であり、それより上位のすべてはASP.NET 5と見なすことができます。
ASP.NET 5
Webアプリケーションホスティング
ASP.NET 5 Webアプリケーションでは、
ドキュメント ホスティングレイヤーはMicrosoft.DNX.ApplicationHostの上で実行されます。 これは、
Microsoft.AspNet.Hosting githubアセンブリによって表され
ます 。 この層は、Webサーバーを見つけ、その上でWebアプリケーションを起動し、Webアプリケーションのシャットダウン中に「自身をクリーニング」します。 また
、 github アプリに追加のレイヤー関連のホスティングサービスを提供します。
Webアプリケーションを起動するには、Microsoft.DNX.ApplicationHostが
エントリポイント github メソッド Microsoft.AspNet.Hostingを呼び出す必要があります。
ホスティングで使用されるWebサーバーは、
--serverオプションを指定するか、hosting.jsonファイルや環境変数などの他のホスティング設定方法を使用して選択できます。 ホスティングレイヤーは、選択したWebサーバーをロードして起動します。 ダウンロードできるように、よく使用されるWebサーバーは、project.jsonファイルの依存関係リストにリストする必要があります。
通常、コマンドラインからWebアプリケーションを起動するには、
dnx webコマンドを使用します。
ASP.NET 5 Webアプリケーションテンプレートには、project.jsonファイルで定義された一連
の docs コマンドが含まれており、
webコマンドはそれらの1つです。
"commands": { "web": "Microsoft.AspNet.Server.Kestrel", "ef": "EntityFramework.Commands" },
実際、コマンドは
dnx.exe追加の引数を設定するだけで、
dnx webと入力してWebアプリケーションを起動すると、実際には次のように変換されます。
dnx.exe --appbase . Microsoft.DNX.ApplicationHost Microsoft.AspNet.Server.Kestrel
次に、
エントリポイントの呼び出し
Microsoft.AspNet.Server.Kestrel githubは呼び出しに変換されます。
Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.Kestrel
したがって、最終的なコマンドは次のようになります。
dnx.exe --appbase . Microsoft.DNX.ApplicationHost Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.Kestrel
その結果、Microsoft.DNX.ApplicationHostはエントリポイントメソッドMicrosoft.AspNet.Hostingを呼び出します（クロスプラットフォームコンソールアプリケーションのセクションで、実行する代わりにアセンブリ名を渡すと、ApplicationHostがエントリポイントを呼び出すと言いました）。
docs.asp.netドキュメントのホスティングに関する記事は準備ができていませんが、ホスティングの構成に使用されるキーについてはこちらをご覧ください 。
Webアプリケーションの起動ロジック
ホスティングレイヤーは
、 ドキュメント Webアプリケーションの
github 開始ロジックを
起動する役割も果たします。 以前はGlobal.asaxファイルにありましたが、現在はデフォルトでStartupクラスにあり、リクエスト処理パイプラインの構築に使用されるConfigureメソッドと、Webアプリケーションサービスの設定に使用されるConfigureServicesメソッドで構成されています。
namespace WebApplication1 { public class Startup { public void ConfigureService(IServiceCollection services) {
Configureメソッドは、
IApplicationBuilder githubインターフェイスを使用して
、リクエスト処理パイプラインを
構築します。 IApplicationBuilderを使用すると、リクエスト処理パイプラインでリクエストデリゲート（「使用」メソッド）を登録し、ミドルウェア（「UseMiddleware」メソッド）を登録できます。
リクエストデリゲートは、ASP.NET 5の重要な概念です。リクエストデリゲートは、着信リクエストハンドラであり、HttpContextを受け入れ、非同期で有用な処理を行います。
public delegate Task RequestDelegate(HttpContext context);
ASP.NET 5での要求処理は、登録された要求デリゲートのチェーンに沿った呼び出しです。 ただし、チェーン内の次のリクエストデリゲートを呼び出す決定は作成者に委ねられるため、各リクエストデリゲートはリクエストの処理を停止して、ユーザーに応答を返すことができます。
次の要求デリゲートを呼び出さない要求デリゲート要求処理パイプラインでの登録を簡素化するには、Run拡張メソッドIApplicationBuilderを使用できます。
public void Configure(IApplicationBuilder app) { app.Run(async context => await context.Response.WriteAsync("Hello, world!")); }
Use拡張メソッドを使用し、次のリクエストデリゲートを呼び出さなくても同じことが実現できます。
public void Configure(IApplicationBuilder app) { app.Use(next => async context => await context.Response.WriteAsync("Hello, world!")); }
そして、リクエストデリゲートチェーンで次を呼び出す例：
public void Configure(IApplicationBuilder app) { app.Use(next => async context => { await context.Response.WriteAsync("Hello, world!"); await next.Invoke(context); }); }
要求デリゲートを簡単に再利用できるようにするために、
ASP.NET 5ミドルウェア ドキュメントの形式でフォーマットすることができます。
ミドルウェア
ミドルウェアASP.NET 5は、特定の規則に従う通常のクラスです。
- チェーン内の次の要求デリゲート（および必要なサービスと追加パラメーター）はミドルウェアコンストラクターに渡されます。
- HttpContext処理ロジックは、非同期のInvokeメソッドに実装する必要があります。
ミドルウェアの例：
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); } }
要求デリゲートチェーンの次の呼び出し（次を呼び出す場合）は、Invokeメソッド内で行う必要があります。 次のリクエストデリゲートの呼び出しの下にロジックを配置すると、リクエストに続くすべての着信リクエストハンドラが完了した後に実行されます。
要求処理パイプラインでは、IApplicationBuilderメソッドの
UseMiddleware<T>拡張機能を使用して、この規則に従ってミドルウェアを含めることができます。
public void Configure(IApplicationBuilder app) { app.UseMiddleware<XHttpHeaderOverrideMiddleware>(); }
このメソッドに渡されるパラメーターは、
RequestDelegate nextおよび要求されたサービスの後にミドルウェアコンストラクターで実装されます。
さらにサービスとパラメーターを受け入れるミドルウェアコンストラクター：
public XHttpHeaderOverrideMiddleware(RequestDelegate next, SomeServise1 service1, SomeServise2 service2, string param1, bool param2) { _next = next; }
リクエスト処理パイプラインにミドルウェアを含め、パラメーターを渡す：
public void Configure(IApplicationBuilder app) { app.UseMiddleware<XHttpHeaderOverrideMiddleware>(param1, param2); }
慣例により、呼び出しチェーンへのミドルウェアの組み込みは、IApplicationBuilderの「Use ...」拡張メソッドの形式で行う必要があります。
public static class BuilderExtensions { public static IApplicationBuilder UseXHttpHeaderOverride( this IApplicationBuilder builder) { return builder.UseMiddleware<XHttpHeaderOverrideMiddleware>(); } }
このミドルウェアをリクエスト処理パイプラインに含めるには、Configureメソッドでこの拡張メソッドを呼び出す必要があります。
public void Configure(IApplicationBuilder app) { app.UseXHttpHeaderOverride(); }
ASP.NET 5には、組み込みミドルウェアの大規模なセットが付属しています。
ドキュメント ファイル 、
ルーティング ドキュメント 、エラー処理、
ドキュメント 診断 、およびセキュリティを操作
するためのミドルウェアがあり
ます 。 ミドルウェアは、nuget.orgを通じてNuGetパッケージとして出荷されます。
サービス
ASP.NET 5は、サービスの概念を導入します。これは、アプリケーション内のいくつかの場所でアクセスが必要となる可能性のある「共通」コンポーネントです。 サービスは、依存性注入システムを介してアプリケーションで利用できます。 ASP.NET 5には、コンストラクターでの依存性注入をサポートする単純な
ドキュメント IoCコンテナーが付属していますが
、その
ドキュメントを別のコンテナーに簡単に
置き換えることができます。
Startupクラスは依存関係の注入もサポートしています。コンストラクターパラメーターとしてクエリを実行するだけです。
public Startup(IApplicationEnvironment appEnv) { }
デフォルトでは、次のサービスを利用できます。
Microsoft.Extensions.PlatformAbstractions.IApplicationEnvironment-アプリケーションに関する情報（アプリケーションフォルダーへの物理パス、その名前、バージョン、ランタイムフレームワークで使用される構成（リリース、デバッグ））。
Microsoft.Extensions.PlatformAbstractions.IRuntimeEnvironment -DNXランタイムおよびOS情報。
Microsoft.AspNet.Hosting.IHostingEnvironment-アプリケーションのWebルート（通常は「wwwroot」フォルダー）へのアクセス、および現在の環境に関する情報（dev、stage、prod）。
Microsoft.Extensions.Logging.ILoggerFactoryは、
ドキュメント ロガーを作成するためのファクトリです。
Microsoft.AspNet.Hosting.Builder.IApplicationBuilderFactory -IApplicationBuilderを作成するためのファクトリー（要求パイプラインのビルドに使用）。
Microsoft.AspNet.Http.IHttpContextFactoryは、Httpコンテキストを作成するためのファクトリーです。
Microsoft.AspNet.Http.IHttpContextAccessor-現在のHttpコンテキストへのアクセスを提供します。
IServiceCollection githubインターフェイスを使用して、StartupクラスのConfigureServicesメソッドでアプリケーションにサービスを追加できます。 通常、フレームワークとライブラリは、IServiceCollectionの「Add ...」拡張メソッドを提供して、IoCコンテナにサービスを追加します。 たとえば、ASP.NET MVC 6で使用されるサービスの追加は次のように行われます。
public void ConfigureServices(IServiceCollection services) {
IoCコンテナに独自のサービスを追加できます。 追加されるサービスは、transient（AddTransientメソッドIServiceCollection）、scoped（AddScopedメソッドIServiceCollection）、singleton（AddSingletonメソッドIServiceCollection）の3つのタイプのいずれかです。
public void ConfigureServices(IServiceCollection services) { services.AddTransient<CustomService1>(); services.AddScoped<CustomService2>(); services.AddSingleton<CustomService3>(); }
コンテナからのリクエストごとに一時的なサービスが作成されます。 スコープサービスは、現在のスコープで作成されていない場合にのみ作成されます。 Webアプリケーションでは、各リクエストに対してスコープコンテナが作成されるため、各HTTPリクエストに対して作成されるサービスと考えることができます。 シングルトンサービスは、アプリケーションのライフサイクルごとに1回だけ作成されます。
依存関係の注入にアクセスできないコンソールアプリケーションでは、静的なMicrosoft.Extensions.PlatformAbstractions.PlatformServices.Defaultオブジェクトを使用して、サービスにアクセスする必要があります：IApplicationEnvironmentおよびIRuntimeEnvironment。
アプリケーション構成
Web.configおよびapp.configファイルはサポートされなくなりました。 代わりに、ASP.NET 5は、新しく簡素化された
構成API ドキュメントを 使用します 。 さまざまなソースからデータを受信できます。 デフォルトの構成プロバイダーは、JSON、XML、INI、コマンドライン引数、環境変数、およびコードからのパラメーターの直接設定（メモリ内コレクション）をサポートしています。 複数のソースを指定でき、それらは追加された順序で使用されます（最後に追加されたソースは、以前に追加された設定を上書きします）。 また、
ドキュメント 環境ごとに異なる設定（test、stage、prod）を設定することもできます。 これにより、さまざまな環境でのアプリケーションの公開が容易になります。
appsettings.jsonファイルの例：
{ "Name": "Stas", "Surname": "Boyarincev" }
構成APIを使用してアプリケーション構成を取得する例：
var builder = new ConfigurationBuilder() .AddJsonFile("appsettings.json") .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true) .AddEnvironmentVariables(); var Configuration = builder.Build();
GetSectionメソッドとキー名を使用してデータを要求できます。
var name = Configuration.GetSection("name"); var surname = Configuration.GetSection("surname");
または、インデックスによる連絡：
var name = Configuration["name"]; var surname = Configuration["surname"];
StartupクラスでConfiguration APIを操作し、設定を任意の機能に対応する小さなデータセットに分割し、
Options docsメカニズムを使用してアプリケーションの他の部分に設定することをお勧めします。
オプションメカニズムを使用すると、Plain Old CLR Object（POCO）クラスを設定付きのオブジェクトとして使用できます。 ConfigureServicesメソッドでIServiceCollectionのAddOptions拡張メソッドを呼び出すことにより、アプリケーションに追加できます。
public void ConfigureServices(IServiceCollection services) {
実際、AddOptionsを呼び出すと、依存関係注入システムに
IOptions<TOption>が追加されます。 このサービスを使用して、依存関係の注入が可能な場所であれば、さまざまなタイプのオプションを取得できます（
IOption<TOption>からの要求だけで、TOption POCOは必要な設定を持つクラスです）。
オプションを登録するには、
Configure<TOption>拡張メソッドIServiceCollectionを使用できます。
public void ConfigureServices(IServiceCollection services) { services.Configure<MvcOptions>(options => options.Filters.Add( new MyGlobalFilter())); }
上記の例では、
MvcOptions githubは、MVCフレームワークがユーザーから設定を取得するために使用するクラスです。
構成設定の一部をオプションに簡単に渡すこともできます。
public void ConfigureServices(IServiceCollection services) {
この場合、構成の設定キーは、設定クラスのPOCOプロパティ名にマップされます。
また、アプリケーション内で設定された設定でMyOptionsを取得するには、たとえばコントローラーのコンストラクターを介して、依存関係
IOption<MyOptions>システム
IOption<MyOptions>から要求するだけで十分です。
public HomeController(IOptions<MyOptions> appOptions) { }
内部的に、Optionsメカニズムは、
IConfigureOptions<TOptions>をサービスコンテナーに追加することで機能します。TOptionsは設定クラスです。
IOptions<TOption>の標準実装は
IConfigureOptions<TOptions>同じタイプのすべての
IOptions<TOption>を収集し、「それらのプロパティを要約」して、最終インスタンスを提供します。これは、同じタイプの設定を持つオブジェクトをサービスコンテナに何度も追加できるためです。設定を上書きします。
Webサーバー
Webサーバーが起動するとすぐに、着信要求の待機が開始され、各要求の処理プロセスが開始されます。 Webサーバーのレベルは、要求をホスティングレベルに上げ、一連の機能インターフェイスを送信します。 ファイル、Webソケット、セッションサポート、クライアント証明書、および
他の多くの ドキュメントを送信するための機能インターフェイスがあります。
たとえば、Httpリクエストの機能インターフェイス：
namespace Microsoft.AspNet.Http.Features { 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; } IHeaderDictionary Headers { get; set; } Stream Body { get; set; } } }
Webサーバーは、機能インターフェイスを使用して、低レベルの機能をホスティングレベルに公開します。 そして彼は、
HttpContextを通じてアプリケーション全体でそれらを利用できるようにします。 これにより、Webサーバーのレベルとホスティングとの密接な関係を破り、さまざまなWebサーバーにアプリケーションを配置できます。 ASP.NET 5には、HTTP.SYS（
Microsoft.AspNet.Server.WebListener ）上のラッパーと、
Kestrel githubという新しいクロスプラットフォームWebサーバーが付属しています。
.NET（OWIN）のオープンWebインターフェイスは、これらの目標を共有する標準です。 OWINは、.NETサーバーとアプリケーションが相互に通信する方法を標準化します。 ASP.NET 5
は 、
Microsoft.AspNet.Owin githubパッケージを使用
してOWIN ドキュメントを
サポートしています。
github ASP.NET 5 OWIN-based -
OWIN middleware github ASP.NET 5 pipeline.
Katana Project Microsoft OWIN ASP.NET ASP.NET 5. Katana pipeline middleware -. , Katana, OWIN , ASP.NET 5 . Katana middleware ASP.NET 5
OWIN githubまとめ
ASP.NET 5ランタイムは、クロスプラットフォームWebアプリケーションをサポートするためにゼロから構築されています。ASP.NET 5には、完全な.NET Framework、.NET Core、さらにはMonoで実行できる柔軟な多層アーキテクチャがあります。新しいホスティングモデルにより、ミドルウェアを使用してアプリケーションを簡単に作成し、さまざまなWebサーバーでホストできます。また、依存関係の注入と新しい改良されたアプリケーション構成機能もサポートします。リンク集
github.com/aspnetはASP.NET 5のソースコードです。docs.asp.netはASP.NET 5 のドキュメントです。github.com/ aspnet / Home / wikiはDNXランタイムに関する記事です。