能巴的博客

摘要： As known，dotnet assembly可以JIT或者用NGEN直接生成汇编级assembly来一劳永逸。对于进一步加深理解，需要记住：1. 对于JIT来说：一，它是方法级的compile；二是，只有一个assembly的所有代码都被调用过了，这个assembly才被彻底编译了一遍；第三，JIT对一个assembly的一个调用方法，在app未重新启动的情况下只做一次（点了两点：JIT的编译结果是一个存放在内存里的映射表方法名，实际函数地址；因此，app每启动一次，都要重新建）2. 对于NGEN来说，他的结果是放到GAC里的（？）。 参考：.net你怎么这么慢 阅读全文

摘要： System.Text.EncodingSystem.Text.ASCIIEncodingSystem.Text.UnicodeEncodingSystem.Text.UTF32EncodingSystem.Text.UTF7EncodingSystem.Text.UTF8Encoding参见：Character Encoding in the .NET Framework 阅读全文

摘要： GAC解决的问题是dotnet assembly如何共享assembly的问题，比如dotnet framework，肯定要部署到GAC中。注：dotnet assembly locate rule是先找GAC，再找当前app所在的目录树（CLR will firstly search in GAC for assembly loading and then get into app specific directory / path tree）。所以，对于公用的assembly，只有一条路：就是放在GAC中。sidebyside assembly解决的是dotnet assembly 版本冲 阅读全文

摘要： 项目中碰到这样一个需求：本来，一个app的plugin （pluginA.dll + pluginARes.dll）是自然的deploy到app dir里面的；但是呢，现在要把这个plugin在这个app以及基于这个app开发的一些衍生产品上共享，就必须要把它放在一个common的目录里。但是呢，这个plugin有点特殊：pluginA.dll是mixedmode C++/CLI的module，然后呢，pluginARes.dll是用C#写的纯资源的dll；由于CLR locate assembly的机制，它一般只会在app目录树和GAC里寻找，那么如果，像这里的情况一样，把pluginA + 阅读全文