什么时候可以打破CLS合规？

Question

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

您是否遇到/了解YAGNI超过最佳做法的案例？

Answer 1

“[原文如此]符合CLS的用途是什么？”

Medium trust，ClickOnce，从共享网络驱动器运行，域设置中的访客配置文件等。如果您违反CLS合规性，则会出现许多安全情况，导致您的代码无法运行。< / p>

我个人已经看到很多情况，用户试图从共享网络驱动器运行他们的应用程序而不能，因为本地管理员已经在安全配置文件中杀死了非CLS兼容的应用程序。

一般来说，通常有办法解决这个问题。我会采取与上述评论相反的方法，为什么要打破它？您正在编写托管代码，为什么要故意限制应用程序？

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

Answer 2

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

Answer 3

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

但是这些不符合要求的接口应该在更高的层次上重新封装。