c# - 未标记为符合 CLS 的程序集的实际限制？

Question

作为 OSS 库的作者，我一直试图让我的东西符合 CLS。但是 MS 并没有让这变得容易。他们经常让您陷入 22 条军规，例如以下情况:

• 您不能拥有仅在大小写上与公共(public)属性不同的 protected 变量。
• 您不能拥有以下划线或“m_”开头的 protected 或公共(public)变量。
• 如果你想让一个类真正可扩展，你通常需要有匹配公共(public)属性的 protected 变量。最不丑陋的导出是为变量添加后缀，如“Var”或“Value”。这对我来说是令人讨厌和 Not Acceptable 。我喜欢干净的代码。

据我所知，没有一种 .NET 语言不支持以下划线开头的变量，而且我在许多需要子类可见变量的地方使用了它们。

我厌倦了这些警告，我计划在我的 30 多个 C# 库的汇编级别关闭 CLS 合规性。

关闭图书馆的 CLS 合规性是否存在任何实际问题？这样做有什么真正的问题吗？

几十年来，Microsoft 一直在发布令人忽视的软件指南，其中只有不到 5% 的字节值得编码的字节数。我找不到任何证据表明此最佳实践有任何实际意义对任何事情的影响。

但是，为了小心，我正在检查。

不，这不是这个问题的反面的重复:Any reason not to mark a DLL as CLSCompliant?

我在这里寻找的是实际结果和效果，而不是 MS 实习生的建议。

例如，如果 IronPython、IronRuby 或 F# 无法读取或写入以下划线开头的变量，这就是一个影响，尽管它只会对子类化某些对象的用户造成问题。

如果一种语言或工具完全无法使用程序集，除非它被标记为符合 CLS，这就很重要了。

Answer 1

据我所知，不合规的实际或真实问题是您失去了保证。

http://msdn.microsoft.com/en-us/library/bhc3fa7f.aspx

这就像对您的计算机进行超频或驾驶带有第三方模块的汽车，如果出现任何问题(即使它碰巧可以工作)，您将失去最初为您提供服务的人员的“官方”支持。

在 CLS 合规性的情况下，您将失去 MS 对您的代码与其他语言的互操作性的支持(我自己强调):

If you design a CLS–compliant class library, your library will have a guarantee of interoperability with a wide range of programming languages

至于所有的 catch-22，我不知道。不能说我曾经关心过 CLS 合规性。