OWINのStartup.csクラスを使用していて、そこにすべての構成を移動する場合、Global.asax.csファイルが必要ですか？

たとえば、MVCから個別のアカウントテンプレートを使用して作成された新しいASP.NET MVC 5アプリケーションで、Global.asax.csクラスを削除し、その構成コードをStartup.cs Configuration()次のようにメソッドに移動すると、どのような欠点がありますか？

public partial class Startup
{
     public void Configuration(IAppBuilder app)
     {
        AreaRegistration.RegisterAllAreas();
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);

        ConfigureAuth(app);
    }
}

私にとっての利点は、ASP.NET 4アプリケーションをASP.NET 5にアップグレードし、Startup.csクラスで構成する必要がある部分を使用するときに、依存関係の注入と、関連しているように見える2つの異なるクラスでの他の構成を行わないことです。起動、および構成。

Startup.ConfigurationはApplication_Startより少し遅れて呼び出されますが、ほとんどの場合、その違いはそれほど重要ではないと思います。

Global.asaxに他のコードを保持した主な理由は次のとおりです。

1. 以前のバージョンのMVCとの整合性。（これが、現在誰もがこのコードを見つけることを期待している場所です。）
2. 他のイベントハンドラーを追加する機能。Global.asaxでは、Session_StartやApplication_Errorなどの他のメソッドを処理できます。
3. さまざまな認証シナリオにおける正当性。Startup.Configurationメソッドは、binディレクトリにMicrosoft.Owin.Host.SystemWeb.dllがある場合にのみ呼び出されます。このDLLを削除すると、Startup.Configurationの呼び出しが黙って停止します。

3つ目の理由は、デフォルトでこのアプローチを採用しなかった最も重要な理由だと思います。一部のシナリオには、このDLLが含まれていないためです。また、無関係なコードの場所を無効にすることなく認証アプローチを変更できるのは素晴らしいことです（ルート登録）が配置されます。

しかし、これらの理由のいずれもシナリオに当てはまらない場合は、このアプローチを使用しても問題ないと思います。

完全な手順をお探しの方：OWINベースのIISホストWeb APIを作成したい場合は、次の手順を実行する必要があります。

1. File -> New -> Project
2. 対話では、 Installed -> templates -> Other Project types -> Visual Studio Solutions -> Blank Solution targeting .NET 4.6

3. ソリューションで、右クリックして追加Project -> Web -> ASP.NET Web Applicationします（.NET 4.6を対象としています）。

   3.1 ASP.NET 4.5テンプレートで、テンプレートとして[空]を選択します

   3.2これにより、2つのnugetパッケージを持つ空のソリューションが作成されます。

   Microsoft.CodeDom.Providers.DotNetCompilerPlatform v 1.0.0
   Microsoft.Net.Compilers v 1.0.0
   

4. 次のパッケージをインストールします。

   Install-Package Microsoft.AspNet.WebApi.WebHost -Version 5.2.3
   Install-Package Microsoft.AspNet.WebApi -Version 5.2.3
   Install-Package WebApiContrib.Formatting.Razor 2.3.0.0
   

OWINの場合：

Install-Package Microsoft.Owin.Host.SystemWeb 
Install-Package Microsoft.AspNet.WebApi.OwinSelfHost    

次に、構成メソッドを使用してStartup.csを追加します。

[assembly:OwinStartup(typeof(namespace.Startup))]
public class Startup
    {
        /// <summary> Configurations the specified application. </summary>
        /// <param name="app">The application.</param>
        public static void Configuration(IAppBuilder app)
        {
            var httpConfiguration = CreateHttpConfiguration();

            app
                .UseWebApi(httpConfiguration);
        }

        /// <summary> Creates the HTTP configuration. </summary>
        /// <returns> An <see cref="HttpConfiguration"/> to bootstrap the hosted API </returns>
        public static HttpConfiguration CreateHttpConfiguration()
        {
            var httpConfiguration = new HttpConfiguration();
            httpConfiguration.MapHttpAttributeRoutes();

            return httpConfiguration;
        }
}

