我知道这里已经有很多关于这个主题的问题(我已经阅读了我能找到的尽可能多的问题)，但我还没有弄清楚如何最好地满足我的特定标准。以下是目标:
ASP.NET 应用程序将在几个不同的 Web 服务器上运行，包括用于开发的 localhost 工作站。这意味着使用机器 key 加密 web.config 已经过时了。 Web 服务器的每个“类型”或环境(dev、test、prod)都有自己对应的数据库(dev、test、prod)。我们希望将这些连接字符串分开，以便处理“dev”代码的开发人员无法看到任何“prod”连接字符串密码，也不允许将这些生产密码部署到错误的服务器或提交给 SVN。 应用程序应该能够根据服务器名称(使用 switch 语句)决定尝试使用哪个连接字符串。例如，“localhost”和“dev.example.com”应该知道使用 DevDatabaseConnectionString，“test.example.com”将使用 TestDatabaseConnectionString，而“www.example.com”将使用 ProdDatabaseConnectionString，例如。这样做的原因是为了限制任何部署事故的机会，其中错误类型的 Web 服务器连接到错误的数据库。 理想情况下，完全相同的可执行文件和 web.config 应该能够在这些环境中的任何一个上运行，而无需在我们每次部署时分别定制或配置每个环境(似乎很容易忘记/搞砸的东西在部署期间的某一天，这就是为什么我们不再只拥有一个必须在每个目标上更改的连接字符串)。部署目前是通过 FTP 完成的。更新:使用“构建事件”并修改我们的部署程序可能不是一个坏主意。 我们将无法通过命令行访问生产 Web 服务器。这意味着使用 aspnet_regiis.exe 加密 web.config 已失效。更新:我们可以以编程方式执行此操作，因此这一点没有实际意义。 我们希望在密码更改时不必重新编译应用程序，因此使用 web.config(或 db.config 或其他)似乎最有意义。 开发人员应该无法获得生产数据库密码。如果开发人员在他们的 localhost 笔记本电脑上检查源代码(这将确定它应该使用 DevDatabaseConnectionString，还记得吗？)并且笔记本电脑丢失或被盗，应该不可能获得其他连接字符串。因此，不能考虑使用单个 RSA 私钥来解密所有三个密码。 (与上面的 #3 相反，如果我们走这条路，我们似乎确实需要三个单独的 key 文件；这些可以在每台机器上安装一次，如果错误的 key 文件被部署到错误的服务器，最糟糕的是应该发生的情况是应用程序无法解密任何内容——并且不允许错误的主机访问错误的数据库!) 更新/补充:该应用程序有几个单独的面向 Web 的组件:一个经典的 ASMX Web 服务项目、一个 ASPX Web 窗体应用程序和一个较新的 MVC 应用程序。为了不为每个单独的环境在每个单独的项目中配置相同的连接字符串而发疯，最好让它只出现在一个地方。 (可能在我们的 DAL 类库或单个链接的配置文件中。)
我知道这可能是一个主观问题(要求做某事的“最佳”方式)，但考虑到我提到的标准，我希望确实会出现一个最佳答案。
谢谢! 集成身份验证/Windows 身份验证是一个不错的选择。没有密码，至少没有密码需要存储在 web.config 中。事实上，这是我更喜欢的选项，除非管理员明确将其从我这里拿走。
就个人而言，对于因机器而异的任何内容(不仅仅是连接字符串)，我使用以下技术从 web.config 中放入外部引用:http://www.devx.com/vb2themax/Tip/18880
当我把代码扔给生产服务器管理员时，他得到了一个新的 web.config，但没有得到外部文件——他使用了他之前的那个。
