打包脚本+工具+运行时 全部分享哈。。。。。（无公司争议，请放心）
精简包：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:WINDOWSMicrosoft.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? 不卖关子，直接给答案！
注册表：SOFTWAREMicrosoft.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: "SOFTWAREMicrosoft.NETFramework";Permissions:admins-full; ValueType: string; ValueName: "InstallRoot"; ValueData: "{win}Microsoft.NETFramework";Check:WebServerRuntimeNotInstall
Root: HKLM; Subkey: "SOFTWAREMicrosoft.NETFrameworkpolicyv4.0";Permissions:admins-full;Check:WebServerRuntimeNotInstall
Root: HKLM; Subkey: "SOFTWAREMicrosoft.NETFrameworkpolicyv4.0"; Permissions:admins-full; ValueType: string; ValueName: "30319"; ValueData: "30319-30319";Check:WebServerRuntimeHasNotV4SubKey
不要问我，上面是什么鬼，inno setup 又是什么鬼。尽情享用吧.........