抱歉，如果这是重复的，但我没有设法找到直接问这个问题。
这里的一般意见（我和我对面的他）是他们不应该这样做，原因是 DLL 可以共享；因此，在 DLL 中包含特定于应用程序的信息的想法是无稽之谈。如果信息不是特定于应用程序的，则可以使用常量。
另一个问题是，假设 DLL 没有自己的配置文件，DLL 是否应该使用加载 DLL 的可执行文件的配置文件，或者将相关数据作为某种构造函数的一部分传递。我们的观点是后者，因为它更易于测试，缺点是有时需要将大量数据传递给 dll。
意见？
【问题讨论】：
标签： dll configuration
就“使用配置文件进行简单配置”和“可测试”而言，您没有理由不能两全其美。有一个静态方法，可以从配置文件创建实例，但也提供了一个构造函数来实现更多的控制和可测试性。静态方法只会获取设置并调用构造函数。
我相信可以像任何其他项目一样为 DLL 创建设置类，然后您只需将实际文本放入应用程序的配置文件中，而不是为 DLL 创建一个。基本上忽略为库项目生成的 app.config，除非用作应用程序中心的模板。
或者，使用 Spring.NET 之类的东西来管理这类事情 :)
【讨论】：
通常，我想您应该将相关信息传递给您正在调用的函数，或者在您正在创建的、在 DLL 中定义的对象中设置相关属性。我想这就是为什么 .NET 并不真正支持 DLL 的配置文件（您可以创建它们，但它们在运行时不会被使用）。
我有一个场景，DLL 正在读取配置文件，但这是非常特殊的：.NET DLL 将对象导出为 COM 对象以供 Microsoft Navision 使用。它使用 XML-RPC 接口与保理银行进行通信。
虽然 DLL 安装在每个用户的机器上，但接口的配置对所有用户都是通用的，因此我将配置放置在映射到每台 PC 的网络驱动器上，并且配置（URL、凭据等）从那个公用文件中读取。
这是否是好的做法取决于读者，但在那种情况下，拥有一个通用配置文件才有意义...
【讨论】：