Мне было интересно, какие существуют крайние случаи, которые могли бы сделать Common Language Specification compliance приемлемым. Даже если вы не собираетесь получать доступ с других языков, я считаю, что принципы, принятые CLSCompliantAttribute, являются лучшими практиками.Когда приемлемо нарушать соответствие CLS?
Вы столкнулись/знаете случаи, когда YAGNI перевешивает лучшие практики?
«[sic] Какая польза от совместимости с CLS?»
Medium trust, ClickOnce, работающий от общего сетевого диска, профилей гостей в настройках домена и т. Д. Существует множество ситуаций безопасности, при которых ваш код не может работать, если вы нарушаете соответствие CLS.
Я лично видел множество ситуаций, когда пользователи пытаются запустить свое приложение с общего сетевого диска и не могут, поскольку локальный администратор убил приложения, не совместимые с CLS, в профиле безопасности.
В общем, обычно есть способы обойти проблему в любом случае. Я бы придерживался противоположного подхода к комментариям выше, зачем ломать его? Вы пишете управляемый код, почему вы хотите ограничить свое приложение?
Я бы сказал, что если вы строите сборку или компонент API, вы всегда должны придерживаться их. Слишком много сторонних компонентов принимают простой выход и просто отмечают их как сломанные при попытке запустить из среднего доверия. В некоторых случаях это единственная причина, по которой они не могут работать. Если бы им потребовалось больше времени для соблюдения руководящих принципов, пользователи не ограничивались бы тем, как они могут использовать свой компонент.
Какова взаимосвязь между соблюдением CLS и доверием? Я думал, что соответствие не CLS просто означает, что некоторые функции вашего класса могут быть непригодными для использования на некоторых языках; например если коллекция только выставила свое свойство 'Count' как' UInt32', код, написанный на языках, которые не поддерживали этот тип, не смог бы узнать, сколько элементов было в нем. Если какая-то особенность имеет смысл только в языках, поддерживающих неподписанные типы (например, вызов перегрузки 'UInt32' функции' Interlocked.Increment' будет иметь смысл только в том случае, если у одного уже есть * такая переменная 'UInt32' для увеличения). .. – supercat
... Я не вижу причин, по которым включение такой перегрузки следует считать «плохой», или ограничивать контексты безопасности, где может использоваться код. – supercat
Я думаю, что это приемлемо для библиотеки, внутренней для продукта, при работе с устаревшими слоями, требующими такого рода функций или по соображениям производительности.
Но эти несоответствующие интерфейсы затем должны быть повторно отображены на более высоком уровне.
Согласен. Пока библиотека предназначена для внутреннего использования, и вы контролируете ее использование, это не должно быть проблемой. –
Ну, массивы «params» по атрибутам иногда просто настолько соблазнительны (но несовместимы). Но я бы рекомендовал использовать CLS-совместимые подходы, когда это возможно.
Если вы создаете приложение, которое не будет использоваться в качестве библиотеки, и вы знаете, что его нельзя будет портировать на другие платформы (например, Mono), какой смысл использовать CLS? –
Опираясь на дело, это хорошая практика при дифференциации свойств и их частных полей поддержки. Или это исключение из вашего «правила»? –
@Hosam Aly: например. не полагаясь на случай дифференцировать членов, является хорошей практикой, независимо от портирования или использования. –