ASP.NET Core 2.2 基礎知識(十八) 託管和部署 概述

爲了方便演示,以 .NET Core 控制檯應用程序講解.

咱們新建一個控制檯應用程序,安裝 "Newtonsoft.Json" Nuget 包,而後右鍵點擊該項目,選擇"發佈":

 

咱們依次選擇"文件",設置好路徑,最後點擊建立配置文件,界面變成了下面這樣:

 

而後咱們點擊"配置"

 

那麼,問題來了."部署模式" 裏面有兩個選項:

1.當選擇框架依賴時,"目標運行時"有:"可移植","win-x86","win-x64","osx-64","linux-x64" 5個選項.

2.當選擇"獨立"時,"目標運行時"沒有"可移植"這個選項.

咱們到底應該怎麼選擇?

不要作思想的巨人,行動的矮子!

沒事兒走兩步!

依賴框架的部署 (FDD) : 框架依賴 + 可移植

 

以這種方法發佈後,進入發佈的文件夾發現,竟然只有5個文件 !

 

1個應用程序的程序集,1個pdb,2個json,1個第三方依賴項.

咦?怎麼沒有.EXE 文件?沒有 .exe 文件,我怎麼運行該項目?(其實,進入到該項目的debug文件夾,你會發現也沒有.exe文件)

這樣運行:(爲了方便,我經過 VS Code 進入該文件夾)

如今,咱們回過頭來看官方對這種方式的解釋:

依賴框架的部署 (FDD) : 顧名思義,依賴目標系統上存在的共享系統級版本的 .NET Core.因爲已存在 .NET Core，所以應用在 .NET Core 安裝程序間也是可移植的.應用僅包含其本身的代碼和任何位於 .NET Core 庫外的第三方依賴項.FDD 包含可經過在命令行中使用 dotnet 實用程序啓動的 .dll 文件。 例如，dotnet app.dll 就能夠運行一個名爲 app 的應用程序.

結合咱們的實際操做,大概就是這幾個意思:

1.FDD 只會部署應用程序和第三方依賴項,也就是發佈生成的這4個文件: MyConsole.dll ,MyConsole.pdb , 應用程序配置文件 MyConsole.deps.json,以及第三方依賴項 Newtonsoft.json.dll .

2.名字既然叫"依賴框架",那依賴的系統確定必需要有框架才行!也就是說,應用程序將要部署到的目標系統上,必需要有 .NET Core ;

3.應用程序將使用目標系統上存在的 .NET Core 版本.這就是最後一個文件的意義.咱們用記事本打開 MyConsole.runtimeconfig.json ,能夠看出,該文件指明瞭咱們須要依賴的.Net Core 的版本: "2.2.0"

{
  "runtimeOptions": { "tfm": "netcoreapp2.2", "framework": { "name": "Microsoft.NETCore.App", "version": "2.2.0" } } }

FDD 也是 .NET Core 和 ASP.NET Core 應用程序的默認部署模型.該部署方式的優缺點以下:

優勢：

• 不須要提早定義 .NET Core 應用將在其上運行的目標操做系統。 由於不管什麼操做系統，.NET Core 的可執行文件和庫都是用通用的 PE 文件格式，所以，不管什麼基礎操做系統，.NET Core 均可執行應用。 
  

• 部署包很小。 只需部署應用及其依賴項，而無需部署 .NET Core 自己。

• 除非重寫，不然 FDD 將使用目標系統上安裝的最新服務運行時。 這容許應用程序使用 .NET Core 運行時的最新修補版本。

• 許多應用均可使用相同的 .NET Core 安裝，從而下降了主機系統上磁盤空間和內存使用量。

缺點：

• 只有目標系統上安裝的 .NET Core 版本不低於應用程序要求的版本時，應用才能運行。

• 若是不瞭解未來版本，.NET Core 運行時和庫可能發生更改。 在極少數狀況下，這可能會更改應用的行爲。

官方的這個優缺點已經說得很詳細了.其中,我對標紅的這句缺點實驗了一下,結果分享給你們:

首先,咱們將 MyConsole.runtimeconfig.json 文件中的版本號修改爲 "2.3.0":

{
  "runtimeOptions": { "tfm": "netcoreapp2.2", "framework": { "name": "Microsoft.NETCore.App", "version": "2.3.0"  } } }

接着,咱們在命令行中輸入 dotnet myconsole.dll 運行該項目:

