正文

.Net代码控制PrivateBinPath和ConfigurationFile的位置

IP云
IP云V管理员/4 阅读
11/29
提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

.Net的WinForm程序有的时候让人很烦的是，在执行目录下总是一大堆的DLL，配置文件，最少则是个以下，多的时候怕有四五十个吧……，自己程序中的类库，第三方的类库……加载一起让人感觉乱糟糟的，非常不爽。在下虽然在个人卫生上没有什么洁癖，可是对于应用程序的这个样子确实没有一点容忍力的，是可忍孰不可忍啊！

处理这些DLL还是比较简单的，Configuration文件里就可以配置了。先将DLL分门别类，Core, Module, Misc等等，然后将这几个目录名称加入App.config中。如： 

<runtime>

  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

    <probing privatePath="Castle;Core;Module;UI;Misc;"/>

  </assemblyBinding>

</runtime>

嗯，现在看上去就舒服多了，各就各位的，清爽！慢……在主目录下，出了我们的应用程序Exe可执行文件外，还有一个例外，app.config…… 多少还是有点儿不爽，怎么办呢？我们建个Data目录，将config文件移动进去吧~！说做就做，我们就把app.config移动到下级目录了，开心啊，看看程序能运行不？ 杯具发生了，程序运行毫无反应…… 用VS调试之，发现是找不到其他类库中的类型导致的。也是，我们刚刚在config文件中加了privatePath，现在有把这个文件移动了，怎么能加载到其他目录下的DLL呢？

知道原因了，当然就好解决。据说configuration文件的位置是可以指定的。AppDomainSetup.ConfiguraitonFile属性就是指的这个。让我们来试试……

分析一下：

要改config的路径，当然是要在使用config之前咯，而且越早越好…… 哪里比较早呢？嗯，Main函数，程序的入口是个不错的选择…… 

static class Program

{

     /// <summary>

    /// 应用程序的主入口点。

    /// </summary>

    [STAThread]

    static void Main()

    {

        AppDomain.CurrentDomain.SetupInformation.ConfigurationFile = "Data\MyApp.Config";

        Application.Run(new MyAppForm());

    }

}

好，编译，信心满满的再次运行程序，可是杯具再一次啊发生了，依然没有反应……

……在此调试，惊奇的发现这个属性设置居然完全没有效果，语句执行完后，该属性值依然是默认值。于是查文档啊，百度啊，谷歌啊~ 最后终于知道设置config的正确方法。 

AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", path);

嗯，这个这个……不是微软在害人吗…… 好了，停下抱怨继续工作先…… 嗯，看到了，config文件的位置生效了，指向了我们预定的位置，可是………… 杯具毫无意外的再次发生……DLL依然不能加载！

虽然我已经在AppDomainSetup里看到了PrivateBinPath属性，可是我却一点兴奋感觉都没有，应该跟前面的结果类似把！

想想程序运行的过程，PrivateBinPath是AppDomain.Current.SetupInformation里的属性，而这个属性只有在AppDomain.Create的时候才会生效，在AppDomain已经建立后更改config的路径再去设置这个值，应该是不行的。看来只好代码里来设置了。可是如何下手呢？

关门， 放Reflector！呵呵，让我们看看AppDomain内部的情况。果其不然啊！SetupInforamtion只是其内部配置的一个Copy，这也就解释了为什么更改属性却没有生效的原因！ 

public AppDomainSetup SetupInformation

{

    get

    {

        return new AppDomainSetup(this.FusionStore, true);

    }

}

看起来不动用终极手段是不行的了！反射！更改内部字段来达到我们的目的！仔细检查了以下代码，发现AppDomain内部的Setup信息是保存在一个FunsionStore的Internal属性里的。好，我们就从这里动手把！ 

AppDomain.CurrentDomain.SetData("PRIVATE_BINPATH", "Castle;Core;Module;UI;Misc;");

AppDomain.CurrentDomain.SetData("BINPATH_PROBE_ONLY", "Castle;Core;Module;UI;Misc;");

这段代码确实就更改了AppDomain.CurrentDomain.SetupInformation.PrivateBinPath的值了，可是运行发现类型还是不能加载！可能内部还有个什么RefrefshConfiguraiton或UpdateCache之类的方法来刷新！继续找啊找的~ 终于发现了。是一个static extern的方法。呵呵……这下简单了，看代码！

在调试过程中，我们还发现Main方法不是最好的地方，所以我们将代码放在了Program的静态构造方法中，这里是除了静态字段外的最早的起始地了。 

static Program()

{

    AppDomain.CurrentDomain.SetData("PRIVATE_BINPATH", "Castle;Core;Module;UI;Misc;");

    AppDomain.CurrentDomain.SetData("BINPATH_PROBE_ONLY", "Castle;Core;Module;UI;Misc;");

    var m = typeof(AppDomainSetup).GetMethod("UpdateContextProperty", BindingFlags.NonPublic | BindingFlags.Static);

    var funsion = typeof(AppDomain).GetMethod("GetFusionContext", BindingFlags.NonPublic | BindingFlags.Instance);

    m.Invoke(null, new object[] { funsion.Invoke(AppDomain.CurrentDomain, null), "PRIVATE_BINPATH", "Castle;Core;Module;UI;Misc;" });

}

嗯，迫不及待的编译，运行！哇！毫不意外的，程序正常了，再看看应用程序目录，只有一个干干净净的exe文件的存在，真是爽到极点~

告诉你，exe文件就一个，我可以！哈哈！

最后提醒，如果Program里有静态字段，不要定义为用其他类库的类型，因为这个时候我们上述的方法还没有执行到，会因为找不到类型而出错的哦~

相关阅读

目录[+]