为什么System.Numerics.BigInteger在Silverlight 4.0中没有Parse方法，但是在.Net 4.0中呢？

Question

我遇到.Net 4.0和Silverlight 4.0使用的BigInteger之间的奇怪差异;在.Net中，BigInteger有Parse和TryParse方法，与Silverlight版本一样，它没有这两种方法。

如果你看一下Reflector中的System.Numerics的.Net版本，你也会看到当你反汇编代码时，每一个方法都是空的，它缺少BigIntergerBuilder和朋友的Silverlight版本：

public static BigInteger Parse(string value)
{
}

这里发生了什么？

Answer 1

我不认为System.Numerics.dll是Silverlight 4.0发行版的一部分。但这不是真正的观点。您正在查看的是参考装配的特殊版本。例如，您可以在c:\program files\reference assemblies\microsoft\framework\.netframework\v4.0中找到一个。

那里的组件已经从它们中剥离了所有的IL。其他元数据与c:\windows\microsoft.net\framework\v4.0.30319

中的“真实”参考集合相同

我不知道这些剥离组件的功能应该是什么。我只能想象它们是为了加速编译，因为编译器只需要元数据。但那是一个长镜头。我还可以想象它与神秘的新[TargetedPatchingOptOut]属性有关，这也是一个很长的镜头，因为它背后的机制没有在任何我能找到的地方解释。我和JaredPar谈过这件事，他打算在MSFT里面询问一下。没有收到回复。

嗯，没有真正的答案，但它确实解释了你所看到的。

---

接下来，当我注意到该文件夹​​名为“v4.0”时，我还有另外一个理论。请注意，构建号不是它的一部分，因为它位于c：\ windows \ microsoft.net中。在发布新版本时应该会产生有趣的效果，类似于发布Service Pack时对.NET 2.0基本程序集的更新。

臭名昭着，一件严重错误的事情是这些更新在核心类中发生了变化，没有对[AssemblyVersion]的更改。最明显的是WaitHandle类，它获取了WaitOne（int）重载。非常有用，因为没有人能够找出 exitContext 参数传递的内容。使用这个新的重载很容易，目标.NET 2.0并没有阻止它，但如果目标机器安装了原始的.NET 2.0 RTM版本而没有获得服务包，那么地狱就会崩溃。

我的猜测：这些参考程序集是.NET 4.0的当前和未来版本的核心程序集。他们的公共界面被冻结了。并防止您意外使用在以后的版本中添加的公共方法。因此，IL没有用，因为它会发生变化。

Answer 2

很明显不是 BigInteger.Parse的代码 - 它不会编译，因为它不会返回任何内容。

这当然不是Silverlight中唯一“缺失”的东西 - 当然还有很多不在Silverlight中的.NET API。它是框架的简化版本。我担心这只是事情的方式。

整数就是它们的本质，以一种天真的方式自己实现它可能不会太难......如果你对它的效率很低，我怀疑它不会是非常多的代码所有