为某个.NET平台标准版本选择应用程序接口背后的原因是什么？
据我所知，.NET平台标准是一种提供支持不同平台的契约的方法。因此，我们的目标是同时支持这三个平台的.NET平台标准版本，而不是编写应该运行平台A、B和C的代码。
据我所知，这样做的动机是每个平台都有一个可用的“基础库”(就像BCL一样)。最后，我们的代码依赖于这个基库，所以我们需要知道哪些API的ara是可用的。以平台A、B和C为目标让我们知道我们可以访问在平台A、B和C的基础库中同时可用的API。
选择特定平台A、B和C的明显缺点是，如果出现另一个平台，而该平台的基础库中也有我们需要的API，我们就不能使用它。
通过.NET平台标准，我们以特定的“.NET级别”为目标，因此我们支持符合该标准的平台。这是因为我们确信，对于特定的.NET平台标准，我们有一组特定的API，这些API将出现在平台基础库中。
这里我要说的是:这里有一个从平台版本到.NET集合的映射，所以对于.NET标准1.0，我们关联了一个特定的API列表，对于API标准1.1，我们关联了1.1中的相同列表，以及更多的API，以此类推，直到1.4。
在这种情况下，我们为每个.NET标准版本挑选一个API列表，也就是说，单个数字包含了大量信息。
这背后的原因是什么？这个单一的数字怎么能包含如此多的信息？什么定义了在每个.NET标准平台级别中支持哪些API？
回答 1
Stack Overflow用户
发布于 2016-02-19 23:49:16
与PCL相反，平台标准试图以一种新的方法来解决兼容性问题，我们假设1.0版本匹配一些平台(尽管实际上这些平台在发布时并没有考虑到这样的标准)。然后在2.0版本中添加了一些新的API，因此匹配的平台得到了升级。
因此，目前所有现有平台到标准平台版本的映射就像是编造了这样的平台是如何“设计和发布”的历史。
它更多地强调了未来应该如何治理.NET生态系统。
例如，如果Microsoft和Xamarin (以及其他主要供应商)想要发布新的标准平台版本(规范)，那么他们可以讨论要添加的新API。在此之后，每个供应商都必须发布他们的新平台(.NET框架/.NET核心/Xamarin.iOS等等)以符合新标准。否则，它们将失去在生态系统中的地位。
其他编程语言，如C++，多年来一直在使用这种方法，而且效果很好。查看C++ 11、C++ 14和C++ 17。
https://stackoverflow.com/questions/35506915
复制相似问题
腾讯云开发者
