动态加载是遇到的最恶心的问题了,由于之前没有接触过这类技术,没接触就要用它来开发,是真的有点困难啊,所幸的是给的时间比较长,心里还能多少给自己的小小安慰。没有看专业的书,在开始的几天里,疯狂的Google相关的内容。其实我对网上的信息是颇有怨念的,几天疯狂下来,总结起来发现真正的文章就是那么两三篇,然后就是你抄我,我抄他的,最可恶的是完全ctrl-c+ctrl-v,抄的时候也不把自己的见解加上去。就比如在一篇文章的最后作者提出一个缺陷,就是在remoting的代理中返回一个assembly,作者提出在有些时候会出现错误,我在做例子的时候就遇到这问题,由于新手,还不能自己拿出解决方法,只能再问Google大神,结果一大堆的文章都是相同的,没一个提出解决方法或者问题所在。可见大家都是一样的懒啊。

  在开始几天按照网上的例子做了一遍后,就开始正式动工了。不过没有系统的学习过,有些知识是似懂非懂的,常常遇到很多很纠结的问题。那时候真是白天也问题,晚上也问题,在网上疯狂的Google,疯狂的提问题,然后按照自己的猜测、网友的帮助终于磕磕碰碰的完成了。

  上传的dll我们可以通过反射对它进行加载,在C#中,由于存在托管代码的自动垃圾回收机制,它并不提供释放资源的函数,一切都由垃圾回收来做。因此我们对dll加载后,只要当程序接受才能被释放,也就是说我要跟换dll到新版本时,我必须先接受程序,重新启动后才可以,这明显不是我所需要的。幸好的,AppDomain能解决这个问题。

  AppDomain的创建非常简单:

     AppDomainSetup setup = new AppDomainSetup();
            setup.ApplicationName = this.Name + ":" + this.Version;
            setup.ShadowCopyFiles = "false";
            setup.LoaderOptimization = LoaderOptimization.SingleDomain;
            setup.DisallowBindingRedirects = false;
            setup.DisallowCodeDownload = true;

            setup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory;
            setup.PrivateBinPath = this.WorkPath;
            setup.CachePath = setup.ApplicationBase;
            setup.ConfigurationFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;

            this._appDomain = AppDomain.CreateDomain(this.Name + ":" + this.Version, null, setup);

  其实真正的创建只要最后一句就够了,之前的代码都是对这个心创建的AppDomain进行设置,千万不能小看这些配置,我就在这上面栽了个很大的跟头。由于我要实现的目标是对上传的dll进行加载,然后再根据需要进行本地操作或者remoting出去,而我上传dll的时候将他保存在新建立的文件夹下面,文件夹规则是DLL\dll Name\datetime\,这样的话就遇到个很恶心的问题,我按网上的提示实现了代码,用assembly.loadfile反射dll后,在本地是可以调用dll的方法,但是服务器通过remoting后,在客户端用接口实现remoting的代理时,就出现了问题,提示找不到文件,我猜测的原因是服务端的接口和我反射的dll没有取得一致,当我将dll先在服务端引用,又或者说上传dll的时候将dll保存在服务端的工作目录的时候,客户端是能接受成功的,网上的解决方法也大多是直接将dll保存在工作目录里面。但这样显然不是我所需要的,这样处理的话,就会碰到这样的问题,当我上传的dll有很多个版本的话,由于名称相同,工作目录里面只能保存一个,这显然是不成的。后来setup里的ShadowCopyFiles即影像感念启发了我,我仔细的查看了setup的各个方法和属性,最后将PrivateBinPath获取this workpath即dll文件保存路径后这问题得到解决。就是怎么一个小小的改动,我搞定它却用了一个多星期,期间的纠结是非人所能想象。

  AppDomain创建后,下一步是用CreateInstanceAndUnwrap在这个使用assembly类的代理:

                string name = Assembly.GetExecutingAssembly().GetName().FullName;
                BusinessAssemblyLoader baLoader = (BusinessAssemblyLoader)this._appDomain.CreateInstanceAndUnwrap(name, "BusinessAssemblyLoader");
