为什么我们有这么多种.NET？这是好事吗？[关闭]

.NET Framework有许多“特色” ：

满（“正常”）
客户资料子集
Web浏览器中的Silverlight
Windows Phone上的“ Silverlight”
紧凑的框架
WinRT

当在新平台上需要C＃代码时，Microsot似乎更喜欢采用完整的CLR并将其剥离为一个小的子集，从而创建新的程序集并移动类型，而不是仅使用现有的程序集（例如BCL中的程序集）。例如，Silverlight对于WPF具有不同的类/方法（甚至包括某些具有稍微不同的签名或非常不同的实现的方法），而不仅仅是引用与List<T>WPF 相同的实现。

这是理想的体系结构还是传统的标志？BCL不应在所有平台上都只具有不同的表示/ IO库的所有平台上运行吗？还是BCL和其他库过于ated肿，将它们拆分出来会产生太多向后兼容的问题，这是可以接受的？

如果我们从一块空白的画布开始，并且不担心向后兼容性，那么当前的状况真的是处理多个平台的最佳方法吗？

.net frameworks silverlight

— 保罗·斯托维尔
source

所有的近票是多少？这是一个完全合理的问题。

— 梅森惠勒2012年

看来它可能已关闭，可能是因为它的措辞有些判断性（听起来好像您已经确定它的“糟糕架构”）。您可能需要将其重新表述为“ .NET 为什么有这么多种口味？”

— FrustratedWithFormsDesigner 2012年

@FrustratedWithFormsDesigner是正确的。问题始于对.NET的偏见。如果基调较为中立，我怀疑不会进行任何密切投票。

— 奥德

在我看来，您就像在试图引发争论，而不是在寻找对您的问题的建设性答案。我猜这就是为什么您获得接近票数的原因。

— Tyanna 2012年

@Oded和其他人-我已经改写了标题和正文，希望得到您的认可：)

— Paul Stovell 2012年

Answers:

Microsoft所做的将例程分成多个包的操作很常见。有一个.NET版本可以在内存有限的单板计算机（.Net Micro Framework）上运行。例如，在该版本中包含运行完整图形用户界面所需的所有内容都没有任何意义。

如果您查看Apple，iPhone并不包含Mac上的所有例程。

— 强尼船队
source

但是，不是由开发人员复制/粘贴代码以List<T>创建Micro Framework List<T>，还是不应该对BCL进行适当的拆分，以使二进制文件在所有平台上运行？

— Paul Stovell，2012年

换句话说，难道不应该让代码在另一个平台上运行只是选择支持哪些程序集的一种情况？

— Paul Stovell，2012年

Java也这样做。例如，Java Card是Java的子集。

— 伯纳德

@PaulStovell：我不确定MS的工作方式...但是如果MS有一个单独的构建路径/脚本（简而言之）来接受代码并为目标平台构建它，我不会感到惊讶。它不是复制/粘贴，List<T>但可能会从代码中删除某些内容，或者与某些平台特定的内容合并并生成部署项。

— 史蒂文·埃弗斯

我不认为.NET是问题。尽管存在各种运行时，但它们仍然兼容，这就是为什么像可移植类库这样的技术可以工作的原因（适用于您列出的大多数运行时）。

例如，是否每个风味都不应引用一个名为“ System.Collections.dll”的共享程序集，而不是每个运行时都具有自己的System.dll / mscorlib.dll副本以及各种集合副本？

为什么需要这个？只要它们都是兼容的（再次请参见可移植类库），这无关紧要，因为BCL是运行时本身的一部分，并且是串联分布的。

— 里德·科普西
source

我是否应该能够编写只List<T>在任何平台上使用和运行它的类而不创建可移植库的类？还是List<T>自己不应该在便携式库中？在我看来，可移植库感觉像是一种解决方法，而不是优雅设计的一部分。

— Paul Stovell，2012年

.NET本质上是在Windows环境中替换和扩展com对象。它也用于识别许多截然不同的技术，想象一下Adobe是否将其所有产品重命名为使用相同的名称，这就是.NET所发生的事情

— Ryathal
source