Visual Studio 中开发人员特定的 app.config/web.config 文件

Question

我们有几个 .NET 项目，我们将某些设置存储在配置文件中。

现在，每个开发人员都有自己的配置文件，这些配置文件略有不同（连接到本地数据库的连接字符串不同，不同的 WCF 端点等）

目前，我们倾向于检查 app/web.config 文件并修改它们以满足我们的需求。

这会导致许多问题，因为从 TFS。

你如何处理这样的情况？或者说你根本没有这个问题？

Answer 1

我们使用的系统结合了本页上的几个现有答案，并借鉴了 Scott Hanselman 的建议 。

简而言之，我们所做的就是拥有一个通用的 app.config / web.config，并将大部分特定设置放在各个文件中，正如此处其他答案所建议的那样。例如，对于我们的 SMTP 设置，app.config 包含

<system.net>
  <mailSettings>
    <smtp configSource="config\smtp.config" />
  </mailSettings>
</system.net>

此文件位于源代码管理中。然而，像这样的单个文件却并非如此：

<?xml version="1.0" encoding="utf-8" ?>
<smtp deliveryMethod="Network">
  <network host="127.0.0.1" port="25" defaultCredentials="false" password="" userName ="" />
</smtp>

但这并不是故事的结局。新的开发人员或新的源安装怎么样？大部分配置不再位于源代码管理中，手动构建所需的所有 .config 文件非常痛苦。我更喜欢拥有至少可以立即编译的源代码。

因此，我们确实在源代码管理中保留了 .config 文件的一个版本，名为 .config.default 文件。因此，新的源代码树如下所示：

不过，对开发人员来说实际上没有任何用处，因为对于 Visual Studio 来说它们只是毫无意义的文本文件。因此，批处理文件 copy_default_config.bat 负责从 .config.default 文件创建一组初始 .config 文件：

@echo off
@REM Makes copies of all .default files without the .default extension, only if it doesn't already exist. Does the same recursively through all child folders.
for /r %%f in (*.default) do (
    if not exist "%%~pnf" (echo Copying %%~pnf.default to %%~pnf & copy "%%f" "%%~pnf" /y)
)
echo Done.

该脚本可以安全地重新运行，因为已经拥有其.config 文件不会覆盖它们。因此，可以想象，可以将此批处理文件作为预构建事件运行。 .default 文件中的值对于新安装可能不完全正确，但它们是一个合理的起点。

最终每个开发人员最终得到的是一个配置文件的文件夹，如下所示：

它可能看起来有点虽然很复杂，但这绝对比开发人员互相踩脚趾的麻烦要好。

Answer 2

在您的 Web.config 中使用来自其他文件的源代码

<configuration>
    <connectionStrings configSource="ConnectionStrings.config" />
...
</configuration>

将 web.config 保留在版本控制中，并且不要对 ConnectionStrings.config 执行此操作。
现在，所有开发人员都拥有一个用于连接字符串的文件。

您可以对所有本地相关设置执行此操作。

Answer 3

下面是针对 web.config 文件和 Visual Studio 2010 的解决方案：

1) 手动编辑 Web 应用程序 .csproj 文件以添加 AfterBuild 目标，如下所示：

  <Project>
   ...
    <Target Name="AfterBuild">
      <Copy SourceFiles="web.config" DestinationFiles="obj\$(Configuration)\tempweb.config" />
      <TransformXml Source="obj\$(Configuration)\tempweb.config"
                  Transform="web.$(USERNAME).config"
                  Destination="obj\$(Configuration)\tempweb2.config" />
      <ReadLinesFromFile File="obj\$(Configuration)\tempweb2.config"><Output TaskParameter="Lines" ItemName="TransformedWebConfig"/></ReadLinesFromFile>
      <ReadLinesFromFile File="web.config"><Output TaskParameter="Lines" ItemName="UnTransformedWebConfig"/></ReadLinesFromFile>
      <Copy Condition=" @(UnTransformedWebConfig) != @(TransformedWebConfig) " SourceFiles="obj\$(Configuration)\tempweb2.config" DestinationFiles="web.config" OverwriteReadOnlyFiles="True" />
    </Target>
  </Project>

