Практические ограничения для сборок, не помеченных как совместимые с CLS?
Как автор библиотеки OSS, я всегда старался сделать свои вещи совместимыми с CLS. Но MS не делает это легко. Они часто ставят вас в ловушку 22 ситуаций, таких как следующие:
- Вы не можете иметь защищенную переменную, отличающуюся только регистром от общедоступного свойства.
- Вы не можете иметь защищенные или общедоступные переменные, начинающиеся с символа подчеркивания или 'm_'.
- Если вы хотите сделать класс действительно расширяемым, вам часто нужноиметь защищенные переменные, соответствующие общедоступным свойствам. Ваш наименее уродливый выход - добавить к переменной суффикс, например "Var" или "Value". Это противно и неприемлемо для меня. Мне нравится чистый код.
Я не знаю .NET, которые не поддерживают переменные, начинающиеся с символа подчеркивания, и я использовал их во многих местах, где переменная должна быть видима для подклассов.
Я устал от предупреждений и планирую отключить совместимость с CLS на уровне сборки в моих 30+ библиотеках C#.
Существуют ли какие-либо фактическиепроблемы с отключением совместимости с CLS в библиотеках? Есть реальныепроблемы с этим?
На протяжении десятилетий Microsoft выпускала бесполезные руководства по программному обеспечению, в которых менее 5% из них стоили байтов, в которых они были закодированы. Я не могу найти никаких доказательств того, что эта передовая практикаимеет какой-либо реальный эффект. ни на что.
Но, чтобы быть осторожным, я проверяю.
И нет, это не дубликат обратного ответа на этот вопрос: Есть ли причина не помечать DLL как CLSCompliant?
Я ищу здесь фактические результаты и эффекты, а не совет стажера MS.
Например, если IronPython, IronRuby или F# не могут прочитать или записать переменную, начинающуюся с символа подчеркивания, это эффект, хотя это может вызвать проблему только для пользователей, создающих подклассы определенных объектов.
Если язык или инструмент полностью не может использовать сборку, если он не помечен как совместимый с CLS, это уже серьезно.