前天晚上，在一个页面上拖了一个ObjectDataSource，配置数据源时发现选择业务对象的列表没有列出当前项目的实体类，甚至连NewLife.CommonEntity中的实体类也没有列出来。按以往管理，重新编译、删除引用、更新DLL……所有操作都试了一遍，还是不行。这就奇了怪了，虽然这几年来一直碰到这个问题，尽管不知道原因，但是从来没试过解决不了的。觉得也许是我安装了vs2010sp1的原因。
第二天早上到了办公室，让没有安装vs2010sp1的同事试一下，同样的问题……
于是打算反编译.Net类库看看可能是怎么回事。搞了大半天，还是没有一丁点头绪，因为.Net类库里面在设计时方面大量使用接口，以及GetService之类的模式，压根就找不到实现类在哪！苦恼之余，老王告诉我，更换到旧版本的XCode v6.5就没有问题了。我心里一咯噔，v6.5？那是半年前的版本了，难道说这半年来一直用不了？但是也没听说呀！至少，这说明了问题跟我们的组件有关。
于是一个个组件一个个版本的试，终于确定只要把CommonEntity库更换到12月21日的版本就没有问题。于是查看了版本日志，以及代码变更。源代码控制就是好，可以记录编码过程中的点点滴滴！似乎也没什么用，那天修改的几个问题，都是改一下函数内部处理代码而已，vs在加载实体类型时，不会执行到里面的代码。于是又断线了！
OD附加到vs2010，不行，太大了，OD非常容易崩溃！并且还不好下断点。
vs2010调试vs2010，打开.Net源码调试，很悲剧，vs2010的源码是不公开的，同时因为没有合适的启动项目，压根就没地方下断点！
很不情愿的安装了非常不熟悉的WinDbg。太久不用，都生疏了，光是设置就花了几个小时。以前的WinDbg手册和SOS手册也都找不着了……到园子里找了十几二十篇文章临时看了一下，边看边折腾，基本的操作终于学会了。
1，设置符号路径。最好下载操作系统符号库安装。
2，把.Net2.0和.Net4.0的sos.dll拷贝到WinDbg目录下，分Clr20和Clr40目录存放，方便加载。
3，附加进程后，.chain看看已加载的xxx，如果没有sos，用.load加载。开始的时候总是提示sos版本不对，后来.chain看来，发现2和4的都加载了，还是默认自动加载的，悲剧，没有人告诉我怎么卸载，我猜.unload，懒得打参数，还真是。。。卸载最后一个。
4，我走了很多弯路，后来者就不要学我了。不懂指令，可以help，不行？那就用问号！太可怜了，WinDbg就那么几个命令。至于SOS所有指令都是!开头，!help就可以看到，不懂的一个个试，要是不懂英文，就学英文去。
5，!Name2ee指令直接找到要跟踪的方法，!DumpIL看看IL是否和Reflector中一致，鬼知道它会不会有什么优化处理呀，还有，用!u看看这个方法的汇编，是否与IL大致相同。一般来说，会有85%相同，毕竟jit会优化的嘛，特别是内联。
6，bp下断点，OD中一直很讨厌的指令下断点，这里不得不用，谁让WinDbg只有这么一个呢！
7，g吧，vs2010从挂起中恢复了，正常操作，配置数据源，不动了……果然WinDbg中断下了，你就不能学学OD，断下的时候自动把窗口弹出到前面来吗？
。。。。。。
998，sxe clr让clr异常断下，
原来是加载DLL出现异常！
999，查找资料，Assembly的Load、LoadFile、LoadFrom三个究竟什么区别？本地测试，LoadFile实体类库果然报错，LoadFrom倒是没问题，顺手拿MySql的程序集测试，居然通过了的，对比之下，它就多了一个CLS兼容……
1000，修改X各个组件，改成CLS兼容，编译，测试，没问题！
到现在为止，还是不知道为什么……
我不相信神话，我只相信汗水！我不相信命运，我只相信双手！
