打包腳本+工具+運行時 全部分享哈。。。。。（無公司爭議，請放心）
精簡包：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 又是什么鬼。盡情享用吧.........