Question

因此，我们有一个构建过程，可以处理不同环境中的不同开发web.config。我们使用ConfigSource属性并让Team City选择适当的文件。

这很好，但是当开发人员的环境略有不同时我该怎么办？

CI，无法帮助，因为每个人都直接从SVN中获取（即CI显然不会构建到每个开发人员本地计算机上）。

我将使用ConnectionStrings配置部分作为示例：

<connectionStrings configSource=".\Config\ConnectionStrings.config">
</connectionStrings>

我们有： configs\ConnectionStrings.config (通用的）

但我可能需要使用：

configs\ConnectionStrings.dev1.config
configs\ConnectionStrings.dev2.config
configs\ConnectionStrings.dev3.config

取决于目前正在使用代码的开发人员。

有什么想法吗？

Answer 1

我们过去使用过的一种技术（我记得Ayende在网络广播中提到它）是每个连接字符串都以开发者的机器名称命名，例如。

<connectionStrings>
    <add name="BobsPC" connectionString=""/>
    <add name="JonsPC" connectionString=""/>
</connectionStrings>

在调试时，我们会查找“当前”机器名称的连接字符串名称。

这可以节省多个连接字符串文件。相反，我们有一个包含多个连接字符串的文件。

Answer 2

您是否尝试过调查web.config transformations？他们可能能够提供您所寻求的功能，同时仍然将所有内容保留在版本控制中或需要进行任何代码更改。此外，它不仅可以用于连接字符串，还可以用于目录等等。

Answer 3

我们有一个单独的连接文件，就像你提到的当前机器名一样。在需要连接字符串的项目的构建事件中，我们添加了一个预先构建的事件，该事件从当前项目中删除了connection.config文件，在post build事件中，我们将connections.machine.config复制到connections.config中。当前项目文件夹。

在我们的web.config中，我们有一个.NET，它将在一个单独的文件中查找连接字符串信息。

只有在实际部署项目时才能使用Web.config转换。 “default”web.config将始终在本地开发计算机上使用，因此这不适用于开发环境。

您可以将此机制扩展到应用程序设置和其他配置文件，方法是将机器指定的文件放在解决方案文件夹中，然后只在构建时复制它们。

Web.Configs跨越不同的开发环境（和SVN）

3 个答案: