跨不同开发环境（和 SVN）的 Web.Config
因此，我们有一个构建流程来处理不同环境中的不同开发 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
取决于当前使用代码的开发人员。
有什么想法吗？
So we have a build process that handles different development web.configs across different environments. We use the ConfigSource attribute and have Team City pick the appropriate file.
That's great, but what do I do when the developers have slightly different environments?
CI, can't help, because everyones getting it straight out of SVN (i.e. CI obviously doesn't build to each developers local machine).
I'll use the ConnectionStrings config section as an example:
<connectionStrings configSource=".\Config\ConnectionStrings.config">
</connectionStrings>
And we have:configs\ConnectionStrings.config (the generic one)
But I might need to use:
configs\ConnectionStrings.dev1.config
configs\ConnectionStrings.dev2.config
configs\ConnectionStrings.dev3.config
depending on which developer is using the code at the moment.
Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您是否尝试过查看 web.config 转换？他们可能能够提供您寻求的功能，同时仍将所有内容保留在版本控制中或需要任何代码更改。另外，它不仅适用于连接字符串，还适用于目录等。
Have you tried looking into web.config transformations? They might be able to provide the functionality that you seek while still keeping everything in version control or needing any code changes. Plus it will work for more things than just connection strings, but also directories, etc.
我们过去使用的一项技术（我记得 Ayende 在网络广播中提到过）是每个连接字符串都以开发人员的计算机名称命名，例如
在调试时我们会查找“当前”计算机的连接字符串名称姓名。
这可以节省多个连接字符串文件。相反，我们有一个包含多个连接字符串的文件。
One technique we've used in the past (I recall Ayende mentioning it on a web cast) is that each connection string is named with the developers machine name e.g.
When in debug we then look for a connection string name of the "current" machine name.
This saves having multiple connection string files. Instead we have one file with multiple connection strings.
就像您提到的那样，我们有一个单独的连接文件，其中包含当前计算机名称。
在需要连接字符串的项目的构建事件中，我们添加了一个预构建事件，该事件从当前项目中删除connection.config文件，在构建后事件中，我们将connections.machine.config复制到connections.config中当前项目文件夹。
在我们的 web.config 中，.NET 将在单独的文件中查找连接字符串信息。
Web.config 转换只能在实际部署项目时使用。 “默认”web.config 将始终在本地开发计算机上使用，因此这不是开发环境的选项。
您还可以将此机制扩展到应用程序设置和其他配置文件，方法是将机器特定的文件放置在解决方案文件夹中，然后在构建时复制它们。
We have a separate connection file just like you mentioned with the current machine name in it.
In the build event for the projects that need a connection string we've added a pre built event that deletes the connection.config file from the current project and in the post build event we copy connections.machine.config to connections.config in the current project folder.
In our web.config we have a so .NET will look in a separate file for the connection string information.
Web.config transformations can only be used when you actually deploy a project. The 'default' web.config will always be used on your local development machine so this is not an option for development environments.
You can extend this mechanism also to app settings and other config files by placing the machine specif ones in the solution folder and just copying them on build.