Почему маркировка является блоком ComVisible (верный) препятствовавший?
Я всегда отмечал свои блоки.NET как видимые к COM с [assembly: ComVisible(true)], думая, что я никогда не знаю, когда кто-то, возможно, должен был бы назвать их от COM. Я также начал использовать FxCop и начал видеть это предупреждение от анализа кода:
CA1017: Microsoft. Дизайн: Поскольку 'MyLibrary.dll' выставляет внешне видимые типы, отметьте его с ComVisible (ложь) на уровне ассемблера и затем отметьте все типы в рамках блока, который должен быть выставлен COM-клиентам с (верным) ComVisible
Есть ли некоторая причина, почему Вы просто не хотели бы все свои открытые типы, выставленные COM? Я предполагаю, что существует, но я не могу вообразить, какова эта причина. В любом случае это кажется заметно неудобным.
3 ответа
Главное, что экспорт COM-интерфейса не дается бесплатно, поскольку существуют несовместимости и требования, которые должны быть выполнены. Об этом нужно думать, а затем поддерживать. (Предупреждение CA1017 намекает на это.)
Поэтому я всегда работал с философией "opt-in", а не "opt-out", т.е. вместо того, чтобы делать все COM видимым, я помечаю сборку как не COM видимую. Затем я концентрируюсь на выборочном раскрытии types\members (т.е. по выбору), и убеждаюсь, что API, который раскрывается, является нормальным для COM (например, COM не поддерживает generics, перегрузку методов или конструкторы, принимающие параметры), а также что он был протестирован с учетом COM. Таким образом, экспонирование API для COM осуществляется строгим, проверенным, ограниченным и сопровождаемым образом.
Это противоположно тому, чтобы сделать все COM видимым, а затем беспокоиться о любых потенциальных проблемах позже, помня о том, что если вы открыли все, то могут возникнуть связи с пользователями вашего COM интерфейса, которых вы не ожидали, и теперь вам будет трудно от них отказаться.
По памяти пара примеров неожиданных последствий:
При экспорте перегруженных методов они экспортируются и именуются по умолчанию с порядковым номером, например, OverloadedMethod1, OverloadedMethod2 и т.д.. Если вы рефакторите свой код и измените порядок ваших методов или вставите перегрузку и т.д., у вас возникнут проблемы со всеми, кто использовал эти методы из вашего предыдущего COM-интерфейса. ПерегруженныйМетод1 и ПерегруженныйМетод2 могли быть поменяны местами.
Классы, открытые для COM, должны иметь конструктор без параметров. Если нет модульного теста, поддерживающего этот контракт, то впоследствии легко изменить класс так, чтобы он не имел конструктора без параметров, и тем самым нарушить работу пользователей COM-интерфейса.
С появлением Generics и других продвинутых типов, сейчас чаще методы раскрывают типы, которые не могут быть COM видимыми, чем раскрывают типы, которые могут.
Рекомендуемый метод в CA1017 призван побудить вас раскрывать только те типы, которые вы намерены раскрыть для COM.
Пометка сборки как невидимой для COM очень полезна , когда у вас есть куча общедоступных классов внутри, которые вы не хотите открывать для COM . Эти классы могут, например, быть прокси-классами веб-службы, которую использует ваша сборка. Либо вы тщательно помечаете каждый такой класс как не видимый COM, либо просто помечаете сборку как не видимую COM, а затем помечаете каждый класс для доступа к COM. Это гораздо более высокая степень контроля и меньше обслуживания.