ASP.NETコア3.0を探求シリーズ:新しいプロジェクトファイルでProgram.csと一般的なホスト

はじめに: - .csprojプロジェクトファイルとのProgram.csファイルこの記事では、ASP.Netコア3.0アプリケーションの基本的な部分のいくつかを見てみましょう。私は、デフォルトのテンプレートからASP.NETコア2.xの変更でそれらのいくつかを紹介し、APIへの変更のいくつかを説明します。

 

ASP.Netコア3.0シリーズIIも見てみようStartup.csのASP.Netコア3.0を語ります

ASP.Netコアを探検3.0シリーズ3:ASP.Netコア3.0サービスプロバイダの検証

ASP.Netコアを探検3.0シリーズ4:あなたはASP.NETコア3.0でアプリケーションを起動したときに非同期タスクを実行しています

ASP.Netコアを探検3.0シリーズ5:IHostLifetimeを導入し、開始ジェネリックホストを明確に相互作用

ASP.Netコア3.0シリーズ六おすすめ情報ASP.NETコア3.0の新機能は、構造化されたログ情報を開始します

I.はじめに

私たちは、のは、インフラストラクチャ上の変更のいくつかを見てみましょう、私たちは、本番環境で開始された9月23日にリリース。ネットコア3.0は、使用され始めた知っています:

(1)Microsoft.AspNetCore.App NuGetはもはや利用可能に。

(2)ASP.Netコアは現在、一般的なホストではなく、Webホストをベースにしています。

あなたはASP.Netコア2.xのASP.Netコア3.0にアップグレードしたい場合は、記事を参照してください。https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?ビュー= aspnetcore-3.0&タブ=視覚スタジオ

 

私たちは..csprojとのProgram.csファイル内ASP.Netコア新しく作成されたアプリケーションに焦点を当て、この記事では、後の記事で私たちは2.xと様々な変化から来るStartup.csどのように比較されます(例えばウェブWEBAPIのMVCなど)異なるテンプレートの変更。

第二に、新しい.csprojと共有の枠組みの変更

私たちは、以下の変更が表示されます、新しいASP.Netコアプロジェクトを作成し、.csprojファイルを開きます。

 

この比較のASP.NETコア2.xのアプリケーションでプロジェクトファイルならば、様々な類似点と相違点があります。

(1)<TargetFramework>むしろnetcoreapp2.1又は2.2よりも我々が2.1 / 2.2の代わりに純コアプロジェクト3.0を作成しているので、それは、netcoreapp3.0あります。

(2)SDKで、<プロジェクト>要素はまだMicrosoft.Net.Sdk.Webです。

(3)Microsoft.AspNetCore.Appメタパッケージを参照していません。

(4)最後の点は、最も興味深いの変化です。ASP.Netのcore2.1 / 2.2では、あなたは、「共有フレームワーク」元のパッケージ、Microsoft.AspNetCore.Appを参照することができます。共有フレームワークでは、そのようなあなたは、単一のパッケージなどに手動ですべてのアプリケーションをインストールしないようすることができますように多くの利点を提供します。

Nugetパッケージが公開されているとしてネットコア3.0では、Microsoftはまだ以前のように、.NETのコアと一緒にインストールされているフレームワークを共有し、それはMicrosoft.AspNetCore.Appバージョン3.0.0を持っていません、フレームワークを共有されていませんが、3.0ではそれを参照してください。さまざまな方法。

 

ASP.NETコア2.xでは、参照フレームワークを共有するために、プロジェクトファイルには、以下を追加します。

<ItemGroup> 
  <PackageReference含める= " Microsoft.AspNetCore.App " /> 
</ ItemGroup>

これとは対照的に、3.0には、参照する<FrameworkReference>要素を使用することができます。

<ItemGroup> 
  <FrameworkReferenceを含める= " Microsoft.AspNetCore.App " /> 
</ ItemGroup>

慎重な学生は言うかもしれないが、なぜASP.Netコアプロジェクトは、ファイルを私の新しく作成されたが、すでにMicrosoft.AspNetCore.App存在し、実際には、SDK Microsoft.Net.Sdk.Web 3.0のネットコアですでにそれに含まれています。

 

 

 

第三に、パッケージには、共有フレームアセンブリとして使用できなくなりました

3.0での大きな変化は、あなたが、例えば、本来は共有フレームワークの一部であった単一NuGetパッケージをインストールすることはできませんASP.NETコア2.xの中で、あなたがそのようなMicrosoft.AspNetCore.Authenticationとして、単一のパッケージに頼ることができるということですむしろスクリーンショットは以下の全体的なフレームワーク部分に頼るよりMicrosoft.AspNetCore.Identity:

 

 :具体的に資料を参照してください。https://github.com/aspnet/AspNetCore/issues/3756

