VS2015中SharedProject與可移植類庫（PCL）項目

今天閒裏偷空看了點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這一個新的項目類型的。