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这一个新的项目类型的。