1

正如 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 为我做的那样？

4

1 回答 1

0

从我能够建立的情况来看，从一个包（比如为这个特定的 MSBuild 命令创建的包）同步会发现与它尝试部署的本地工作副本相关的差异。

如果我重新签出，然后构建和部署，它将发布整个 Web 应用程序。

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

如果我在此基础上进行构建，它只会发布经过转换的 web.config 文件和其他一些我无法押韵或推理的随机 dll。

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

附带说明一下，在执行其他正常的 ms deploy 命令时，我还遇到了随机的、不可靠的 404 错误。它们似乎是断断续续的，并且在我自己的工作站、我的同事和 CI 服务器之间可能会有所不同，因此 MS Deploy 服务将返回 404 或在每次连续调用的几秒钟内正常执行。我为此类行为找到的解决方案包括从重新启动 Visual Studio 到卸载和重新安装各种组件，并确保您以正确的顺序进行操作，并且仅在任何以“ary”结尾的月份的第三周的第二个星期二进行。 ..

对我来说，这个工具是粗略的，如果你能得到一个以任何可靠性工作的设置，那是一个奇迹，你不应该再碰它，并向硅神祈祷它保持这种状态。

于 2013-04-03T18:44:46.500 回答