アプリケーションは常にしかし、.NETのコア3.0で、これはもはや可能で、共有フレームワークに依存しないので、これは、多くの場合、ライブラリーに最も有用です。NuGetこれらのパッケージは、これらのライブラリのいずれかを参照する必要がある場合は、あなたのプロジェクトファイルにライブラリーから<FrameworkReference>要素を追加する必要があり、逆に、利用できなくなります。注意すべきもう一つは、(EF Coreおよび社会的な認証プロバイダなど)いくつかのパッケージは共有フレームワークには含まれていませんということです。あなたはこれらのパッケージを使用する必要がある場合は、手動でプロジェクトにNuGetパッケージをインストールする必要があります。

アプリケーションパッケージの完全なリストについては、参照してください。  https://github.com/aspnet/AspNetCore/issues/3755を

スクリーンショット一部を次のように

 

 

四、Program.csののネットコア3.0

我々は非常に似ていますが、実際には多くの種類が変更されている.NETのコア2.xのバージョンでのProgram.csでASP.Netコア3.0を感じる一目します。.NETのコア3.0で、ASP.NETコアはのように再構築されてきたので、これはある一般的なホストではなく別のウェブホストを使用するよりも、実行時に、。

 

 

 

 上記のチャートから、有意差は、2.1で導入された一般的なホストの存在は、これは良いアイデアですが、多くの問題は、それがライブラリーのためのより多くの仕事を作成しますが、幸い、この変更の3.0にすべき私たちは、これらの問題を解決することができます。

ほとんどの場合、あなたとの最終用途の習慣は、.NETのコア2.xのに非常によく似ていますが、それはむしろ2を持つ単一のメソッドWebHost.CreateDefaultBuilderアプリケーション設定すべてのコンテンツ()、より、二つの論理ステップに分割されます単一のメソッド呼び出し:

(1)Host.CreateDefaultBuilder()関数は、アプリケーションの設定項目、ログ、および依存性注入容器に配置されています。

(2)IHostBuilder.ConfigureWebHostDefaults():使用して、ケストレルの構成:ロールのような必要なすべてのASP.Netコアアプリケーションを追加することであるStartup.csを  DIコンテナと中間パイプを設定します。

 

五、一般的なホストビルダー

私はすでに述べたように、一般的なホストは、ASP.NETコア3.0アプリケーションを構築するための基礎を形成します。ロギング、構成および依存性注入:これは、以下のようなMicrosoft.Extensions ASP.NETコア*用途に使用される基本的な要素を提供します。

次のコードは、単純化されたバージョンHost.CreateDefaultBuilder()メソッドです。それはWebHost.CreateDefaultBuilder()メソッドに似ていますが、いくつかの興味深い変更がある、私は後で説明します。

パブリック 静的 IHostBuilder CreateDefaultBuilder(文字列[]引数)
{ 
    VARのビルダー= 新しいHostBuilder()。

    builder.UseContentRoot(Directory.GetCurrentDirectory())。
    builder.ConfigureHostConfiguration(設定 => 
    { 
        //はDOTNET_環境変数とコマンドライン引数を使用し
    })。

    builder.ConfigureAppConfiguration((hostingContext、設定) => 
    { 
        // JSONファイル、ユーザーの秘密、環境変数やコマンドライン引数
    })
    .ConfigureLogging((hostingContext、ロギング) => 
    { 
        //コンソール、デバッグ、イベントソースのロガーを追加し、EventLogに(Windowsのみ)
    })
    .UseDefaultServiceProvider((コンテキスト、オプション) > = 
    { 
        //はDIプロバイダの検証を設定
    )}。

    リターン・ビルダー。
}

 

要するに、と2.xと比較して約異なるがあります。

  • 環境変数の設定をホストDOTNET_接頭辞を使用します。
  • コマンドライン変数のホストの構成を使用。
  • イベントソースレコードとイベントロガープロバイダーを追加します。
  • オプションは、検証のServiceProviderを有効にします
  • いかなる特定の構成のウェブホスティングません。

(1)関心の最初のポイントは、ホスト構成の配置であり、ウェブ・ホストの環境変数は、デフォルトASPNETCORE_を使用するように構成され、従って、ASPNETCORE_ENVIRONMENT設定値を設定する環境を設定します。一般的なホストのプレフィックスのために今DOTNET_であり、アプリケーションのライン引数に渡された任意のコマンドを実行します。構成制御のホスティング環境で動作しているアプリケーション、コンテンツ、および(通常は一緒にIOptionsインタフェースを持つ)とアプリケーションの設定が分離されているホスト。

