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

Question

作为OSS库的作者,我总是试图使我的东西符合CLS.但MS不会让这很容易.他们经常让你陷入困境22,如下所示:

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

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

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

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

几十年来,微软已经发布了关于软件的不可听的指导,其编码的字节数不到5%.我找不到任何证据表明这种最佳实践对任何事情都有实际影响.

但是,要小心,我正在检查.

不,这不是这个问题的反面的重复:没有任何理由不将DLL标记为CLSCompliant？

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

例如,如果IronPython,IronRuby或F#无法读取或写入以下划线开头的变量,那就会产生影响,尽管这只会导致用户子类化某些对象时出现问题.

如果语言或工具完全无法使用程序集,除非它被标记为符合CLS,现在这是一个大问题.

Answer 1

据我所知,一个实际或真正的违规问题是你失去了保证.

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

这就像超频你的电脑或用第三方模式驾驶你的汽车,如果出现任何问题(即使它碰巧工作),你会失去原来为你提供的"官方"支持.

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

如果您设计符合CLS的类库,那么您的库将 保证与各种编程语言的互操作性

至于所有的捕获22,我不知道.不能说我一直关心CLS合规性.