我在这里遗漏了一些东西。我得到的是在公共接口和方法中使用.NET兼容类型，以便.NET语言可以很好地一起播放（例如，“System.String”，而不是C＃的“字符串”）。
如果使用.NET兼容类型，那么所有基于.NET的语言肯定可以互操作。 CLS合规性何时以及如何影响？
例如，System.UInt16符合.NET，不符合CLR，并且相当于C＃中的“ushort”。
答案 0 :(得分：1)
CLS合规性比共享类型系统更严格（意味着所有.NET语言都可以使用的类型）。
一个例子是命名 - 在C＃中，您可以使用_启动公共成员名称。
这不符合CLS，因为并非所有语言都允许。
答案 1 :(得分：1)
我知道在公共接口和方法中会使用.NET兼容类型，这样.NET语言就可以很好地协同工作（例如，“System.String”，而不是C＃的“字符串”）。
这实际上不是问题。使用C＃的string将导致与使用System.String完全相同的CIL 。
CLS合规性何时以及如何影响？
某些语言不支持所有类型，因此如果您希望支持以所有语言干净地工作的类型系统，则需要符合CLS。这意味着ushort（System.UInt16）不能保证所有.NET语言都可以使用，因此如果您想要符合CLS，则应避免将其暴露在公共类型中。
对于CLS合规性，您还需要遵循其他规则，例如不要仅仅根据具体情况区分成员，因为某些语言不区分大小写。类型要求仅仅是完全符合CLS的众多要求之一。
这里的主要问题是常见的.NET语言（例如C＃）允许您使用许多类型，名称和技术，这些类型，名称和技术不能保证可用于所有符合CLS的语言 - C＃比它更灵活语言需要符合CLS。这意味着，当您使用C＃编写代码时，如果您希望所有符合CLS的语言都能使用该代码，则需要限制在公共API中公开的内容。
答案 2 :(得分：1)
如果使用.NET兼容类型，那么所有基于.NET的语言肯定可以互操作。
这根本不是真的。并非所有语言都支持所有.NET类型。例如，早期版本的VB.NET不支持UInt16，UInt32或UInt64。
CLS合规性何时以及如何影响？
除其他外，CLS定义了必须实现的类型才能进行互操作。所有其他类型都是可选的。