(2)主な方法は、アプリケーションを設定することですが、ConfigureAppConfiguration()変更されていません、それはまだ使用していますappsettings.jsonファイルを、そしてappsettings.ENV.jsonのファイル、ユーザーの秘密、環境変数、およびコマンドラインパラメータ。

(3)ユニバーサルホストは3.0で開始したLoggingセクション、それはまだアプリケーション構成ログレベルの設定を通して濾過し、コンソールおよびデバッグロガープロバイダを追加しています。しかし、それはまた、追加のEventSourceの  インターフェース(Windows上でETWおよびLinux上などLTTngなど)OSロギングシステムに使用されるログプロバイダを、。また、Windows上でのみ、レコーダーが追加されます  イベントにログプロバイダを Windowsのイベントログに書き込むために,,。

 

最後に、2.xの中で行われているように、開発環境で実行しているときにスコープを検証するために、一般的なホスト構成依存性注入コンテナ その目的は、依存関係の例、サービスはシングルトンに注入されるサービスの範囲を捕捉することです。3.0では、一般的なホストはまたValidateOnBuildを有効にする、これは私が、その後の記事で説明した機能です。

一般的なホストキーポイントは、ASP.NET CoreまたはHTTPワークロードを持つ任意の特定の関係を持っていない、すなわち、それは普遍的であるということです。あなたは、一般的なホストコンソールアプリケーションや長期のサービスと、一般的なASP.NETのコアアプリケーションを作成するための基礎として使用することができます。3.0で、この点を説明するために、追加のメソッド--ConfigureWebHostDefaultsを持っています()。

 

第六に、使用ConfigureWebHostDefaultsは機能ASP.NETCoreを復元します

この記事では、私は多くの詳細について話をここではないでしょう、長い時間ですが、ConfigureWebHostDefaults  ホスト上の一般的な機能のための拡張メソッドは、「レイヤー」ASP.NETCoreを追加します。最も単純なレベルで、これはホストにケストレルWebサーバーを加えることを含むが、他の変更があります。以下は、(提供機能GenericWebHostBuilder含む)方法の概要を提供しています。

  • ASPNETCORE_プレフィックス環境変数は、(接頭辞DOTNET_変数とコマンドラインパラメータを除く)ホスト構成に追加しました。
  • 添加GenericWebHostService,这是一个实现了IHostService接口的类,实际上运行在ASP.NET Core server,这是使ASP.NET Core可以重用通用主机的主要功能。
  • 添加了一个附加的应用程序配置源,StaticWebAssetsLoader,用于处理Razor UI类库中的静态文件(css / js)。
  • 使用默认值(与2.x相同)配置Kestrel
  • 添加HostFilteringStartupFilter(与2.x相同)
  • 如果ForwardedHeaders_Enabled配置值为true,即ASPNETCORE_FORWARDEDHEADERS_ENABLED环境变量为true,则添加ForwardedHeadersStartupFilter。
  • 在Windows上启用IIS集成。
  • 将端点路由服务(endpoint routing)添加到DI容器。

 

(1)其中的大部分与ASP.NET Core 2.x中的相同,不同之处在于:用于将应用程序作为IHostedService运行的基础结构; 端点路由,此路由在3.0中全局启用(而不是仅在2.2中针对MVC / Razor Pages启用); 和ForwardedHeadersStartupFilter。

(2)ForwardedHeadersMiddleware从1.0开始就存在,在将应用程序托管在代理之后时必不可少,以确保您的应用程序能够处理SSL卸载并正确生成URL。 所更改的是,您只需设置环境变量即可将中间件配置为使用X-Forwarded-For和X-Forwarded-Proto标头。

 

七、总结

在本文中,我仅用两个文件深入研究了从ASP.NET Core 2.x到3.0的更改:.csproj项目文件和`Program.cs文件。 从表面上看,对这些文件的更改很小,因此从2.x移植到3.0并不难。 这种简单性掩盖了幕后的重大变化:共享框架发生了重大变化,并且ASP.NET Core已在通用主机之上重建。

我希望人们会遇到的最大问题是NuGet包之间的差异-一些应用程序将不得不删除对ASP.NET Core包的引用,同时添加对其他包的显式引用。 尽管不难解决,但对于不熟悉此更改的用户可能会造成混淆,因此应该首先怀疑任何问题。

 

 

翻译:Andrew Lock    https://andrewlock.net/exploring-the-new-project-file-program-and-the-generic-host-in-asp-net-core-3/

 

作者:郭峥

出处:http://www.cnblogs.com/runningsmallguo/

本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接。

おすすめ

転載: www.cnblogs.com/runningsmallguo/p/11616202.html