什么时候可以违反 CLS 合规性？答案

【问题标题】：When is it acceptable to break CLS compliance?什么时候可以违反 CLS 合规性？
【发布时间】：2013-01-22 18:41:31
【问题描述】：

我想知道存在哪些边缘情况可以使Common Language Specification compliance 可以接受。即使不打算从其他语言访问，我认为CLSCompliantAttribute 断言的原则是良好的最佳实践。

您是否遇到/知道YAGNI 胜过最佳实践的案例？

【问题讨论】：

【解决方案1】：

“[原文如此] 符合 CLS 有什么用？”

Medium trust、ClickOnce、从共享网络驱动器、域设置中的访客配置文件等运行。如果您违反 CLS 合规性，则在许多安全情况下您的代码将无法运行。

我个人见过很多情况，用户试图从共享网络驱动器运行他们的应用程序，但由于本地管理员在安全配置文件中杀死了不符合 CLS 的应用程序而无法运行。

一般来说，无论如何，通常都有解决此问题的方法。我会对上面的 cmets 采取相反的方法，为什么要打破它？您正在编写托管代码，为什么要故意限制您的应用程序？

我想说，如果您正在构建 API 程序集或组件，则应始终遵守它们。太多的第三方组件采取了简单的方法，并在尝试从中等信任度运行时将它们标记为已损坏。在某些情况下，这是它们无法运行的唯一原因。如果他们花更多的时间来遵守这些指南，那么用户将不会受到他们如何使用他们的组件的限制。

【讨论】：

CLS 合规性和信任之间有什么关系？我认为不符合 CLS 仅意味着您的课程的某些功能可能无法从某些语言中使用；例如如果集合仅将其Count 属性公开为UInt32，则以不支持该类型的语言编写的代码将无法找出其中有多少项目。如果某些功能仅在支持无符号类型的语言中有意义（例如，调用 Interlocked.Increment 样式函数的 UInt32 重载仅在已经拥有这样的 UInt32 变量时才有意义增量）...
...我看不出有任何理由为什么包含这样的重载应该被视为“坏”的事情，或者限制可以使用代码的安全上下文。

【解决方案2】：

嗯，属性上的“params”数组有时非常诱人（但不合规）。但我建议尽可能使用符合 CLS 的方法。

【讨论】：

【解决方案3】：

我认为在处理需要此类功能或出于性能原因的遗留层时，产品内部的库是可以接受的。

但这些不符合标准的接口随后应在更高级别重新封装。

【讨论】：