什么是.NET可移植子集（遗留）？

Visual Studio 2012中的对象浏览器为可移植类库提供了两种不同的组件集：

• .NET可移植子集
• .NET可移植子集（遗留）

---

当我创建可移植类库时，它使用.NET可移植子集。第二套是什么？我如何使用它？它包含了MEF，这在过去是.NET Framework还是.NET Compact Framework时要简单得多，但微软只需将XNA/360、Silverlight和Windows Phone加入其中

---

我找不到任何关于“可移植子集（遗留）”的官方描述，但关于“可移植子集”的文档中没有提到紧凑框架，因此我猜测，如果非遗留子集指XNA、SL和WP7，“遗留”子集指的是紧凑框架。

是的，这令人困惑，这基本上是因为对象浏览器没有一个好的方法来表示可移植子集（在这个版本中，我们无法添加一种方法，而不进行重大重写）

帮助阐明这一点，请考虑下面的图表：

圆圈代表各平台的API表面积（不按比例）。在portable中，我们有效地公开了重叠区域中存在的API。例如，当针对上述三个平台时，我们允许您根据所有三个平台相交的表面区域（即正中心）进行构建。当针对Windows应用商店和.NET Framework时，我们允许您根据这两个平台相交的交叉点（即中间和右下角）进行构建。瞄准更多的平台，您可以使用的可用表面积将减少，瞄准更少的平台，您可以使用的表面积将增加。如果你仔细想想，这是有道理的，你结合的平台越多，它们的共同点就越少

这与您在对象浏览器中看到的内容如何匹配？

在对象浏览器中，我们没有一种简单的方法来公开这些单独的交叉点（当您将平台数量和单独版本的数量考虑在内时，会有很多！）。因此，我们所做的是在便携设备中获取所有可用的表面区域（即所有交叉点的组合），并将其暴露出来。这意味着对象浏览器显示了我们认为所有平台上都是“可移植”的所有API的组合。 这就是你看到我的原因。当您以.NET Framework和Silverlight为目标时，MEF是可用的，但一旦您将Phone或Windows应用商店添加到目标，您就会丢失它，因为这些平台不支持它

在.NET可移植子集和.NET可移植子集（遗留）之间有什么区别？

在portable中，我们有两种方法来实现可移植性，这取决于您是针对我们所称的遗留平台还是新平台

对于传统平台（Phone 7.x、SL4/5、.NET 4、Xbox），当我们想到多个平台之间的交叉点时，我们需要实际生成表示公共API的实际程序集。例如，当您将Windows Phone 7和.NET Framework组合在一起时，我们会生成（在Microsoft中由我们生成）一个实际的mscorlib、system、system.core等，其中包含这些共享的API。这不仅非常耗时，而且问题也非常严重，因为它可以生成不太有用的子集。例如，当我们第一次为跨平台的网络堆栈生成子集时，甚至没有一种创建HttpWebRequest连接的通用方法。这是因为在较旧的平台上（无论出于何种原因），没有人考虑可移植性

对于新平台（.NET4.5、WindowsStore、Phone8），我们从一开始就后退一步，设计了可移植性。我们没有事后考虑移植性，而是设计了我们称之为契约（基本上是程序集）的东西，它代表了一个自包含的代码单元，平台支持全部或全部不支持。这意味着，当您在.NET Framework 4.5上看到“System.IO 4.0.0.0”时，它支持的API与您在Windows Phone 8上看到的完全相同。这使得可移植性非常容易，而不需要生成自定义程序集来表示平台的交集，我们只需在程序集边界处创建子集。例如，给定支持System.Runtime.dll、System.Reflection.dll和System.Reflection.Emit.dll的平台1和支持System.Runtime.dll和System.Reflection.dll的平台2。当您以portable为目标时，我们只需选择System.Runtime.dll和System.Reflection.dll。从长远来看，这使得可移植性更容易理解，因为您可以从程序集而不是单个API的角度来考虑

遗留平台的表面积（基于Mscorlib）由.NET可移植子集（遗留）表示，而对于新平台，则由.NET可移植子集表示

当使用便携式时，我们试图隐藏这两个表面区域，但根据您的目标平台，我们会将您的第一个或第二个表面区域作为目标

---

这比我计划的时间要长得多，但请随意提出澄清问题。过去3年来，我一直在生活和呼吸这一点，所以我倾向于跳过一些事情而不去想它。

时间更长，但非常棒！谢谢你的详细解释。这是我找到的最有用的答案之一。谢谢你抽出时间。很高兴能不时从内部得到关于如何完成事情的反馈：）虽然答案是好的和全面的+1，但给我的印象是微软完全搞乱了.NET。我现在的处境是，我的大部分C#.NET核心框架代码在iOS和Android上编译得很好（通过Xamarin），但我发现现在Windows Phone 8完全崩溃了，因为它们忽略了基本的核心功能（如