解惑

解己之惑,解人之惑

2010年3月

c#反射之Enum篇

因为最开始就遇到这个问题,所以单独提出来,不废话了,上代码吧

Assembly assembly = Assembly..Load(“MyDLL”);
Type type = assembly.GetType(“MyDLL.MyEnum”);
FieldInfo enumItem = type.GetField(“ENUM_TEST”);
object enumValue= Enum.ToObject(type, enumItem.GetValue(type));
最后一行代码得到的就是对应的enum对象的实例,可以传递给方法调用,type.GetField方法中的字符串其实就是enum中的字符串名字。要得到这个名字的列表也很容易:

string[] names = Enum.GetNames(type);

c#反射入门篇

主要就是几点

加载DLL

通过Assembly类的方法,主要是Load,还有其他一些方法可以自己研究下,Load方法可以传一个简单名,也可以传完整的限定名,传简单名(MyDLL)的时候,对应的DLL文件(MyDLL.dll)必须位于当前目录?(或者是PATH里面),如果是引用系统注册的DLL,则必须是完整的限定名,例如:MyDLL, Version=1.0.0.0, Culture=Neutral, PublickeyToken=d3cc2ceeafb73bc1

得到Type

这个没有什么,调用上面得到Assembly实例的GetType就行了

创建实例

得到Type以后,使用Activator.CreateInstance就可以了

调用方法

通过Type的GetMethod得到需要调用的MethodInfo对象,然后调用MethodInfo的Invoke方法。

废话少说,看代码吧:

Assembly assembly = Assembly..Load(“MyDLL”);
Type type = assembly.GetType(“MyDLL.MyClass”);
object obj = Activator.CreateInstance(type);
MethodInfo createMethod = type.GetMethod(“MyMethod”);
object[] parameters = new object[1];
parameters[0] = “ParameterValue”
object result = createMethod.Invoke(obj, parameters);

其实和Java差不多,就是java不需要load那一步,因为默认是从CLASSPATH中的所有jar中都可以load的,这个是JVM做的事情。如果需要load其他的不在CLASSPATH中的jar也是可以的,比较麻烦而已。

研究c#的反射机制

要做一个通用的自动测试框架,通过写xml文件完成Test Case的构建,由于打算支持COM和普通的DLL的方法调用,所以必须基于反射来做了。

大概看了下,好像也不是很复杂,就是得一步一步的试了。

Regsvr32: 0x80070716

注册Dll的时候遇到这个错误,当然,我是在开发一个新的自己的DLL,或者是我修改已有的DLL增加我自己的东西,已经遇到好几次这个错误了。这个错误的对应的错误信息是:

the resource name specified cannot be found in the image file

其实我已经遇到过几次了,上次解决过一次,但是忘记了,这次吸取教训,把它记下来。

我的错误是因为我增加了一些类,idl修改好了,rgs文件也都写好了,但是我忘记了在rc文件里面把那些rgs文件引用下。

超短的Iteration

项目正式启动,但是时间很紧,两个月时间要把对旧系统的修改做好,因为要赶他们的一个发布计划。两个月被划分成3个Iteration,扣除前期的讨论时间和预留的时间,实际就剩6周,所以一个Iteration就是两周,上周计划开始的时候还在讨论设计,不过这个也怪我,因为在Iteration开始的前一周的周三抛出一个我的设计想法,和中国这边的团队讨论了两天,周五才发邮件给美国的同事,到了周二才正式开会确定采用我的设计,不过架构师要求快速出个原型,还好比较顺利,我的设计还是蛮符合预期的,很多地方甚至比预期的还顺利,根本不用修改代码直接就是OK的。不过,实际上,我们上周还没有把Code Base准备好,开发环境也没有准备好,周五的时候匆忙把Code Base弄好了,下周我还得把我负责的基础类弄好,还有新进的设备得弄好。好多事情啊。估计这个Iteration的BurnDown Chart会很难看,因为上周一周基本上都在做计划外的事情。

交行网银支付支持Safari

今天抱着试试看的心情试了下交行的网上支付功能,让我吃惊的是它竟然偷偷的支持Safari了!终于解决了我最后一个完全转向MAC的问题,兴奋啊,为什么一直没有人说过啊,也没有见交行宣传过。这下爽歪了,柳暗花明啊。

全面转向无线

买了MAC后,开始的时候使用的有线的方式上网,很不方便,一个是因为MAC的插口都集中在左边,电源、网线口和USB口都在一起,正常情况下就显得非常的局促,换了无线路由以后感觉好多了,可以满屋子到处用了,但是鼠标又成为问题,笔记本自带的触摸板还不错,但是缺少中间滚轮功能还是比较不方便的,考虑到现在满世界都是无线信号,也不在乎多一个辐射源了,所以就买了个无线鼠标,另外由于装修时的布线问题,家里的ADSL牵的线也很别扭,电话线和ADSL的那个转换器的线横跨房间,经常绊到,给PC也配一个无线网卡。正在考虑是否要买个人体工学的无线键盘,主要是上班的时候用。

设计也不是个简单的事情

理论上,一个系统的设计如果有多种方案,应该是很容易决定出优劣的,但是现实往往不是这样,需要考虑很多种因素。

  • 参与决策的人的设计风格不同,有的喜欢Properties式的无约定扩展风格,有的喜欢超级父类式的运行时多态风格,还有的喜欢根据功能不断增加的API不断对应增加的风格,当然还有其他的一些根据三种风格的变种的风格。
  • 实现系统的人的能力和背景不同,某些很好的设计对于他们来说难度较大,因为实现的人不能充分的理解设计者的意图,最终好的设计变成糟糕的实现。
  • 时间约束,项目的时间很紧,某些设计方案需要做比较多的架构和框架方面的东西才能做业务方面的东西,导致前期更高级别的人看不到项目的直接而且直观的结果。
  • 需求的不确定,很多设计都是根据当前和可预见的需求来设计的,但是如果需求非常的不确定,很难决定那种设计更好,不同的关键需求的变更可能导致某些关键设计的失败。
  • 技术风险,某些设计存在一些技术风险,设计还没有成熟的先例,在大规模系统情况下存在不可预见的技术瓶颈。

习惯MAC了

定制得差不多了,抛弃或者一般不用系统自带的应用,这个和用WINDOWS系统类似。开始的时候很多使用方式不是很清楚,现在已经比较熟练了,不影响日常使用了。现在用得比较多的还是mac上的鼠标板,不过已经订了个rapoo的无线鼠标。

列举下安装的软件:

  • NEOOffice
  • FIREFOX
  • CHROME
  • ADIUM
  • QQ
  • MSN
  • FILEZILLA
  • VIRTUALBOX
  • FIT

mac下应该不用杀毒软件吧,经常上apple的官网看软件,但是很多是共享软件,不爽,我基本只用免费软件,穷啊。

PS:FIT确实比系统自带的输入法好多了。

© 2025 解惑

本主题由Anders Noren提供向上 ↑