眾所周知dotnet cli可以用來編譯和生成發布.net core，其實dotnet publish 還能進行WebDeploy。先解釋一下使用場景一般是用於持續部署
dotnet publish進行web deploy其實是內置調用MSBuild, 相當於dotnet publish和MSBuild進行web deploy兩個步驟合二為一了。
首先，執行部署命令的機器需要安裝MSBuild 和Visual Studio Build Tools。目前最新的Visual Studio Installer已經集成了安裝組件，所以我們只需要通過Visual Studio Installer來安裝就可以了。后續的vs2019版本的安裝器應該也會是這樣的。
如下圖所示，勾選Visual C++生成工具，取消勾選CMake和測試工具(因為進行web deploy是不需要，需要的人請略過)
然后在單個組件中勾選Web部署 (Web Deployed)
然后點擊安裝就可以了，總共需要約4G空間。
在VS中添加WebDeploy配置文件
填入目標服務器，站點名，進行部署的用戶名 密碼，目標url選填。然后點擊驗證連接，測試是否出錯。保存即可。默認生成的發布xml文件叫做CustomProfile.pubxml。在項目的Properties/PublishProfiles下可以看到，可以重命名。
然后打開命令行或者Powershell到項目所在目錄，運行dotnet publish命令，加上web deploy參數即可。
示例如下
dotnet publish -c Release /p:PublishProfile="CustomProfile" /p:Password=xxxxx /p:AllowUntrustedCertificate=true
PublishProfile參數指定發布xml文件名，Password指定發布用戶名的密碼，AllowUntrustedCertificate指定是否允許不信任認證，設置為true就不會報連接未認證的錯誤了。
其實還可以在任意路徑運行，但是dotnet publish后要加上項目csproj文件的路徑，效果和一樣。
命令行發布成功
在windows服務器中使用CI(持續集成)/CD(持續部署)就可以通過這種方式一步到位編譯生成部署。
jenkins teamcity都行。azure devops則完全不需要這種方式，因為它自帶的IIS部署就已經很強大了，而且CI和CD是完全分離的。
但是azure devops的CI構建沒有緩存，導致每次構建都是一次git下載，完全重新編譯部署的過程，實在是 太慢了。或許后續會有所改進吧（再吐槽下azure devops本地部署(就是TFS) 所用的ES實在是太吃內存，常年占用4-6G,換成雲的又是6刀/人/月(5人一下免費),公司開發者剛好10個左右，很尷尬，不願意花這錢。還有就是CI的速度問題最終不得不放棄Azure DevOps,選擇了teamcity）