今天閑裡偷空看了點Connect大會的視訊，C# 6.0的新文法、EF7的支援非關系型資料庫、Windows商店應用程式支援.net native等等都令我十分感動。但是，更令我感動的是SharedProject開放給所有類型的項目使用了。
在說SharedProject之前，我們先說一說它的前身——可移植類庫（Portable Class Library），簡稱PCL。
可移植類庫：
PCL的本質就是一個類庫，但是，它是可移植的。什麼是可移植的呢？例如，我們有一個項目，要求多個平台都能用的，那麼一般來說會設計成這樣：
圖畫得很爛，算了。-_-|||
Model層、資料通路層、業務邏輯層我們一般都建為普通的類庫項目，這點很正常。
随着時間過去，公司規模大了，老闆/Boss開始發福的時候，閑得蛋疼說：“哎，我看人家那個啥SilverLight的東西做得挺好看的，我們也把我們的項目弄個吧”。作為碼農的你隻能說幹就幹呗。于是就打開VS——建立項目——SilverLight 5——添加Model層的引用。媽蛋，啥玩意？
SilverLight沒法添加對普通類庫的引用！
這時候，可移植類庫就派上用場了。建立可移植類庫，将我們原來Model層的代碼轉移至可移植類庫下，接着，代碼還是我們原來的那些代碼，但Model層已經可以被各個平台類型的項目所引用了。
可移植類庫盡管真的很通用，但是其限制也是很大，I/O方面的方法幾乎全在可移植類庫中無法使用，控件這種更是不用想。
通用應用程式導緻SharedProject的誕生：
在WP8.0的時期，我們開發應用使用的是SilverLight的那一套技術，而在Windows 8應用商店開發的過程中，我們用的是Windows Runtime的那一套技術。那段時間的微軟肯定是被驢給踢了，最早的WPF，然後SilverLight，接着又來個WinRT，控件的使用方式換了一套又一套，以至于寫着WP8.0的時候我們找不到WrapPanel（原生不帶，需添加元件）、寫着WinRT的時候找不到LongListView。。于是乎，程式員們抱怨了，在WP8.1的時候支援了WinRT，并且能一次開發兩個平台的應用。這點怎麼辦呢？PCL限制過大，一個普通類庫的話，兩個平台又有少量的差別（例如Win平闆沒有WP的傳回鍵和搜尋鍵），于是SharedProject就應運而生。
如何建立SharedProject：
在VS2013及之前，我們隻能夠建立通用應用程式的時候，VS自動建立一個并且是唯一的一個給我們使用。
其中的App1.Shared就是SharedProject。
打開App.xaml.cs
我們可以看到App.xaml是被作為了入口點（當然傳統的Main還在，這裡不探讨，隻探讨在項目可見範圍）。并且我們可以看見圖中的部分代碼變灰色了，因為被條件編譯了。注意#if WINDOWS_PHONE_APP，說明隻有具有這個條件編譯符合才會編譯這段代碼。接下來我們修改左上角的這個地方。
修改為WindowsPhone，發現我們的代碼不再會是灰色的了，也就是說，這段代碼在編譯為Windows商店應用的時候是被忽略的，而隻有在編譯為WindowsPhone商店應用的時候才有效的。
可見，作用很強大，可移植類庫能夠繼承被引用項目的條件編譯指令，但可惜的是，再強大也隻能在應用商店程式項目中使用，什麼Winform、WPF等等的都隻能看着瞪眼。
但是，在VS2015中，這點改變了。
并且，建多個？沒問題。
結論：
辛苦各位看官了。
通過上面的過程，相信我們應該可以發現SharedProject的本質，就是在編譯的時候将代碼添加進被引用的項目中。（不然沒法解釋SharedProject能被條件編譯指令影響）
是以，我們可以得到以下表格來區分SharedProject與PCL的特點。
| 項目類型 | 編譯方式 | 條件編譯 | API限制 |
| SharedProject | 與引用SharedProject的項目的代碼合成一起編譯 | 受引用SharedProject的項目的影響，自身無法定義條件編譯符号 | 結合條件編譯下，與引用SharedProject的項目相同 |
| 可移植類庫（PCL） | 單獨編譯成dll | 不受引用PCL的項目的影響，能定義條件編譯符号 | 大 |
可見，SharedProject對比起PCL有極大的優勢。由于受引用SharedProject的項目條件編譯符合影響，使得SharedProject可以在不失靈活性的同時能用到相應平台的API。相信在VS2015正式釋出後，會有很多博友會喜歡上SharedProject這一個新的項目類型的。