组件未标记为符合CLS的实际限制？

Question

作为一名OSS图书馆作者，我总是试图让我的东西符合CLS标准。但MS不会让这很容易。他们经常把你带入陷阱22，如下所示：

• 只有公共财产才能使受保护变量不同。
• 您不能以下划线或'm_'开头的受保护或公共变量。
• 如果您想使类真正可扩展，您通常需要以使受保护的变量与公共属性匹配。你最不丑的退出是为变量添加一个后缀，比如“Var”或“Value”。这对我来说是令人讨厌和不可接受的。我喜欢干净的代码。

我知道没有.NET语言不支持以下划线开头的变量，我已经在很多地方使用它们，其中变量需要对子类可见。

我已经厌倦了这些警告，而且我打算在我的30多个C＃库上关闭汇编级别的CLS合规性。

关闭库的CLS合规性是否存在实际问题？这样做的任何真正的问题？

几十年来，微软已经发布了关于软件的不可听的指导，其中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对您的代码与其他语言的互操作性的支持（我自己的重点）：

  

如果您设计符合CLS的类库，您的库将有一个   保证互操作性与广泛的编程   语言

至于所有的捕获22，我都不知道。不能说我一直关心CLS合规。

Answer 2

关于您用作示例的问题：

• 如果公共属性具有公共setter和getter，则不需要受保护变量，因为派生类可以使用公共属性设置值。
• 如果公共财产没有公共设置者，请为其提供受保护的设置者。这消除了对受保护变量的需要，因为派生类可以使用公共属性的受保护setter来设置值。
• 应完全避免使用公共变量。

结论：对受保护甚至公共变量通常 no 。它都可以使用属性建模。