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 實用程序啟動的 .dlldotnet 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 文件。
ASP.NET Core 2.2 基礎知識(十八) 托管和部署 概述