把AppDomain想象成一个黑盒,BusinessAssemblyLoader类就是这个黑盒里面的xxx,黑盒外面是不知道里面是什么样子的,而baLoader就是一个指向xxx的句柄,提供黑盒外面的使用,事实上就是这样完成两个程序域之间的通信的。建立代理后,我们就可以通过代理调用BusinessAssemblyLoader类的方法:

      obj = baLoader.RemoteLoader(this.Filename, className, int.Parse(this.Port), key, this.Mode);

  创建后我们就需要实现卸载功能,没有卸载功能的话,AppDomain没有任何的意义了。卸载的代码也很简单:

    public void Dispose()
        {
            AppDomain.Unload(this._appDomain);
            this._appDomain = null;
            System.GC.Collect();
        }

AppDomain.Unload就是AppDomain提供的卸载功能,由于我将整个BusinessAssembly类缓存在Core类库的键和值的工厂里,我通过get CachePool就能得到这个AppDomain,然后进行卸载操作。

  至此,一个操作AppDomain的类BusinessAssembly就已经完成了,接下来我们需要实现 BusinessAssemblyLoader类,并完成反射、remoting的操作:

     Assembly asm = Assembly.LoadFile(filename);  //通过assembly对dll进行反射,需要说明的是,dll所引用的类库服务端也必须引用,即存在于当前工作目录中,否则会出现“找不到文件或相关项”的错误,至于为什么服务端引用就可以,因为我在setup设置的时候将dll影像在当前工作目录了。

             Type type = asm.GetType(className);   

这样,反射dll就已完成了,下面将反射的内容remoting:

  

    IChannel channel = ChannelServices.GetChannel(port.ToString());
            if (null == channel)
            {
                IDictionary properties = new Hashtable();
                properties["name"] = port.ToString();
                properties["port"] = port;
                if (remoteMode.EndsWith("HTTP"))
                {
                    channel = new HttpChannel(properties, new SoapClientFormatterSinkProvider(),
                                      new SoapServerFormatterSinkProvider());

                }
                else
                {
                    channel = new TcpChannel(properties, new BinaryClientFormatterSinkProvider(), new BinaryServerFormatterSinkProvider());
                }
                ChannelServices.RegisterChannel(channel, false);
            }

            RemotingConfiguration.RegisterWellKnownServiceType(type, serviceName, WellKnownObjectMode.SingleCall);

这个我采用的是服务端激发模式,当然客户端激发下篇的服务端和控制台通信的时候会说到。在这段代码里,我也遇到过两个问题:1、端口开辟。我曾尝试将反射和remoting分开,使代码更规范。但是在程序域之间只能使用代理,不能得到Type,然后又将代码重新迁回BusinessAssemblyLoader,当时仍然将端口开辟放在BusinessAssemblyLoader之外,但郁闷的是port开辟代码放在这个AppDomain之外就是不行,将它整合到BusinessAssemblyLoader类里就又ok了,模糊感觉还是两个程序域之间的问题,但不知道根本原因所在。2、通道模式。在开辟为http时,当时马虎的也写成和tcp一样:HttpChannel(properties, new BinaryClientFormatterSinkProvider(), new BinaryServerFormatterSinkProvider());结果使用http时,客户端老是出错,最后帮助里仔细看了下,原来是—— HttpChannel(properties, new SoapClientFormatterSinkProvider(),
                                      new SoapServerFormatterSinkProvider());

 

  写了这里,反射、remoting等需求已基本上实现了,当然,也只是实现,有些东西是知其然而不知其所以然,甚至还可能隐藏着bug,但是最主要的,这代码缺失能跑的通了,不是吗,问题,以后使用的时候再慢慢发现吧。这语气,这么看这么感觉对自己代码特没信心,郁闷中。只要一看那些关于这些技术的文章的发表时间,就更郁闷了,人家用这些东西都有十年了,我还在这条路上摸索,还没摸通,郁闷啊!

Posted on 2010-12-16 16:03  萧鼎  阅读(1641)  评论(0编辑  收藏  举报