今天闲里偷空看了点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这一个新的项目类型的。