共享配置文件和跨企业的数据库连接字符串
我们公司有多个应用程序（Web 和控制台/Windows），它们都连接到同一组数据库。我试图找出存储/访问/管理各种数据库连接字符串的最佳方法，以便它们可以在所有应用程序之间共享。
目前，我们的连接字符串位于所有服务器上的 machine.config 文件中。虽然这消除了在每个应用程序的配置文件中包含这些连接字符串的需要，但我们仍然必须在每个服务器上具有相同的设置块，并且每个服务器有 4 个不同的版本，我们必须将它们包含在（32 位/64 位）中、2.0 和 4.0 框架）。此外，每个服务器都有自己的环境（开发、QA、生产），因此这些设置必须保持独立。这累积起来，当需要改变时就变得难以管理。
理想情况下，最好在每台服务器上都有一个中央位置（可能在网络上共享），其中存储这些数据库连接字符串（可能还有其他信息）。我研究了几个选项，但每个选项都有局限性：
这看起来不错，但仅适用于 app.config 和 web.config 级别，并且不支持绝对（或 UNC ) 路径。如果我们能让它指向服务器上的中心位置，那么这可能会起作用。但据我了解，它必须位于应用程序根目录以下的位置，并且必须是相对路径。我读到有关使用文件链接的内容，如果我们在更改后部署每个应用程序，这将起作用，但我们不想这样做 - 我们希望能够将文件部署到一个位置（每个服务器，最坏的情况）并完成。
理论上，这听起来像什么我们想要。但我发现对它的支持非常少，所以我想知道这是否已被弃用，是否无法按照我的想法工作，或者是否不被推荐。
其他人如何共享这样的配置值，有没有办法使用上述任何方法来执行我所描述的操作？适合我们情况的最佳实践是什么？
提前致谢。
Our company has several applications -- both web and console/windows -- that all connect to the same set of databases. I'm trying to figure out the best way to store/access/manage the various database connection strings so that they can be shared across all of the applications.
Currently, we have our connection strings in machine.config files on all of our servers. While this eliminates the need to have these connection strings in each application's config file, we still have to have the same block of settings on each server, and each server has 4 different versions we have to include these in (32-/64-bit, 2.0 and 4.0 frameworks). Additionally, each server has its own environment (dev, QA, production), so these settings have to be kept separate. This adds up, and becomes hard to manage when changes are needed.
Ideally, it would be nice to have a central location on each server -- maybe shared on a network -- where these database connection strings (and possibly other info) are stored. I've looked into a few options, but each of them has limitations:
configSource and appSettings file
This seems nice, but only works at the app.config and web.config level, and does not support absolute (or UNC) paths. If we could get this to point to a central location on the server, then this may work. But as I understand it, it must live in a location below the application root, and must be a relative path. I read about using a file link, and this would work if we deployed each app after a change, but we don't want to have to do that -- we want to be able to deploy the file to one location (per server, worst case) and be done.
In theory, this sounds like what we want. But I'm finding very little support for it, so am wondering if this has been deprecated, doesn't work as I'm thinking, or isn't recommended.
How do others go about sharing configuration values like this, and is there a way to use any of the methods above to do what I described? What are best practices for our situation?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
根据这篇文章，这是不可能的。
http://social. msdn.microsoft.com/forums/en-US/netfxbcl/thread/1cad3740-12f5-4859-ba02-717c4b418a8c/
现在，如果您想研究“拖拉机拖车”版本的配置，请继续关注这只兔子漏洞：
http://msdn.microsoft.com/en-US/vstudio/bb499684 .aspx
配置服务
或（相同的东西，但查找方式不同）
google 或 bing 这个
stocktrader msdn“配置服务”
它不适合温和的人。但这都是关于将配置更改部署到大型环境。
Based on this post, this isn't possible.
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/1cad3740-12f5-4859-ba02-717c4b418a8c/
Now, if you want to research a "tractor trailer" version of configuration, go down this rabbit hole:
http://msdn.microsoft.com/en-US/vstudio/bb499684.aspx
Configuration Service
or (same thing, but a different way to look for it)
google or bing this
stocktrader msdn "Configuration Service"
It's not for the mild hearted. But is all about deploying configuration changes to large environments.
希望这会有所帮助，尽管它可能与所提出的问题完全不同。
为了管理跨各种环境的配置，我们使用了一种非常好的方法，该方法利用了 maven 和 Jenkins 等构建自动化工具，以及一个简单的 java 程序和一些 bash 脚本。
我们创建了一个包含所有环境（DEV、QA、PROD）的各种属性的字典，它将应用于包含所有环境的配置文件列表的通用模板，Java 程序替换了模板中的占位符，字典中的值，为所有环境创建配置文件，因此所有配置现在都在我们创建的字典的代码级别进行管理。
Java程序在maven构建中执行，它还会复制我们在生成的配置文件中可能需要的任何其他资源（例如证书），整个过程通过Jenkins打包并部署在服务器中，最后bash 脚本的一部分会将配置文件放置在正确的文件夹中，从而使一切自动化。
Hope this helps, though it might exactly not be the same as the question asked.
To manage configurations across various environments, we used a very good approach that utilized build automation tools like maven and Jenkins, and a simple java program along with some bash scripting.
We created a Dictionary that contained various properties for all environments(DEV, QA, PROD), it was to be applied on a general template that contained a list of configuration files for all environments, the Java program replaced placeholders in the template, with the values in the dictionary, to create configuration files for all the environments, so all the configurations are now managed at code level from the dictionary we created.
the Java Program was executed inside of a maven build, which would also copy any other resource that we might need in the produced configuration files(such as certificates), the whole thing was packaged and deployed in the server through Jenkins, where in the last part the bash scripts would place the configuration files in the right folder, thus automating everything.