9月,微軟發佈了新版.NET Core,用於構建Windows桌面應用程序,包括WPF和Windows Forms。從那時起開發人員能夠將傳統的nfx桌面應用程序(和控件庫)遷移到.NET Core。通常使用WPF和Windows Forms開發的業務範圍包括:git
這只是.NET Core上Windows應用程序開發的開始。繼續閱讀以瞭解有關.NET Core對構建Windows應用程序更多好處的信息。github
.NET Core(以及未來在.NET Core之上構建的.NET 5)將是.NET的將來。在將來幾年內微軟將繼續支持.NET Framework,可是不會增長任何新功能,這些新功能只會添加到.NET Core(最終是.NET 5)中。爲了改進Windows桌面應用領域,並使.NET桌面開發人員能夠從中受益,微軟將Windows Forms和WPF引入了.NET Core,但由於與Windows API緊密相關,因此仍將僅支持Windows平臺。可是.NET Core除了能夠跨平臺使用外,還具備許多其餘功能,能夠加強桌面應用程序。數據庫
首先,全部運行時改進和語言功能將僅添加到.NET Core中,之後也將添加到.NET 5中。一個很好的例子是C# 8,它已在.NET Core 3.0中可用。並且Windows Forms和WPF的.NET Core版本將成爲.NET 5平臺的一部分。json
此外,.NET Core經過.NET Framework中不可用的新選項爲應用程序帶來了部署靈活性,例如:windows
經過將應用程序程序集編譯爲ReadyToRun(R2R)格式,能夠縮短.NET Core應用程序的啓動時間。R2R是一種提早(AOT)編譯的形式。它是.NET Core 3.0中的發佈時選擇功能。api
R2R二進制文件經過減小應用程序加載時JIT須要完成的工做量來提升啓動性能。R2R二進制文件較大,由於它們既包含中間語言(IL)代碼(某些狀況下仍然須要此代碼),也包含相同代碼的本機版本,以改善啓動。安全
要啓用ReadyToRun編譯:性能優化
PublishReadyToRun
屬性設置爲true
。RuntimeIdentifier
。注意:編譯應用程序程序集時,生成的本機代碼特定於平臺和體系結構(這就是發佈時必須指定有效的RuntimeIdentifier的緣由)。網絡
下面是一個例子:app
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishReadyToRun>true</PublishReadyToRun> </PropertyGroup> </Project>
並使用如下命令發佈:
dotnet publish -r win-x64 -c Release
注意:
RuntimeIdentifier
能夠將其設置爲其餘操做系統或芯片。也能夠在項目文件中設置。<PublishReadyToRunShowWarnings>true</PublishReadyToRunShowWarnings>
查看詳情日誌。.NET core 3.0 SDK附帶了一個工具,該工具能夠經過分析IL和修剪未使用的程序集來減少應用程序的大小。這是.NET Core 3.0中的另外一個發佈時選擇加入功能。
藉助.NET Core,始終能夠發佈包含運行代碼所需的一切的自包含應用程序,而無需在部署目標上安裝.NET。在某些狀況下,該應用僅須要框架的一小部分便可運行,而且可能僅包含所使用的庫就能夠變得更小。
使用IL連接器掃描應用程序的IL,以檢測實際須要哪些代碼,而後修剪未使用的框架庫。這能夠大大減少某些應用程序的大小。一般,相似小型工具的控制檯應用程序受益最大,由於它們傾向於使用框架的較小子集,而且一般更易於調整。
要使用連接器:
PublishTrimmed
屬性設置爲true
。RuntimeIdentifier
。下面是一個例子:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishTrimmed>true</PublishTrimmed> </PropertyGroup> </Project>
並使用如下命令發佈:
dotnet publish -r win-x64 -c Release
注意:RuntimeIdentifier
能夠將其設置爲其餘操做系統或芯片。也能夠在項目文件中設置。
經測試對於helloworld應用程序,大小從〜68MB減少到〜28MB。
修剪後使用反射或相關動態功能的應用程序或框架(包括ASP.NET Core和WPF)一般會中斷,由於連接器不瞭解這種動態行爲,而且一般沒法肯定反射所需的框架類型在運行時。要修剪此類應用程序,您須要告知連接器有關代碼中以及依賴的任何包或框架中反射所須要的任何類型。修剪後必定要測試應用程序。針對這個問題微軟在.NET 5上正在努力改善。
有關IL Linker的更多信息,請參閱文檔,或訪問mono / linker存儲庫。
注意:在.NET Core的早期版本中,ILLink.Tasks做爲外部NuGet軟件包提供,並提供了許多相同的功能。請更新到.NET Core 3.0 SDK,而後嘗試新的體驗!
Assembly linking和ReadyToRun compiler可用於同一應用程序。一般,Assembly linking使應用程序更小,ready-to-run compiler 使應用程序更大一些,但在性能上有明顯優點。能夠在各類配置中進行測試以瞭解每一個選項的影響。
可使用發佈單個文件的可執行文件dotnet publish
。這種形式的單個EXE其實是一個自解壓縮的可執行文件。它包含全部依賴項(包括本地依賴項)做爲資源。在第一次啓動時,它將全部依賴項複製到一個臨時目錄,並在該目錄中加載它們。它只須要解壓縮依賴項一次。當再次啓動時將會很快啓動,而且沒有任何損失。
能夠經過將PublishSingleFile
屬性添加到項目文件或在命令行上添加新的參數來啓用此發佈選項。
要生成一個獨立的單個EXE應用程序,在這種狀況下,對於64位Windows:
dotnet publish -r win10-x64 /p:PublishSingleFile=true
注意:
RuntimeIdentifier
能夠將其設置爲其餘操做系統或芯片。也能夠在項目文件中設置。有關更多信息,請參見單文件捆綁器。
Assembly trimmer, ahead-of-time compilation(經過crossgen)和單個文件捆綁都是.NET Core 3.0中的全部新功能,能夠一塊兒使用,也能夠單獨使用。
經過設置屬性<PublishSingleFile>
,<RuntimeIdentifier>
、<PublishTrimmed>
、 <PublishReadyToRun>
、<PublishReadyToRunShowWarnings>
在發佈配置文件中,可以將修剪、ahead-of-time compilation後的自包含應用程序部署爲單個.exe文件,以下面的示例所示。
<PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishSingleFile>true</PublishSingleFile> <RuntimeIdentifier>win-x64</RuntimeIdentifier> <PublishReadyToRun>true</PublishReadyToRun> <PublishReadyToRunShowWarnings>true</PublishReadyToRunShowWarnings> <PublishTrimmed>true</PublishTrimmed> </PropertyGroup>
而後使用Visual Studio發佈工具或者命令dotnet publish -c release
發佈。
若是你正在尋找一種將應用程序分發給最終用戶的方法,那麼將其打包爲MSIX可能比建立單個.exe
文件更好。PublishSingleFile
提供了一個包含全部應用程序依賴項的自解壓ZIP文件,而MSIX提供了乾淨可靠的Windows集成應用程序安裝和卸載。《MSDN雜誌》上寫了一篇文章,不只展現瞭如何打包應用程序,並且還展現瞭如何爲MSIX包設置持續集成(CI),持續部署(CD)和自動更新。
WPF應用程序在.NET Core上徹底受支持。對於Windows Forms,運行時部分已徹底移植到.NET Core,而且微軟團隊正在繼續開發Windows窗體設計器。微軟計劃在2020年第四季度以前將其準備就緒,如今能夠在Visual Studio預覽下載頁面 16.4 Preview 3或更高版本中籤出設計器的Preview版本。別忘了在工具->選項->預覽功能->使用.NET Core應用程序的Windows窗體設計器預覽,而後從新啓動Visual Studio 。
.NET Framework和.NET Core之間有一些重大更改,但與Windows窗體和WPF區域相關的大多數代碼都按原樣移植到了Core。若是使用的組件包括WCF客戶端,代碼訪問安全性,應用程序域,互操做性和遠程處理,則要切換到.NET Core,則須要重構代碼。
請記住另外一件事,.NET Core上的默認輸出路徑與.NET Framework上的默認輸出路徑不一樣,所以,若是在代碼中對正在運行的應用程序的文件/文件夾結構進行了一些假設,則它可能會在運行時失敗。
此外,配置.NET功能的方式也有所變化。.NET Core而非machine.config
文件使用的<something>.runtimeconfig.json
是應用程序隨附的文件,該文件具備相同的通用目的和類似的信息。一些配置,如system.diagnostics
,system.net
或system.servicemodel
不被支持,那麼應用程序配置文件將失敗是否含有這些內容的加載。此更改影響System.Diagnostics
之前使用XML配置一般配置的跟蹤和WCF客戶端方案。在.NET Core中,須要改成在代碼中進行配置。要更改行爲而無需從新編譯,請考慮使用從Microsoft.Extensions.Configuration
源或從中加載的值來設置跟蹤和WCF類型appSettings
。
能夠在.NET Core沒法使用的.NET Framework技術找到有關.NET Core和.NET Framework之間差別的更多信息。
首先,運行可移植性分析器並在須要時更新代碼以與.NET Core 100%兼容。這是有關使用可移植性分析器的說明。建議在對應用程序進行任何更改以前使用源代碼控制或備份代碼,以防重構沒法按照但願的方式進行。
當應用程序與.NET Core徹底兼容時,就能夠準備移植它了。首先,能夠嘗試使用工具try-convert以幫助將.NET Framework項目自動轉換爲.NET Core。
此工具只是通往.NET Core的起點。它也不是受支持的Microsoft產品。儘管它能夠幫助解決遷移的某些機械問題,但它不能處理全部方案或項目類型。若是遇到該工具沒法轉換的項目,則必須手動進行移植。
.NET Core 3.1是一個小型且簡短的發行版,着重於Blazor和Windows桌面應用(.NET Core 3.0的兩個重大改進)的關鍵改進。這將是一個長期支持(LTS)版本,至少支持3年,預計最終發佈日期爲2019年12月。
此版本中最大的改進是對C++/CLI(又稱爲「託管C++」)的支持。