【问题标题】:.NET 3.5 DLL using its own config file.NET 3.5 DLL 使用自己的配置文件
【发布时间】:2010-12-05 09:09:09
【问题描述】:

我需要一个 .NET 3.5 DLL 有自己的配置文件。可以从许多不同的应用程序调用此 DLL,因此存储在配置文件中的信息(如连接字符串)需要保存在 DLL 可以引用的配置文件中。我想要的是当使用 DLL 时,我需要将用于引用信息的配置文件“切换”为 DLL 配置文件。然后,当 DLL 使用完配置信息后,切换回默认值。 DLL 是使用 .NET 3.5 编写的。我一直在寻找如何做到这一点,而我一直在寻找的是如何将信息与 exe 的 app.config 文件合并。就我而言,我不知道如何使用这个 DLL 来修改任何 exe 的 app.config 文件。此解决方案需要独立。但是,用于创建 DLL(包含业务对象)的基类期望在配置文件中查找连接字符串和其他信息,这就是为什么我需要在它的时候“切换”到我的 DLL 配置文件被访问然后将其切换回来,这样我就不会弄乱调用 DLL 的 exe 应用程序。

【问题讨论】:

    标签: .net-3.5 dll configuration-files


    【解决方案1】:

    我知道这篇文章有点老了,但我想投入我的 2 美分。虽然在某些情况下,我同意应用程序应该提供设置,而不是 dll。我发现了一种情况,而 dll 特定的配置似乎更可取。

    我们使用 Quartz.NET 的调度/任务应用程序。我们开发了一个界面来创建和监控 Quartz 服务器上的作业。 Quartz.NET 的一大优点是您创建“作业”程序并将它们编译成 DLL,然后将它们放入 Quartz.NET 服务器文件夹中,通过反射等,Quartz 能够开始使用新的 DLL无需对 Quartz 服务器进行任何额外的调整……如果没有需要保存在配置文件中的信息。

    对于 Quartz 服务器,如果您有任何特定的配置信息应该保存在配置文件中,则必须将其放入 Quartz.NET 配置文件中。我们已经创建了几个“工作”应用程序,每个应用程序都有自己的配置信息位,所以现在我们的 Quartz.NET 配置文件充满了所有这些不相关的设置。拥有一个 dll 特定的配置文件将大大减少 Quartz.NET 服务器的混乱。我看到的唯一其他选择是将所有这些单独的设置添加到设置数据库表中,但是为了整合和维护代码,出于我们的目的,单独的配置文件是更可取的。

    只是把它扔在那里考虑。

    【讨论】:

      【解决方案2】:

      .NET 2.0 及更高版本的配置系统为您提供了功能 - 例如,您可以按需加载特定的配置文件。这需要更多的工作 - 但它确实有效。

      你必须这样做:

      // set up a exe configuration map - specify the file name of the DLL's config file
      ExeConfigurationFileMap map = new ExeConfigurationFileMap();
      map.ExeConfigFilename = "ConfigLibrary.config";
      
      // now grab the configuration from the ConfigManager
      Configuration cfg = ConfigurationManager
                         .OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
      
      // now grab the section you're interested in from the opened config - 
      // as a sample, I'm grabbing the <appSettings> section
      AppSettingsSection section = (cfg.GetSection("appSettings") as AppSettingsSection);
      
      // check for null to be safe, and then get settings from the section
      if(section != null)
      {
         string value = section.Settings["Test"].Value;
      }
      

      您还需要确保正在构建类库 DLL 的配置并将其复制到您可以获取的位置。在最坏的情况下,您需要指定一个特定的配置文件,并通过在 Visual Studio 属性窗口中设置其“复制到输出目录”属性来确保将其复制到输出目录。

      您还应该在 CodeProject 上查看 Jon Rista 关于 .NET 2.0 配置的三部分系列。

      强烈推荐,写得很好,非常有帮助!

      马克

      【讨论】:

      • 这听起来很有希望使用这种方法。不过我有一个问题,我不需要“撤消”这个吗?我的 DLL 配置会成为查找的“默认”配置吗?
      • 否 - 您必须从 ConfigurationManager 显式请求“配置”对象,并且只有在处理这个单独的对象时,您才能获得这些单独的设置。
      【解决方案3】:

      您不能使用内置的 .Net 配置系统来执行此操作。它旨在(应该如此)配置应用程序进程,而不是单个 Dll。解决此问题的正确方法是将 dll 的配置设置添加到 app.config 系统中,以便为每个“使用”(引用)该 dll 的可执行应用程序。 (或在 machine.config 中)

      • 只需使设置可访问 适用于所有使用 dll 的应用程序 可以通过把它们来完成 在 Machine.config 中(在 C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG 对于.Net2.0

      如果您不想那样做,那么您将不得不编写自己的代码来打开、读取和写入自定义 Xml 文件(或您选择使用的任何格式)来提取这些设置.

      【讨论】:

      • 啊,你可以 - 这有点工作,而且不像 app.config 故事那样出色和无缝 - 但它确实有效。大多数时候,我同意 - 主机应用程序应该提供配置。我确实看到了单独的库特定配置也很有意义的情况。
      【解决方案4】:

      通常,当您在应用程序级别进行设置时,您需要在应用程序级别生成这些设置,然后将它们渗透到您的库中。它在您的初始化中添加了几行代码以注入依赖项,但您实际上是在尝试这样做。

      如果您尝试在库的每次部署中同时包含一个仅用于 dll 的配置文件,那么您将遇到比其价值更多的问题,而且它在语义上没有多大意义。

      以 System.Data 为例...当您创建连接时,您指定了连接字符串,而不是为仅连接字符串创建单独的配置文件以与 System.Data 库并排部署。 [这会导致大量问题,因为它很可能驻留在您系统上的 GAC 中]

      【讨论】:

        【解决方案5】:

        对此最简单的答案是将值放在 machine.config 中。这样,所有使用 dll 的应用程序都将能够通过 .net 应用程序配置类访问信息。通过这种方式,如果您绝对需要覆盖某个应用程序的值,您可以在主应用程序的 app.config 文件中覆盖它。

        【讨论】:

          猜你喜欢
          • 2010-10-06
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2011-07-18
          相关资源
          最近更新 更多