ASP.NET 连接字符串部署最佳实践
我收集了（希望有用的）我为完成本文主题而研究的方法的摘要，以及我遇到的问题。请告诉我您是否找到了您更喜欢的其他方法，特别是如果它们解决了我提到的方法无法解决的问题。
将连接字符串保留在 web.config 中，并使用 XDT/msdeploy 转换根据我的活动构建配置（例如 web.PublicTest.config 文件）将它们替换为设置。我的问题是我将一些特定于服务器的设置合并并隐藏到一个具有许多配置元素的全局相同的文件中。此外，我无法在多个对等级应用程序之间共享连接字符串定义。
为 web.config 中的连接字符串指定 configSource="DeveloperLocalConnectionStrings.config" 值，XDT 会将该值转换为指向我的代码库中的多个特定于环境的文件之一。我的问题是，我将所有环境的密码发送到所有目的地（当然，除了 SVN），并且服务器上有未使用的配置部分等待意外使用。
machine.config 文件中的特定连接字符串而不是 web.config。问题：谁到底希望在 machine.config 中找到连接字符串，结果出现意外名称冲突的可能性很高。
指定 configSource="LocalConnectionStrings.config"，不转换该值，并编辑项目 xml 以排除连接字符串配置的部署。 http://msdn.microsoft.com/en-us/library/ ee942158.aspx#can_i_exclude_specific_files_or_folders_from_deployment - 这是我发现的最好的解决方案，可以满足我对专有（非分布式）Web 应用程序的需求，但我担心有一天另一位团队成员会来复制生产站点出于某种原因进行测试，瞧！现在正在 UAT 期间修改生产数据库。 （更新：我发现在这种情况下无法使用一键发布，只能使用带 -skip 参数的 msdeploy 命令行。排除上述文件与将其设置为“无”编译操作而不是“ Content”，并导致包从部署目标中删除它。）
连接部署包以提示输入连接字符串（如果尚未设置）（我还不知道如何执行此操作，但我了解这是可能的）。这将产生与上面 #4 类似的结果。
指定 configSource="..\ConnectionStrings.config"。非常适合我的需求，因为我可以在我选择的应用程序之间共享配置，并且我的应用程序目录中不会有任何特定于机器的内容。不幸的是，此属性中不允许使用父路径（就像它们用于“appSettings file="”' - 另请注意，您可以在 configSource= 引用中巧妙地使用 file=）。
ps 这里讨论了其中一些解决方案： ASP .Net配置文件->多个开发人员和部署服务器的连接字符串
I've collected a (hopefully useful) summary of the ways I've researched to accomplish the subject of this post, as well as the problems I have with them. Please tell me if you've found other ways you like better, especially if they resolve the problems that the methods I mention do not.
Leave connection strings in web.config and use XDT/msdeploy transformation to replace them with settings according to my active build configuration (for example, a web.PublicTest.config file). My problem with this is I merge and bury a few server-specific settings into an otherwise globally identical file with many configuration elements. Additionally, I cannot share connection string definitions among multiple peer-level applications.
Specify a configSource="DeveloperLocalConnectionStrings.config" value for connection strings in web.config, and XDT transform this value to point to one of the multiple environment-specific files in my code-base. My problem with this is I send passwords for all my environments to all destinations (in addition to SVN, of course) and have unused config sections sitting on servers waiting to be accidentally used.
Specific connection strings in the machine.config file rather than web.config. Problem: who the heck expects to find connection strings in the machine.config, and the probability of surprise name collisions as a result is high.
Specify a configSource="LocalConnectionStrings.config", do not transform the value, and edit the project xml to exclude deployment of the connection string config. http://msdn.microsoft.com/en-us/library/ee942158.aspx#can_i_exclude_specific_files_or_folders_from_deployment - It's the best solution I've found to address my needs for a proprietary (non-distributed) web application, but I'm paranoid another team member will come one day and copy the production site to test for some reason, and voila! Production database is now being modified during UAT. (Update: I've found I can't use one-click publish in this scenario, only msdeploy command line with the -skip parameter. Excluding a file as above is the same as setting it to "None" compile action instead of "Content", and results in the package deleting it from the deployment target.)
Wire the deployment package up to prompt for a connection string if it isn't already set (I don't know how to do this yet but I understand it is possible). This will have similar results to #4 above.
Specify a configSource="..\ConnectionStrings.config". Would be great for my needs, since I could share the config among the apps I choose, and there would be nothing machine-specific in my application directory. Unfortunately parent paths are not allowed in this attribute (like they are for 'appSettings file=""' - note also that you can spiffily use file= inside a configSource= reference).
p.s. some of these solutions are discussed here: ASP.Net configuration file -> Connection strings for multiple developers and deployment servers
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
使用 SQL Server 时，您还可以使用集成安全性/SSPI 并将 WebServer 计算机登录添加到 Sql Server。
这样您就不必在 web.config 中公开任何内容，并且可以像向任何其他数据库用户一样向该登录授予角色。
尽管您必须了解要采取的含义和安全注意事项，因为作为该计算机执行的任何恶意代码都将有权访问 Sql Server。
关于
奥莱
When using SQL Server, you can also use Integrated Security / SSPI and add the WebServer Computer Login to the Sql Server.
That way you dont have to expose anything in the web.config and you can grant roles to that login like you would to any other DB user.
Though you have to understand the implications and security considerations to be taken, because any malicious code executed as THAT machine will have access to the Sql Server.
with regards
Ole
使用主机名作为连接字符串的键，这样您就可以自动选择数据源。确保选择例程没有错误（更改主机名 - 测试！）...
不要将其放在 web.config 中，编写一个 ini 文件，这样就没有 XML 编码。
使用私钥/公钥 (RSA/PGP) 加密其中的密码。切勿使用明文或对称密钥，这同样糟糕。
Use the hostname as key for the connectionstring, that way you can choose the datasource automagically. Make sure the choosing routine is not buggy (change hostname - test!)...
Don't put it in the web.config, write an ini file, that way there is no XML encoding.
Encrypt the password therein, with private/public key (RSA/PGP). Don't ever use cleartext, or a symmetric key, which is just as bad.
查看我的以下博客文章： 保护 asp.net 计算机密钥和连接字符串
如果您确实使用 Quandary 的答案，请使用不在站点文件夹中的密钥，就像 asp.net 对受保护的配置部分所做的那样。
我们手动批准对进入暂存/生产的 web.config 的更改。我们尽可能使用集成的而不是基于用户名的，但我们在后一种情况下使用的一个选项是仅在 SVN 中使用用户名/密码的占位符。
我们过去使用过单独的配置文件，但我们在 web.config 修改方面遇到了其他类型的问题，因此我们最近将其锁定在单个文件中。
Check my following blog post: Protecting asp.net machine keys and connection strings
If you do use Quandary's answer, use a key that's not in the site's folder, just like asp.net does with protected config sections.
We manually approve changes to the web.config that go into staging/production. We use integrated instead of username based where possible, but an option we've used in the later case is to just have placeholders for the username/passwords in SVN.
We've used separate config files in the past, but we have run into other type of issues with web.config modifications, so we have been locking it in a single file lately.