众所周知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参数即可。
示例如下
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）