CLS 与 .NET 类型合规性：了解差异答案

【问题标题】：CLS vs .NET type compliance: understanding the differenceCLS 与 .NET 类型合规性：了解差异
【发布时间】：2013-05-29 18:32:31
【问题描述】：

我在这里遗漏了一些东西。我知道有人会在公共接口和方法中使用符合 .NET 的类型，以便 .NET 语言可以很好地协同工作（例如，“System.String”，而不是 C# 的“string”）。

如果使用 .NET 兼容类型，那么所有基于 .NET 的语言肯定都可以互操作。 CLS 合规性何时以及如何影响？

例如，System.UInt16 是 .NET 兼容的，而不是 CLR 兼容的，相当于 C# 中的“ushort”。

【问题讨论】：

标签： .net types interop cls-compliant

【解决方案1】：

我知道人们会在公共接口和方法中使用符合 .NET 的类型，以便 .NET 语言可以很好地协同工作（例如，“System.String”，而不是 C# 的“string”）。

这实际上不是问题。使用 C# 的 string 将导致 与使用 System.String 完全相同的CIL。

CLS 合规性何时以及如何影响？

某些语言不支持所有类型，因此如果您想支持将在所有语言中干净地工作的类型系统，则需要符合 CLS。这意味着 ushort (System.UInt16) 不能保证可用于所有 .NET 语言，因此如果您想符合 CLS，则应避免将其暴露在公共类型中。

为了遵守 CLS，您还需要遵守其他规则，例如不要仅按大小写区分成员，因为某些语言不区分大小写。类型要求只是完全符合 CLS 的众多要求之一。

这里的主要问题是常见的 .NET 语言（例如 C#）允许您使用许多类型、名称和技术，这些类型、名称和技术并不保证适用于所有 CLS 兼容语言 - C# 比它更灵活语言需要符合 CLS。这意味着，当您使用 C# 编写代码时，如果您希望所有符合 CLS 的语言都可以使用该代码，您需要限制在公共 API 中公开的内容。

【讨论】：

好的，但是 System.UInt16 是 .Net 类型，所以肯定所有 .Net 语言都必须支持它？
@IanC Nope - 通常，大多数 .NET 语言支持的远远超过 CLS 要求，但您可以编写完全符合 CLS 且不支持 UInt16 的语言。
@IanC 在其中添加了一段可能有助于解释事情的段落。
因此，“.Net 语言”不需要支持所有 .Net 类型，但必须支持所有 CLS 类型。嗯，那为什么不叫“CLS Languages”呢？至少对我来说，说“一种 .Net 语言”意味着合规性。
@IanC ".NET Language" 有点用词不当——它实际上是一种使用“通用语言规范”以“通用语言运行时”为目标的语言——一种语言可以添加到规范中（并且与其他类型一起使用），但如果它想要兼容，它必须实现并使用 CLS 中的 everything。这使得创建可以在 CLR 上工作的语言（您不必支持每种语言的特性）变得更加容易，但如果您不想这样做，也可以不限于 CLS。

【解决方案2】：

CLS 合规性比共享类型系统更严格（意味着所有 .NET 语言都可以使用的类型）。

一个例子是命名 - 在 C# 中，您可以使用 _ 开始一个公共成员名称。

这不符合 CLS，因为并非所有语言都允许这样做。

【讨论】：

谢谢。所以这归结为哪些语言会使用 CLS 而不是 .Net 类型？
@IanC - 不确定我是否遵循。所有 .NET 语言都将使用 .NET 类型，但并非每种 .NET 语言都支持所有类型。此外，命名也很重要。
嗯，例如，似乎 System.UInt16 不需要被所有 .Net 语言支持，即使这是一个基本的 .Net 类型。这是正确的吗？
@IanC - 我相信是的。并非所有 .NET 语言都有无符号整数。

【解决方案3】：

如果使用 .NET 兼容类型，那么所有基于 .NET 的语言肯定都可以互操作。

这根本不是真的。并非所有语言都支持所有 .NET 类型。例如，VB.NET 的早期版本不支持UInt16、UInt32 或UInt64。

CLS 合规性何时以及如何影响？

CLS 定义了语言必须实现的类型以实现互操作。所有其他类型都是可选的。

【讨论】：