如何使用 Web 部署（msdeploy）升级（合并）web.config？答案

【问题标题】：How to upgrade (merge) web.config with web deploy (msdeploy)?如何使用 Web 部署（msdeploy）升级（合并）web.config？
【发布时间】：2014-05-26 01:56:06
【问题描述】：

我正在尝试为我们的一些 ASP.NET 应用程序设置部署链。目前选择的工具是 Web Deploy (msdeploy)。不幸的是，我遇到了一个问题。

因此，链的高级概述是：

Web 开发人员创建代码并在 SVN 中检查；
Buildserver 看到更新并构建网站的 msdeploy .zip 包；
.zip 包会自动放入我们的安装程序中并发送给各个客户端；
客户端在其网络服务器上运行安装程序(-s)；
安装程序在内部使用 msdeploy 部署 .zip 包并创建新网站或升级现有网站。

Msdeploy 使部署新实例变得容易，但我对如何执行“升级”安装感到困惑。主要问题是 web.config 文件。每个客户肯定都会在那里进行一些定制以适应他们的特定环境。安装程序本身提供在首次安装时设置一些更关键的参数（通过 msdeploy 的参数机制实现），但他们可以手动设置其他参数。

另一方面，我们开发人员有时也会对 web.config 进行更改，添加一些新设置或删除过时的设置。所以我不能只告诉 msdeploy 完全忽略该文件。我需要某种高级 XML 修改机制。它可能是开发人员维护的脚本，但它只需要在升级时运行，而不是在新安装时运行。

我不知道如何做到这一点。

除此之外，有时还有一些完全奇怪的升级逻辑。例如，该应用程序带有我们公司的徽标，但一些客户已替换该 .png 文件以显示他们自己的徽标。最近我们需要更新徽标 - 但仅限于尚未用自己的徽标替换的客户。

同样，在某些升级时可能需要清理一些缓存文件夹，而在其他升级时则不需要。或包含可能无法触及的用户内容的文件夹（但在初始安装时带有默认内容）。等等。

您通常如何为 msdeploy 包实现这种双重行为？我真的需要为每个应用程序创建 2 个不同的包吗？

【问题讨论】：

标签： asp.net upgrade web-deployment msdeploy webdeploy

【解决方案1】：

个人经验建议：

隔离自定义

您的客户应该能够自定义他们的设置，最好的方法是为他们提供覆盖文件之类的东西。这样您就可以安装新软件包，然后将客户的自定义设置叠加在您的标准设置之上。如果它是全新的安装，那么将没有什么可以叠加的。

> top-level             --
    > standard files      |
           images         | This will never be touched or changed by customer
           settings.txt   |
                        __
    > customer files           --
           images                | Customer hacks this to their heart's content
           settings.txt_override |
                               --

是的，这确实意味着需要进行某种合并过程，并且需要一些脚本来执行此操作，但这种方法有几个优点。

对于突然变得多余的设置，只需发出警告即可
如果客户有自己的徽标，则可以在覆盖文件中指定这一点
信息对客户来说很清楚。远离标准文件。
如果客户要求更多可自定义的设置，则在升级期间将默认设置写入覆盖文件（如果不存在）。

Vilx，在回答您的问题时，必须在脚本本身中包含知道它是否是升级的逻辑。

在安装前运行升级脚本

msdeploy -verb:sync -source:contentPath="C:\Test1" -dest:contentPath="C:\Test2" -preSync:runcommand="c:\UpgradeScript.bat"

或者在安装后运行升级脚本

msdeploy -verb:sync -source:contentPath="C:\Test1" -dest:contentPath="C:\Test2" -postSync:runcommand="c:\UpgradeScript.bat"

更多信息here

至于您如何知道它的升级，您的脚本可以检查名为“version.txt”的文本文件，如果存在，升级 bat 脚本将运行。要包含在文本文件中的版本。有点基本，但它应该可以工作。

这还具有额外的优势，使您能够更优雅地在版本之间合并客户的自定义设置，因为您知道可以为该特定版本覆盖哪些属性。

【讨论】：

我确实打算改用这个模型，是的，但即使这样也需要某种升级脚本。问题是 - 如何在 msdeploy 中获取升级脚本？当且仅当它是升级时，我不知道如何让它运行脚本。
+1 用于隔离自定义，这是一种非常干净的处理方式。您甚至可以比此处描述的更进一步：与其将客户文件放置在顶级安装文件夹中，您可以将它们放置在外部并且只有一个配置此位置的设置（客户可以在安装/升级期间在参数文件中指定）。检查“当且仅当它是升级时” 就像检查此文件夹是否存在（或例如，此文件夹中是否存在 version.txt）一样简单。您的前置/后置脚本可以根据需要处理这些文件。

【解决方案2】：

有一些一般性建议（不是特定于 msdeploy），但我希望对您有所帮助：

我认为无论如何您都需要提供几个安装程序：用于初始设置和每个版本到版本的升级。
我建议让您的客户自己合并配置文件。您可以向他们提供添加/更改/删除 waht 的详细说明，和/或包含简化合并的实用程序。也许this 和this 链接会给你一些指导。
至于合并被替换的标志，其他客户的定制，我认为最好的方法是支持你的应用程序的品牌化。我的意思是 - 将所有品牌细节移到新安装/升级安装人员不会触及的地方。
至于您的客户所做的其他调整，他们会自行承担风险，因此您可以为他们提供的唯一帮助是包含更改的详细列表（甚至可能是更改文件的列表自上一版本以来）以及有关使用 Araxis Merge 或类似工具合并源的操作方法文章
或者..您可以创建一个实用程序并将其包含到安装程序中，这将尝试在客户端计算机上执行所有棘手的合并工作。我不推荐这种方式，因为它需要大量的努力/资源来维护。
还有一件事：您可以在升级之前专注于备份以前的客户端副本。因此，即使是客户端也会遇到升级问题 - 总是有可能回滚。您唯一要做的就是提供一个良好的反馈渠道，您的客户可以使用它来解决他们的问题。此反馈将使您能够找出客户遇到的问题以及如何使他们的升级过程更加舒适。

【讨论】：

【解决方案3】：

我会建立在上面所说的基础上，但我会通过转换和关于谁配置什么的严格文档来做到这一点。您现在拥有它的方式依赖于客户对对应用部署过程至关重要的配置进行干预。

创建三个配置文件区域。一种用于开发，一种用于“生产通用”构建，另一种是供客户编辑的空模板。

开发实例应该是不言自明的。这是采用生产通用模板并为您的开发服务器创建 Web 配置的转换。（听起来你在这里为 CI 类型的流程拍摄）
“生产通用”转换应为应用程序的假设完美实例设置应用程序。如果建筑师按照自己的方式安装，这就是安装的样子。
客户使用客户转换来根据需要设置 Web 配置以满足他们自己的需要。写一些文档，看看会发生什么。在帮助客户完成整个过程的同时编辑文档。

这就是你要找的东西吗？想法？

【讨论】：