在类库的配置文件中指定连接字符串并在 ASP.NET Web 应用程序中重用/修改
如何在类库的配置文件中指定连接字符串,然后在 ASP.NET Web 应用程序中使用时修改它?
类库是一个数据访问层,它具有基于配置文件 (Settings.settings/app.config) 中指定的连接字符串连接到数据库的数据集。
该类库用于 Web 应用程序,用户输入数据并使用 DAL 类和 DAL 类将数据写入数据库。 类库中公开的方法。
现在,我想将此应用程序从开发环境迁移到测试环境,然后再迁移到生产环境。 我面临的问题是,迁移到测试后,测试中的应用程序仍然连接到开发数据库。 我已经更改了
有人可以解释实现这一目标的正确方法吗? 预先感谢您的任何帮助。 干杯。
How can one specify the connection string in a config file of a class library and later modify this when used in a ASP.NET Web Application?
The Class library is a data access layer that has a Dataset connecting to a database based on a connection string specified in a config file (Settings.settings/app.config).
This class library is used in a web application where user inputs data and is written to the database using the DAL classes & methods exposed in the class library.
Now, I want to migrate this application from development environment to testing environment and later to production. The problem I'm facing is that after migrating to testing, the app in testing still connects to development database. I've changed the connection string mentioned in <class library>.dll.config file but this seems to have no impact.
Can someone explain the right way to achieve this? Thanks in advance for any help. Cheers.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
对于 .config 文件,名称必须与主执行程序集匹配。 例如,我遇到了像您这样的情况,我需要一个类库将其设置放在 .dll.config 文件中。 虽然它能够引用它,但实际应用程序将无法读取配置文件,因为它需要 .exe.config。 将 .dll.config 重命名为 .exe.config 解决了该问题。
在您的情况下,将连接字符串从 .dll.config 迁移到 web.config 应该可以解决您的问题!
祝你好运!
With the .config files the name has to match the main executing assembly. For example I had a situation like yours, I needed a class library to have its settings in a .dll.config file. While it was able to reference it the actual application would not be able to read the config file because it was expecting .exe.config. Renaming the .dll.config to .exe.config fixed the problem.
In your case migrating your connection strings from .dll.config to web.config should fix your problem!
Good luck!
约书亚是部分正确的......对于后代,我想在这个答案中添加更多内容,因为我多次遇到过同样的问题。 首先,必须考虑他们的架构。 根据部署,您可能会在 ASP.NET 中的 .config 文件中遇到多个问题。
考虑架构影响:
单层(一台服务器):
一个简单的 Web 应用程序也许能够利用对站点 Web.config 文件的引用并解决您的问题。 对于单层应用程序来说,这将是一个很好的解决方案。 对于用作 .exe 文件的 Windows 应用程序,App.config 也将起作用。
多层(多个服务器):
当我第一次跨边界使用 .config 文件时,事情变得有点棘手。 记住配置结构的层次结构并牢记这一点 (关于 .Config 结构的 MSDN 文章) - 在相应的 ASP.NET 文件夹的根目录下有一个 machine.config。 它们驻留在每台物理服务器上。 这些被站点 Web.config(或 App.config)覆盖,而站点 Web.config(或 App.config)又被子文件夹 .config 文件覆盖。 如果您有多个 .config 文件,您可能需要使用其中一种方法来传递您要使用的特定 .config 文件的文件路径。 更重要的是,这些文件每个都可能具有连接信息。 ASP.NET 的 machine.config 保存了框架的一些内容......所以您至少应该对这是一个“继承”链这一事实保持敏感。 其次,部署后对 Web.config 文件的任何更改都会通知应用程序重新启动。 这将导致状态丢失(如果网站上有活跃用户,则情况会很糟糕)。 解决这个问题的方法是保留一个单独的.config 文件(例如connections.config)并将对该文件的引用放入Web.config 中。 这将允许您更改连接信息(例如密码),而无需重新启动应用程序。 以下是更多信息的链接: MSDN:工作与配置文件。 本文列出了在普通服务器/IIS 部署的应用程序中需要了解的所有详细信息。 请记住,.config 文件主要用于应用程序,而不是库。 如果您有多个层,那么您很可能正在使用某些通信/消息传递层(例如 WCF)。 这将拥有/允许其自己的 Web.config。 您可以将连接字符串保留在那里(并在需要时对其进行加密),但更好的是,将它们放在 Web.config 引用的第二个文件中以实现可管理性。 最后一点,如果您打算考虑云,.config 文件会被打包用于应用程序部署,这实际上消除了它们在“无需重新启动或重新部署”方面提供的所有好处。 Azure 部署需要考虑这篇文章,以避免维护的噩梦:Bill Lodin 博客 - Azul / Cloud 中的配置文件。 本文的另一点是关于如何根据部署以编程方式选择配置的绝佳示例! 如果您想增加在云中或云外部署的灵活性,请务必检查一下。
我希望这些要点可以节省大家的时间并减少头痛。 我知道我浪费了几天的编程时间来处理这些问题......并且很难在一个地方找到可能应用程序没有“实现”其连接对象的所有原因。 希望这能让你们免于和我一样的命运。
Joshua is partly right ... For posterity I would like to add a bit more to this answer as I have delt with the same problems on several occasions. First, one must consider their architecture. There are several issues you can run into with .config files in ASP.NET based on deployments.
Considering the architectural ramifications:
Single tier (one server):
A simple web application may be able to leverage a reference to the sites Web.config file and resolve your issues. This would be a fine solution for a single tier application. In the case of a windows application leveraged as a .exe file, the App.config will work too.
Multi-tier (more than one server):
Here is where things became a bit hairy for me the first time I was working with .config files across boundries. Remember the hierarchy of the config structure and keep this in mind (MSDN Article on .Config structure) - there is a machine.config at the root in the appropriate ASP.NET folder. These reside at each physical server. These are overridden by the site Web.config (or App.config) which are in turn overridden by subfolder .config files. If you have more than one .config file you may want to use one of the methods to pass the file path for the specific .config you want to use. More importantly, these files each may have connection information. ASP.NET's machine.config holds some for the framework ... so you should at least be senstive to the fact this is an "inheritance" chain. Second, any changes to the Web.config file once deployed will tell the application to restart. This will result in loss of state (bad if you have active users on the site). The way around this is to keep a separate .config file (e.g. connections.config) and put a reference to that file in the Web.config. This will allow you to change the connection information (e.g. password) without having to restart the application. Here is a link to more info: MSDN: Working with Configuration Files. This article lays out all the details you need to be aware of in a normal server / IIS deployed application. Keep in mind that the .config files are mainly intended for applications, not libraries. If you have several tiers, chances are you are using some communicaiton / messaging layer (e.g. WCF). This will have / allow its own Web.config. You can keep connection strings there (and encrypt them if needed), but better yet, put them in a second file referenced by the Web.config for manageability. One final point, if you are ever going to consider the cloud, .config files are wrapped for application deployments which in effect removes all of the benefits they offer in terms of "not having restart or redeploy". Azure deployments will want to consider this article to save themselves from nightmares of maintenance: Bill Lodin blog - Configuration files in Azul / Cloud. One other point on this article – great example on how to programmatically select configuration depending on deployment! Be sure to check that out if you want to add flexibility to deploy in or out of the cloud .
I hope these points saves all of you time and headaches. I know I lost a couple days of programming time dealing with these issues ... and it was hard to find all the reasons in one place why may app was not "implementing" its connection object. Hopefully this will save you all from the same fate I had.