Question

我有以下构建目标设置来执行我的部署，正如Hanselman在他的Tiny Happy Features #3中提到的那样，并且在许多其他地方也提到了我认为是推荐的方法：

msbuild my_web_application.csproj /p:Configuration=Production;
                                     DeployOnBuild=true;
                                     PublishProfile=Production;
                                     VisualStudioVersion=11.0;
                                     AllowUntrustedCertificate=true;
                                     AuthType=NTLM

这可以完成这项工作，并通过在命令行上调用ms deploy来替换我以前的部署步骤：

msdeploy.exe" -source:package="c:\source_to_my_web_application.zip" -dest:auto,my_server_name,includeAcls="False" -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:"c:\source_to_my_web_application\Package.SetParameters.xml"

我可以在两种方法中看到的最大区别是命令行调用只会推送具有修改的文件，而msbuild调用每次都会在整个Web应用程序上发送。

有没有办法让msbuild版本执行“同步”行为，就像直接调用msdeploy为我做的那样？

Answer 1

从我能够建立的内容开始，从包中进行同步（如为此特定MSBuild命令创建的包）将发现与其尝试部署的本地工作副本相关的差异。

如果我进行新的结账，然后进行构建和部署，它将发布整个Web应用程序。

如果我在该工作副本上进行清理和重建，它将只发布重建的dll。

如果我对它进行构建，它将只发布已经转换的web.config文件和其他一些我无法制作押韵或推理的随机dll。

我想，最重要的是，通过我们的CI服务器设置，应该假设所有文件都将发布到服务器，如果它发布的数量少于此次，那就是带宽奖励。

作为旁注，我在遇到正常的ms部署命令时也遇到了随机，不可靠的404错误。它们似乎是间歇性的，并且可以在我自己的工作站，我的同事和CI服务器之间变化，这样MS Deploy服务将返回404或在每次连续调用的几秒钟内执行得很好。我发现这种行为的解决方案包括从重新启动Visual Studio到卸载和重新安装各种组件，并确保以正确的顺序执行，只有以“ary”结尾的任何月份的第三周的第二个星期二。 ..

对我来说，这个工具是粗略的，如果你可以设置任何可靠性的设置它是一个奇迹，你不应该再次触摸它并向硅神祈祷，它保持方式。

通过MSBuild发布MSDeploy会复制所有文件而不是同步文件

1 个答案: