我想知道存在哪些可以使公共语言规范合规性可接受的边缘情况。即使不打算从其他语言访问,我认为由断言的原则CLSCompliantAttribute
是良好的最佳实践。
您是否遇到过/知道YAGNI胜过最佳实践的案例?
我想知道存在哪些可以使公共语言规范合规性可接受的边缘情况。即使不打算从其他语言访问,我认为由断言的原则CLSCompliantAttribute
是良好的最佳实践。
您是否遇到过/知道YAGNI胜过最佳实践的案例?
“[原文如此] 符合 CLS 有什么用?”
中等信任、ClickOnce、从共享网络驱动器、域设置中的访客配置文件等运行。如果您违反 CLS 合规性,有很多安全情况下您的代码将无法运行。
我个人见过很多情况,用户试图从共享的网络驱动器运行他们的应用程序并且因为本地管理员在安全配置文件中杀死了不符合 CLS 的应用程序而无法运行。
通常,无论如何,通常都有解决此问题的方法。我会对上面的评论采取相反的方法,为什么要打破它?您正在编写托管代码,为什么要故意限制您的应用程序?
我想说的是,如果您正在构建 API 程序集或组件,您应该始终遵守它们。太多的第三方组件采取了简单的方法,并在尝试从中等信任度运行时将它们标记为已损坏。在某些情况下,这是它们无法运行的唯一原因。如果他们花更多的时间来遵守这些指南,那么用户将不会受到他们如何使用他们的组件的限制。
好吧,属性上的“params”数组有时非常诱人(但不合规)。但我建议尽可能使用符合 CLS 的方法。
我认为在使用需要此类功能或出于性能原因的遗留层时,产品内部的库是可以接受的。
但是这些不符合标准的接口应该在更高的层次上重新封装。