運行失敗!

錯誤信息大概意思以下:

第1句:沒有找到任何能夠兼容的 framework 版本.

第2句:沒有找到指定的 2.3.0 版本的 framework "Microsoft .NETCore.App" .

最後一句:(該系統)只安裝了 2.2.0 版本.

如今 ,咱們將版本號修改爲 2.1.0 試試看:

{
  "runtimeOptions": { "tfm": "netcoreapp2.2", "framework": { "name": "Microsoft.NETCore.App", "version": "2.1.0" } } }

正常運行了:

 

又 12點 了.睡了.明天繼續

---------------------------------------------------------------------------

2019.1.10

依賴框架的可執行文件 (FDE) : 框架依賴+win-x86/win-x64/osx-64/linux-x64

這是.Net Core 2.2 纔開始有的方式.咱們將"目標運行時" 設爲 win-x64 ,演示效果,左邊是 該方式發佈後的文件,右邊是用 上述 FDD 方式發佈的文件:

 

 

能夠看出來,FDE 只比 FDD 多了一個 .exe 文件而已,意義也很明顯了.

 

獨立部署 (SCD) : 獨立+win-x86/win-x64/osx-64/linux-x64

一樣,咱們將"目標運行時"設爲 win-x64 演示效果:

 

 

只截取了一小部分,實際一共有218個文件.共 66.7MB , 而上面的 FDD,FDE 只有 700KB 左右.

看了實際效果後,咱們回頭看看官方對於 SCD 的解釋:

對於獨立部署，能夠部署應用和所需的第三方依賴項以及生成應用所使用的 .NET Core 版本。 建立 SCD 不包括各類平臺上的 .NET Core 本機依賴項，所以運行應用前這些依賴項必須已存在。從 NET Core 2.1 SDK（版本 2.1.300）開始，.NET Core 支持修補程序版本前滾。 在建立獨立部署時，.NET Core 工具會自動包含你的應用程序所指向的 .NET Core 版本的最新服務的運行時。 （最新服務的運行時包括安全修補程序和其餘 bug 修復程序。）服務的運行時不須要存在於你的生成系統上；它會從 NuGet.org 自動下載。有關詳細信息，包括有關如何選擇退出修補程序版本前滾的說明，請參閱獨立部署運行時前滾。

下面是我結合實際效果,對這段解釋的理解:

1."能夠部署應用和所需的第三方依賴項..." : 實際效果就是這4個文件:MyConsole.dll ,MyConsole.pdb , 應用配置文件 MyConsole.deps.json,以及第三方依賴項 Newtonsoft.json.dll ,同時,因爲 SCD 部署的是可執行文件,且選擇的是 win-x64,,因此還有 MyConsole.exe 文件.

2."...以及生成應用所使用的 .NET Core 版本.": 除了第一條的5個文件,剩下的文件就全是這句話所實現的了.

3."建立 SCD 不包括各類平臺上的 .NET Core 本機依賴項，所以運行應用前這些依賴項必須已存在":不一樣系統安裝 .NET Core ,確定也須要依賴一些其餘東西.而用 SCD 部署時,這些東西是不會生成的,因此,須要確保應用要部署到的系統上已經存在這些.NET Core 所依賴的東西.

4. "運行時前滾。": 這個後面再說.

爲何要部署獨立部署？

SCD 主要有兩個優勢：

• 能夠對與應用一塊兒部署的 .NET Core 版本具備單獨的控制權。 只有你才能維護 .NET Core。

• 請放心，目標系統能夠運行你的 .NET Core 應用，由於你提供的是應用將在其上運行的 .NET Core 版本。

它也有幾個缺點：

• 因爲 .NET Core 包含在部署包中，所以必須提早選擇爲其生成部署包的目標平臺。

• 部署包相對較大，由於須要將 .NET Core 和應用及其第三方依賴項包括在內。

  從.NET Core 2.0 開始，能夠經過使用 .NET Core 全球化固定模式在 Linux 系統上減小大約 28 MB 的部署大小。 一般，Linux 上的 .NET Core 依賴於 ICU 庫來實現全球化支持。 在固定模式下，庫不包含在部署中，而且全部區域性的行爲均相似於固定區域性。

• 向系統部署大量獨立的 .NET Core 應用可能會使用大量磁盤空間，由於每一個應用都會複製 .NET Core 文件。