C# DLL 配置文件 [英] C# DLL config file

问题描述

我正在尝试将 app.config 文件添加到我的 DLL，但所有尝试都失败了.

Im trying to add an app.config file to my DLL, but all attempts have failed.

根据将配置信息放入 DLL"中的 MusicGenesis应该没有问题.所以很明显我做错了什么......

According to MusicGenesis in 'Putting configuration information in a DLL' this should not be a problem. So obviously I'm doing something wrong...

以下代码应该从我的 DLL 返回我的 ConnectionString:

The following code should return my ConnectionString from my DLL:

return ConfigurationManager.AppSettings["ConnectionString"];

但是，当我将 app.config 文件复制到我的控制台应用程序时，它工作正常.

However, when I copy the app.config file to my console application, it works fine.

有什么想法吗?

推荐答案

为 .DLL 创建 .NET 配置文件并非易事，这是有充分理由的..NET 配置机制内置了很多功能，以方便应用程序的轻松升级/更新，并保护已安装的应用程序不会相互践踏配置文件.

It is not trivial to create a .NET configuration file for a .DLL, and for good reason. The .NET configuration mechanism has a lot of features built into it to facilitate easy upgrading/updating of the app, and to protect installed apps from trampling each others configuration files.

DLL 的使用方式和应用程序的使用方式之间存在很大差异.您不太可能在同一台计算机上为同一用户安装多个应用程序副本.但是您很可能拥有 100 个不同的应用程序或库，它们都使用了一些 .NET DLL.

There is a big difference between how a DLL is used and how an application is used. You are unlikely to have multiple copies of an application installed on the same machine for the same user. But you may very well have 100 different apps or libraries all making use of some .NET DLL.

虽然很少需要在一个用户配置文件中单独跟踪应用程序的不同副本的设置，但您非常不太可能希望 DLL 的所有不同用法与共享配置彼此.因此，当您使用普通"方法检索 Configuration 对象时，您返回的对象与您正在执行的应用程序域的配置相关，而不是特定程序集.

Whereas there is rarely a need to track settings separately for different copies of an app within one user profile, it's very unlikely that you would want all of the different usages of a DLL to share configuration with each other. For this reason, when you retrieve a Configuration object using the "normal" method, the object you get back is tied to the configuration of the App Domain you are executing in, rather than the particular assembly.

应用程序域绑定到根程序集，该程序集加载了您的代码实际所在的程序集.在大多数情况下，这将是主 .EXE 的程序集，也就是加载 .DLL 的程序集.可以在应用程序中启动其他应用程序域，但您必须明确提供有关该应用程序域的根程序集是什么的信息.

The App Domain is bound to the root assembly which loaded the assembly which your code is actually in. In most cases this will be the assembly of your main .EXE, which is what loaded up the .DLL. It is possible to spin up other app domains within an application, but you must explicitly provide information on what the root assembly of that app domain is.

因此，创建特定于库的配置文件的过程并不那么方便.这与您用于创建不依赖于任何特定程序集的任意可移植配置文件的过程相同，但您希望使用 .NET 的 XML 架构、配置部分和配置元素机制等.这需要创建一个 ExeConfigurationFileMap 对象，加载数据以识别配置文件的存储位置，然后调用 ConfigurationManager.OpenMappedExeConfiguration 将其打开为新的配置 实例.这将切断自动路径生成机制提供的版本保护.

Because of all this, the procedure for creating a library-specific config file is not so convenient. It is the same process you would use for creating an arbitrary portable config file not tied to any particular assembly, but for which you want to make use of .NET's XML schema, config section and config element mechanisms, etc. This entails creating an ExeConfigurationFileMap object, loading in the data to identify where the config file will be stored, and then calling ConfigurationManager.OpenMappedExeConfiguration to open it up into a new Configuration instance. This will cut you off from the version protection offered by the automatic path generation mechanism.

从统计上讲，您可能正在内部环境中使用此库，并且您不太可能在任何一台机器/用户中让多个应用程序使用它.但是如果没有，您应该记住一些事情.如果您为 DLL 使用单个全局配置文件，无论引用它的应用程序如何，您都需要担心访问冲突.如果引用你的库的两个应用程序碰巧同时运行，每个应用程序都打开了自己的 Configuration 对象，那么当一个应用程序保存更改时，下次尝试检索或保存数据时将导致异常在其他应用中.

Statistically speaking, you're probably using this library in an in-house setting, and it's unlikely you'll have multiple apps making use of it within any one machine/user. But if not, there is something you should keep in mind. If you use a single global config file for your DLL, regardless of the app that is referencing it, you need to worry about access conflicts. If two apps referencing your library happen to be running at the same time, each with their own Configuration object open, then when one saves changes, it will cause an exception next time you try to retrieve or save data in the other app.

解决这个问题的最安全和最简单的方法是要求加载 DLL 的程序集也提供一些关于自身的信息，或者通过检查引用程序集的应用程序域来检测它.使用它来创建某种文件夹结构，以便为每个引用您的 DLL 的应用保存单独的用户配置文件.

The safest and simplest way of getting around this is to require that the assembly which is loading your DLL also provide some information about itself, or to detect it by examining the App Domain of the referencing assembly. Use this to create some sort of folder structure for keeping separate user config files for each app referencing your DLL.

如果您确定想要为您的 DLL 进行全局设置，无论它在哪里被引用，您都需要确定它的位置，而不是 .NET 自动找出合适的位置.您还需要积极管理对文件的访问.您需要尽可能多地缓存，仅在加载或保存所需的时间内保持 Configuration 实例，在此之前立即打开并在之后立即处理.最后，您需要一种锁定机制来保护正在由使用该库的应用程序之一编辑的文件.

If you are certain you want to have global settings for your DLL no matter where it is referenced, you'll need to determine your location for it rather than .NET figuring out an appropriate one automatically. You'll also need to be aggressive about managing access to the file. You'll need to cache as much as possible, keeping the Configuration instance around ONLY as long as it takes to load or to save, opening immediately before and disposing immediately after. And finally, you'll need a lock mechanism to protect the file while it's being edited by one of the apps that use the library.

这篇关于C# DLL 配置文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！