Когда допустимо нарушение требований CLS?

"[sic] Какая польза от соответствия требованиям CLS?"

Среднее доверие, ClickOnce, запуск с общего сетевого диска, гостевые профили в настройках домена и т. д. Существует множество ситуаций безопасности, когда ваш код не может работать если вы нарушите соответствие требованиям CLS.

Я лично видел много ситуаций, когда пользователи пытались запустить свое приложение с общего сетевого диска и не могли этого сделать, потому что локальный администратор убил несовместимые с CLS приложения в профиле безопасности.

В общем, обычно есть способы обойти проблему. Я бы придерживался противоположного подхода к комментариям выше, зачем его нарушать? Вы пишете управляемый код, зачем вам намеренно ограничивать свое приложение?

Я бы сказал, что если вы создаете сборку или компонент API, вы всегда должны их придерживаться. Слишком много сторонних компонентов находят простой выход и просто помечают их как сломанные при попытке запустить со средним уровнем доверия. В некоторых случаях это единственная причина, по которой они не могут работать. Если бы им потребовалось немного больше времени, чтобы придерживаться рекомендаций, пользователи не были бы ограничены в том, как они могут использовать свой компонент.

Что ж, массивы "params" атрибутов иногда просто заманчивы (но несовместимы). Но я бы рекомендовал по возможности использовать CLS-совместимые подходы.

Я думаю, что это приемлемо для библиотеки, внутренней по отношению к продукту, при работе с устаревшими слоями, которые требуют таких функций, или по соображениям производительности.

Но затем эти несовместимые интерфейсы следует повторно инкапсулировать на более высоком уровне.