什么时候可以违反 CLS 合规性？
我想知道存在哪些边缘情况可以使 通用语言规范合规性可接受。 即使不打算从其他语言访问，我也认为 CLSCompliantAttribute 是良好的最佳实践。
您是否遇到过/知道 YAGNI 胜过最佳实践的情况？
I was wondering which edge cases exist that could make Common Language Specification compliance acceptable. Even when not intending to be accessed from other languages, I think that the tenets asserted by the CLSCompliantAttribute are good best practices.
Do you have encountered / know of cases where YAGNI outweighs the best practices?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
“[原文如此] 符合 CLS 有什么用？”
中等信任，ClickOnce，从共享网络驱动器、域设置中的来宾配置文件等运行。在许多安全情况下，您的代码无法运行如果您违反了 CLS 合规性。
我个人见过很多情况，用户尝试从共享网络驱动器运行其应用程序，但无法运行，因为本地管理员已在安全配置文件中终止了不符合 CLS 的应用程序。
一般来说，通常有办法解决这个问题。 我会采取与上面评论相反的方法，为什么要打破它呢？ 您正在编写托管代码，为什么要故意限制您的应用程序？
我想说的是，如果您正在构建 API 程序集或组件，您应该始终遵守它们。 太多的第三方组件采取了简单的方法，在尝试从中等信任状态运行时将它们标记为损坏。 在某些情况下，这是他们无法运行的唯一原因。 如果他们多花一点时间来遵守这些指南，用户就不会在如何使用其组件方面受到限制。
"[sic] What use is there for being CLS compliant?"
Medium trust, ClickOnce, running from a shared network drive, guest profiles in a domain setting, etc. There are lots of security situations where your code cannot run if you break the CLS Compliance.
I have personally seen a lot of situations where users are trying to run their application from a shared network drive and can't because the local admin has killed non-CLS compliant applications in the security profile.
In general, there are usually ways to work around the issue anyway. I would take the opposite approach to the comments above, why break it? You are writing managed code, why would you want to limit your application on purpose?
I would say that if you are building an API assembly or component, you should always adhere to them. Too many third-party components take the easy way out and just flag them as broken when attempting to run from medium trust. In some cases, this is the only reason they can't run. If they had taken a little more time to adhere to the guidelines, users would not be limited as to how they can use their component.
嗯，属性上的“params”数组有时是如此诱人（但不合规）。 但我建议尽可能使用符合 CLS 的方法。
Well, "params" arrays on attributes are sometimes just so tempting (but non-compliant). But I'd recommend using CLS-compliant approaches whenever possible.
我认为，当使用需要此类功能或出于性能原因的遗留层时，产品内部的库是可以接受的。
但这些不合格的接口应该在更高的级别上重新封装。
I think it's acceptable for library internal to a product when working with legacy layers that require that kind of features or for performance reasons.
But these non-conformant interfaces should then be reencapsulated at a higher level.