から継承するクラスを追加し、属性とアクションメソッドでApiController注釈を付けます（後のHttp動詞を表す）。これで問題ありません。RoutePrefixRoute + HttpGet/PutPost

これは、Webアプリケーションの開始/ホスティングがどのように進化するかについての理解です。簡単な要約：

1.クラシックASP.NET：必須のIISパイプラインの最後のステップで実行するアプリケーションコードのみを記述します

2. ASP.NET with OWIN： .NET Webサーバーを構成し、アプリケーションコードを記述します。IISに直接結合されなくなったため、強制的に使用する必要がなくなりました。

3. ASP.NET Core：ホストとWebサーバーの両方を構成して、アプリケーションコードを使用および記述します。完全な.NET Frameworkの代わりに.NET Coreをターゲットにする場合、.NET Webサーバーを使用する必要はなくなりました。

次に、それがどのように機能するか、およびどのクラスを使用してアプリケーションを起動するかについてもう少し詳しく説明します。

従来のASP.NET

従来のASP.NETアプリケーションには、Global.asaxエントリポイントとしてファイルがあります。これらのアプリケーションはIISでのみ実行でき、コードはIISパイプラインの最後で実行されます（コードが実行される前にIISがCORS、認証などを担当します）。IIS 7以降では、ASP.NETランタイムをIISに統合する統合モードでアプリケーションを実行できます。これにより、ファイルのイベントでのURLの書き換えやファイルの新しいセクションの使用など、以前は（またはIIS自体では）不可能であった機能をコードで構成できます。Application_StartGlobal.asax<system.webserver>web.config

OWINを使用したASP.NET

まず、OWINはライブラリではなく、.NET Webサーバー（IISなど）がWebアプリケーションと対話する方法の仕様です。マイクロソフト自体は、プロジェクトカタナ（いくつかの異なるNuGetパッケージを通じて配布）と呼ばれるOWINの実装を持っています。この実装は、クラスでIAppBuilder遭遇するインターフェイスとStartup、Microsoftが提供する一部のOWINミドルウェアコンポーネント（OMC）を提供します。使用するIAppBuilder基本的にプラグアンドプレイでミドルウェアを構成して、Webサーバー用のパイプラインを作成します（上記のポイントのようにIIS7 +のASP.NETパイプラインに加えて）。 CORSのミドルウェアコンポーネント、認証のミドルウェアコンポーネント...）このため、アプリケーションはIISに明確に結合されなくなり、次のような任意の.NET Webサーバーで実行できます。

• OwinHostのパッケージには、カタナのウェブサーバで自己ホストアプリケーションに使用することができます。
• Microsoft.Owin.Host.SystemWebのパッケージは、内部的に正しい生涯のイベントにあなたのミドルウェアをサブスクライブすることによって、統合モードでIIS7 +であなたのOWINアプリケーションをホストするために使用されます。

すべてが非常に混乱するのは、どちらもGlobal.asaxOWIN Startupクラスと一緒にサポートされているということですが、どちらも同じようなことができます。たとえば、本当に混乱Global.asaxするOWINミドルウェアを使用してCORS と認証を実装することができます。

私の経験則では、OWINを追加する必要があるときはいつでもGlobal.asax使用できるように、ファイルStartupをすべて削除することです。

ASP.NET Core

ASP.NET Coreは次の進化であり、.NET Coreまたは完全な.NET Frameworkのいずれかをターゲットにできるようになりました。.NET Coreをターゲットにすると、.NET標準をサポートする任意のホストでアプリケーションを実行できます。つまり、（前のポイントのように）.NET Webサーバーに制限されなくなり、Dockerコンテナー、Linux Webサーバー、IIS ...でアプリケーションをホストできます。

ASP.NET Core WebアプリケーションのエントリポイントはProgram.csファイルです。そこでホストStartupを構成し、パイプラインを構成する場所にクラスを再度指定します。OWINの使用（IAppBuilder.UseOwin拡張メソッドを使用）はオプションですが、完全にサポートされています。