Question

现在我们的测试和生产数据库位于同一台服务器上，但名称不同。部署意味着编辑Web.config以更改正确数据库的所有连接字符串。我经常忘记的一步......

我们最终创建了一个用于测试的新数据库服务器，我正在移动数据库...但现在服务器将会有所不同，我们仍然需要处理连接字符串问题。

我正在考虑通过主机文件来管理它，但是当我需要对生产数据进行测试时想到在我的台式机上切换它似乎很麻烦。

所以我只是想知道是否有更好的方法。使用“生产”Web配置进行部署的东西将是理想的......

Answer 1

使用Web Deployment Project并使用一些后期构建任务更新wdproj文件（它只是一个MSBuild文件）以输出正确的.config文件。我保留了web.config和web.release.config，然后在wdproj文件中使用它：

<Target Name="AfterBuild">
    <Copy Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\web.release.config" DestinationFiles="$(OutputPath)\web.config" />
    <Delete Files="$(OutputPath)\web.release.config" />
</Target>

More information

一个更简单的解决方案就是使用configSource property of appSettings and connectionStrings，然后永远不会覆盖生产服务器上的那个文件。

Answer 2

我通常有三个独立的网络配置：一个用于我的开发机器，一个用于QA，一个用于生产。开发一个连接到我的本地SQL数据库（从外部防火墙），它是默认的web.config。其他名为web-prod.config和web-qa.config。发布后，我删除了我不需要的两个，并将正确的一个重命名为web.config。如果我忘了，应用程序会在第一次尝试访问数据库时中断，因为默认配置引用了无法访问的数据库。

由于IIS拒绝提供名为.config的文件，因此我确保它们都以.config结尾，而不是说web.config-prod或web.config-qa。

Answer 3

这是你可以尝试的另一件事：

使用SQL Server配置管理器为开发数据库创建数据库别名，以便开发框和生产服务器上的web.config文件可以相同。

Answer 4

我在每台服务器上创建一个数据库别名，指向数据库。然后我在我的web.config文件中使用此别名。如果我需要更改应用程序指向的数据库，那么我更改别名而不是web.config。

对于SQL Server，请转到SQL Server配置管理器＆gt; SQL Native Client配置＆gt;别名＆gt;创建新别名。

您可以使用tnsnames文件对Oracle执行相同的操作。

Answer 5

为每个环境提供具有单独配置的环境文件夹

为环境部署正确的

Answer 6

我经常这样做，我把生产服务器上的web.config设为只读。

Answer 7

我现在已经在一些地方将它们存储在注册表中。

现在可能有更复杂的方法，但是我用1.0 / 1.1遗产编写的很多代码都存储了注册表中的字符串。

注册表有一些优点

它使人们不会将代码部署到错误的位置，因为未正确配置的计算机将缺少密钥
它消除了开发人员意外打包带有开发连接字符串的web.config文件的问题（随后在半夜发出疯狂的电话，其中显示深夜系统管理员没有回来以前的web.config和开发人员不知道或不记得生产字符串）
它限制了黑客通过从机器上获取web.config来获取连接字符串的可能性。此外，注册表具有比文件系统更高级别的安全性。

Answer 8

我们从CI服务器驱动部署。我们通常为每个位置都有一个单独的文件，并让CI服务器切换到相应的配置，具体取决于传递给它的参数。所有文件编辑都是在NAnt脚本中完成的，因此开发人员可以在他们的机器上运行sam build来获得自己的设置。

Answer 9

我将把我的连接字符串放在我们的QA和Production框中的machine.config中。不过，我会将它们放在我的开发盒上的web.config中以获得灵活性。然后，我将使用Web部署项目在部署到QA时用任何内容（无连接字符串）覆盖我的dev连接字符串。因此，QA站点依赖于machine.config中的连接字符串。我仍然手动部署到生产，以确保一切都成功。我这样做是通过手动将所有内容从QA（web.config除外）复制到生产中。

Answer 10

这类任务正是构建事件旨在解决的问题。考虑构建为特定目标的构建，应在那里执行任何特定于目标的配置。（通常需要注意的是，规则总有一些例外）

Answer 11

我最近一直倾向于在持续集成服务器上进行配置操作。那是因为我们遇到了多个web.config，web.qa.config，web.production.config的问题，保持95％的文件应该是同步的。

简而言之：源代码管理中只有一个web.config，它是开发配置（调试友好，本地数据库等）。构建服务器执行编译，然后部署到canary站点，然后执行候选发布包。

我们正在使用nant，所以它是.build文件，它有xmlpoke来设置debug =“false”，更改连接字符串，以及在canary副本和web.config的打包副本中需要更改的任何其他内容。

构建机器的部署被称为“金丝雀”，因为如果出现问题，它首先会死掉。

在部署ASP.NET站点时如何处理连接字符串？

11 个答案: