打包脚本+工具+运行时 全部分享哈。。。。。(无公司争议,请放心)
精简包:http://pan.baidu.com/s/1i5JpqdB
工具:http://pan.baidu.com/s/1c1PUQK4
打包脚本:http://pan.baidu.com/s/1o84lYw6
注意,精简版的SDK适合开发客户端程序,服务器版本请安装完整版本 谢谢!
如有疑问,请留言
接上一篇
【.Net Framework 体积大?】不安装.net framework 也能运行!?开篇叙述-1
下一篇
【.Net Framework 体积大?】不安装.net framework 也能运行!?原理补充-3
昨天写了一个引子,还是有读者对这套“小把戏”感兴趣。那么不辜负大家的希望,争取博主不做太监........
注意:笔者不想谈Link的方式,虽然很爽,但是不靠谱。毕竟解析翻译到原生的应用,微软到现在也就敢在Xaml系的应用做尝试,不知道是微软的策略,还是自身都信心不大......
至于Mono项目,笔者就不说它了,BUG真的多的一个接一个的,甚至2.0都过去了,3.0还没有修复。虽然它可以支持Link ,mkbundle 工具,但是bug太多,不小心就是一个雷......
开篇先谈下原生的应用和虚机应用。
Native的程序,大多基于特定的平台硬件系统的,这里的系统 我们就说三大主流系统中的Win/Mac/Linux。硬件部分嘛,主要是CPU的类型...原生应用跟随操作系统的兼容性,可以类似插入内存条一样,直接跟系统集成,运行速度快,处理数据速度效率高。开发语言:C/C++ 汇编?(呵呵,这都上个世纪的东东) 。基于C/C++ 衍生出来 主流的 QT VC .....VC 里有衍生出个MFC。。。。。。。
虚机应用,这类应用大多是基于虚机运行时,也就是将运行时 Run time SDK 安装到适配的操作系统后,SDK将硬件 操作系统的不同 进行了自适应。应用开发者,只需要关注程序的运行效果。就好像坑坑哇哇的石头墙,摸了一层水泥,然后上面可以搭载各种形状的石头,而不是特定形状的石头(去适应石头缝大小形状)。特点是:平台适应强 开发速度快 迭代周期缩短...。开发语言:Python Java .net Framework node.js .......
虚机应用,又各自有各自的特定。有的是基于脚本执行,有的是强类型的编译执行。不过大同小异。都离不开运行时!!!
其他语言的运行时,我们不谈,有兴趣,自己研究。我们专门谈一下.net 的运行时 .net Framework.
特点:微软开发,大品牌。体积大,不能说大,简直是巨大!前面说了,从2.0 的几十兆 到3.5的几百兆 到4.0又回到几十兆(但是安装速度真慢的要命,因为要先自解压)。前面说了,十分佩服微软的 cab 压缩,愣是把一个几百兆的.net 4.0 压缩到了几十兆!!!4.5 4.6也都是4系列的。主版本号不变,改变次版本号,说明只是基于4的补丁,但是要亲命的是 4.5 抛弃了XP!!!!XP 啊,提到XP 就好像前端开发者对着IE6那个时代!!! 虽然痛苦恐怖,但是,XP在国内的使用群体依然大的离谱。
虽然 Win7普及的效果不错,但是那毕竟是XP 啊 XP 啊 ............泪奔。
所以,笔者认为 .net 4到目前为止 是兼容最全面的Win 系列的系统。对于开发者来说 4版本无疑是一个划时代的东东,各种应用框架都有,而且性能比3.5好,而且体积小了好多。但是仅仅是相对小了。笔者认为,它依然巨大。相比较 Python Ruby Node.js Lua的运行时,都小巧,安装速度快,运行速度也可以。凭啥.net 这个鬼 体积那么大!??
其实是有原因的。如图:
C:\WINDOWS\Microsoft.NET
这个基本就是.net 的运行时集中营了(虽然在System目录也打入了其他的dll,后面说)
看到这里,我们就需要回忆下,.net 的自身的架构
2.0
3.5
4.0
上图来自:http://www.cnblogs.com/xiaopin/archive/2011/01/07/1929467.html
是不是类似搭积木的方式,一块块的耦合上去的?确实,一个完整的.net framework安装包,需要把整个积木架构搭建起来。但是大多数情况下,我们只需要积木的台子,也就是到 第一个图中的程序集那一层就完事,有GAC 有运行时 ,就足够我们把程序集通过系统引导到 CLR 运行时解析 IL 中间语言到当前平台的原生代码,并执行原生代码。相当于,我们只需要雇佣一个翻译,会翻译其他语言即可,没必要长得高大威猛帅。。。。
那么我们能把上面的枝枝叶叶修建掉么?笔者测试是可以的。
我们只需要把GAC 的相关程序集,还有运行时即可。然后就是特定的引导目录+注册表。
笔者没有找到.net 程序引导的顺序,不过从笔者实验的结果来看。微软打包的程序的时候,给程序集打上了特殊的标识。然后由系统注册表注册的特定应用去解析程序集。类似指定默认程序一样的效果(不知道表述是否正确,欢迎大家指正)。
好,既然是指定的注册表来注册引导程序,那么哪个才是The One? 不卖关子,直接给答案!
注册表:SOFTWARE\Microsoft\.NETFramework\
这个注册表项,有一个安装路径的项,指定到.net的运行时目录。笔者的机器是64位机器,x86的机器就没有64.
然后,注册完路径后,还有它下面的一个注册表键值对:policy
注意其中的键值对:
这个支持策略,类似设计模式中的策略模式。根据特定的场景,使用特定的策略支撑。我们注册4.0后,自然也就支持.net 4.0。
好,注册表关键就这2个,接下来还有关键的一个步骤,在系统目录
一个是箭头指向的dll 还有一个
100那个是4.0的 120那个是笔者安装了 VC 分布包的 VC++2013的。我们需要的是上面的那个哈。。。
好,把这两个程序集 在特定的机器上,也打入进去后,好,我们的精简版本的.net framework就完成了!!
然后,还可以在运行时程序集 目录下,裁剪不需要的程序集 比如什么 exe的小工具啊 WCF 啊 WPF啊什么的。最终就可以粗来一个体积小巧,性能不错,支持.net 4.0的运行时了。
也就是上面的3步走,有兴趣自己尝试,有疑问,请评论留言。笔者不会发布完整的小安装包。版权的问题很蛋痛 呵呵,Congratulations..............
啰嗦一下,为什么添加注册表就能访问策略进行引导,跟.net的历史有关系吧,因为XP系统上面,就已经集成了1.X的.net framework.后续系统Vista win7 server03 08 等等也一样。所以,注册个版本号,也就可以识别粗来了。。。。。
注册表献上:
Root: HKLM; Subkey: "SOFTWARE\Microsoft\.NETFramework";Permissions:admins-full; ValueType: string; ValueName: "InstallRoot"; ValueData: "{win}\Microsoft.NET\Framework\";Check:WebServerRuntimeNotInstall
Root: HKLM; Subkey: "SOFTWARE\Microsoft\.NETFramework\policy\v4.0";Permissions:admins-full;Check:WebServerRuntimeNotInstall
Root: HKLM; Subkey: "SOFTWARE\Microsoft\.NETFramework\policy\v4.0"; Permissions:admins-full; ValueType: string; ValueName: "30319"; ValueData: "30319-30319";Check:WebServerRuntimeHasNotV4SubKey
不要问我,上面是什么鬼,inno setup 又是什么鬼。尽情享用吧.........