该目标将转换与以下内容对应的 Web.config 文件：当前开发人员已登录 - 因此是 $(USERNAME) 变量 - 以及 1) 中创建的相应文件。
仅当内容在每次构建时发生更改（以避免重新启动）时，它才会替换本地 Web.config，即使本地 Web.config 受源代码控制，这就是 OverwriteReadOnlyFiles 设置为真的。这一点其实是值得商榷的。

2) 为项目中的每个开发人员创建一个名为 Web.[developer windows login].config 的文件。 （例如，在下面的屏幕截图中，我有两个名为 smo 和 smo2 的开发人员）：

这些文件（每个 1 个）开发人员）可以/应该进行源代码控制。它们不应该被标记为依赖于主 Web.config，因为我们希望能够单独检查它们。

每个文件都代表一个应用于主 Web.Config 文件的转换。
转换语法如下所述：Web 应用程序项目部署的 Web.config 转换语法。我们重用了这个很酷的 Xml 文件转换任务，它是 Visual Studio 中开箱即用的。此任务的目的是合并 Xml 元素和属性，而不是覆盖整个文件。

例如，下面是一个示例 web.[dev login].config，它更改名为“MyDB”的连接字符串，而不考虑 Web.config 文件的其余部分：

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
    </connectionStrings>
</configuration>

现在，此解决方案并不完美因为：

• 构建后，开发人员可能在本地拥有与源代码控制系统不同的 Web.Config，
• 当从源代码控制系统获取新的 Web.Config 时，开发人员可能必须强制本地写入，
• 开发人员不应签出/签入主 Web。配置。它应该保留给少数人。

但至少，您只需维护一个唯一的主 web.config 以及每个开发人员一个转换文件。

对于 App.config（不是 Web）文件可以采取类似的方法，但我没有进一步详细说明。

Answer 4

我们使用 machine.config 来避免环境之间的 web.config 存在差异。

Answer 5

忽略该文件，使其永远不会被签入怎么样？我遇到了类似的问题，并将 web.config 添加到 Subversion 的忽略列表中。

但在 TFS 中，这有点困难，请参阅这篇文章< /a> 关于如何做到这一点。

Answer 6

您可以应对的一种方法是拥有一个代币化系统并使用 rake 脚本来更改值。

一个更基本的方法可能是为 web.config 中的所有 AppSettings 提供一个指向 AppSettings.config 文件的链接（与连接类似），即

<appSettings configSource="_configs/AppSettings.config" />

然后有一个文件夹，每个开发人员在子文件夹中都有一个版本（即 /_configs /戴夫/）。然后，当开发人员处理自己的代码时，他们会从子文件夹复制到链接文件夹的根目录。

您需要确保传达对这些文件的更改（除非您标记化）。如果您将 AppSettings.config 文件置于源代码控制之外，并且仅签入开发人员的各个文件夹（所有文件夹），那么他们将被迫复制正确的文件夹。

我更喜欢标记化，但如果这只是一个快速修复，那么启动和运行可能会更困难。

Answer 7

忽略这些文件并拥有 Commom_Web.Config 和 Common_App.Config。使用带有构建任务的持续集成构建服务器，将这两个任务重命名为正常名称，以便构建服务器可以完成其工作。

Answer 8

我们有同样的问题，我们正在做的是

• 使用测试服务器/生产值检查 web.config
• 开发人员转到 Windows 资源管理器并更改文件的只读模式
• 编辑配置以适合他们的环境。
• 仅当部署值更改或添加或删除任何配置条目时，才会签入 web.config。
• 这需要为每个配置条目提供大量注释，因为每个开发人员都需要对其进行更改

Answer 9

假设您使用的是 Visual Studio，为什么不使用不同的解决方案配置？
例如：您可以拥有使用 Web.config.debug 的调试配置和使用 Web.config.release 的发布配置。 Web.config.debug 应该具有类似于

<appSettings file="C:/Standard_Path_To_Configs/Standard_Name_For_Config.config"> 

文件 Standard_Name_For_Config.config 的内容，该文件获取所有个人开发人员设置，而 Web.config.release 始终具有生产设置。
您可以将默认配置存储在某些源代码管理文件夹中，并让新用户从那里获取它们。