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

我们有几个.NET项目,我们将某些设置存储在configuration文件中。 现在每个开发人员都有自己的configuration文件,这些configuration文件有点不同(不同的连接string连接到本地数据库,不同的WCF端点等)

目前我们倾向于检查app / web.config文件并修改它们以适应我们的需要。 这会导致很多问题,因为有时候会有人在从tfs获取最新版本时检查自己的设置或者自定义configuration。

我的问题是:你如何处理这样的情况? 或者你根本没有这个问题?

我们使用一个系统,结合了这个页面上现有的几个答案,再加上Scott Hanselman的这个build议 。

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

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

该文件在源代码pipe理中。 但是,像这样的单个文件不是:

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

这不是故事结束的地方。 那么新的开发者或新鲜的源代码安装呢? 大部分configuration已经不在源代码pipe理中,手动构build所需的所有.config文件是一件很痛苦的事情。 我更喜欢有源代码,至less可以立即编译。

因此,我们在源代码pipe理中保留了一个名为.config.default文件的.config文件。 因此,新鲜的源代码树如下所示:

替代文字

尽pipe如此,开发人员并没有什么用处,因为对于Visual Studio他们只是没有意义的文本文件。 因此,batch filecopy_default_config.bat负责从.config.default文件创build一组.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文件的开发者不会覆盖它们。 因此,可以想象将这个batch file作为预生成事件运行。 .default文件中的值对于新安装可能不完全正确,但是它们是一个合理的起点。

最终,每个开发人员最终都会看到如下所示的configuration文件文件夹:

替代文字

这似乎有些复杂,但是开发人员彼此踩脚趾的麻烦绝对是可取的。

这里是web.config文件和Visual Studio 2010的解决scheme:

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> 

这个目标将转换对应于当前开发者login的Web.config文件 – 因此$(USERNAME)variables – 与1)中创build的相应文件。 只有当每次构build时内容已经改变(以避免重新启动),即使本地Web.config是源代码控制的,它也会replace本地的Web.config,这就是为什么OverwriteReadOnlyFiles被设置为True。 这一点实际上是有争议的。

2)为项目中的每个开发人员创build一个名为Web.[developer windows login].config的文件Web.[developer windows login].config 。 (例如在以下屏幕截图中,我有两个名为smo和smo2的开发人员):

在这里输入图像说明

这些文件(每个开发者1个)可以/应该是源代码控制的。 他们不应该被标记为依赖主Web.config,因为我们希望能够单独检查出它们。

每个这个文件都代表一个应用于主Web.Config文件的转换。 这里描述了转换语法: Web应用程序项目部署的Web.config转换语法 。 我们重复使用Visual Studio提供的这个很酷的Xml文件转换任务。 这个任务的目的是合并 Xml元素和属性,而不是覆盖整个文件。

例如,下面是一个示例web.[dev login].config ,不pipeWeb.config文件的其余部分如何,都会更改名为“MyDB”的连接string:

 <?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> 

现在,这个解决scheme并不完美,因为:

  • 在构build之后,开发者可能在本地具有不同的Web.Config而不是源控制系统
  • 当从源代码pipe理系统获得新的Web.Config时,他们可能不得不强制本地写入
  • 开发人员不应该检查/在主web.config。 它应该保留给less数人。

但至less,你只需要维护一个独特的主web.config加上每个开发人员一个转换文件。

App.config(不是networking)文件可以采取类似的方法,但我没有进一步详细说明。

在你的Web.config中使用其他文件的源代码

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

保持web.config版本控制,而不要为ConnectionStrings.config。 现在所有的开发人员都有一个连接string的文件。

您可以对本地依赖的所有设置执行此操作。

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

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

如何忽略文件,所以它永远不会被检入? 我遇到了类似的问题,并添加了web.config Subversion中的忽略列表。

但是在TFS中,这有点难,看到这篇文章如何做到这一点。

你可以应付的一种方法是有一个标记系统,并使用rake脚本来更改值。

一个更基本的方法可能是链接到你的web.config中的所有AppSettings的AppSettings.config文件(类似于连接)

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

然后有一个文件夹与您的每个开发人员有一个版本在一个子文件夹(即/ _configs / dave /)。 然后,当开发人员正在处理他们自己的代码时,他们从子文件夹复制到链接文件夹的根目录。

您需要确保您将更改传达给这些文件(除非您使用标记)。 如果您将AppSettings.config文件放在源代码pipe理之外,并且只检查开发者个人文件夹(所有这些文件夹),那么他们将被迫复制正确的文件夹。

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

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

  • 用testserver / production值检查web.config
  • 开发人员去Windows资源pipe理器,并更改该文件的只读模式
  • 编辑configuration以适应他们的环境。
  • 只有在部署值发生更改或添加或删除任何configuration条目时,才会检入web.config。
  • 这需要每个configuration条目的大量注释,因为它需要由每个dev改变

假设您正在使用Visual Studio,为什么不使用不同的解决schemeconfiguration? 例如:你可以有一个使用Web.config.debug的Debugconfiguration和一个使用Web.config.release的Releaseconfiguration。 Web.config.debug应该有类似的东西

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

使用文件Standard_Name_For_Config.config来显示所有的个人开发者设置,而Web.config.release总是具有生产设置。 您可以将默认configuration存储在某个源代码pipe理的文件夹中,并让新用户从那里进行访问。