dotnet core 命令行使用web deploy 部署项目到远程IIS

众所周知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）