GuidAttribute & ProgId, для чего они?
Поэтому я создаю плагин для Outlook, используя NetOffice.
В точке входа плагина это выглядит примерно так:
[GuidAttribute("d7066ab2-ac03-431a-bea5-b70d3efab2a5"), ProgId("OutlookPlugin"), ComVisible(true)]
Теперь я понимаю, что ComVisible бит устанавливает библиотеку как, ну, в общем, ComVisible. Я предполагаю, что это так, что я могу сделать отдельные классы ComVisible, а не всю библиотеку через Информация о сборке -> Сделать сборку COM-Visible.
Но я не понимаю, что GuidAttribute а также ProgId используются для?
3 ответа
Одна важная особенность COM заключается в том, что приложение может запрашивать объект класса, который создается, и COM сортирует, какой исполняемый файл реализует его, и загружает его для вас. Это требует хорошего способа идентификации компонента.
Вы скажете: "ну, не проблема, просто дайте ему имя". Проблема в том, что люди не очень хорошо выбирают хорошие имена. Есть целый класс парней по имени "Ганс", и я знаю по крайней мере еще одного парня, у которого есть мое точное имя. Где-то живет в Нидерландах, не знаю, кто он.
Это проблема, в отличие от имен людей, столкновения имен компонентов смертельно опасны. Вы загрузите совершенно неправильный компонент, и ваша программа потерпит крах. Поэтому дизайнеры COM решили, что единственным хорошим решением является глобальный уникальный идентификатор, номер, который гарантированно будет уникальным во всей известной вселенной и за ее пределами. GUID.
Приложение COM использует этот номер для запроса объекта, который будет создан. Основной функцией API является CoCreateInstance, первым аргументом является CLSID, который является guid, идентифицирующим класс.
Люди, однако, не очень хорошо запоминают очень длинные цифры. Таким образом, существует резервный способ идентификации компонента, он используется, в частности, в языках сценариев. Тип среды выполнения, в которой получить значение guid надежным способом не так просто. Так что к номеру все еще привязано имя. Это ProgId. Вы передаете его вспомогательной функции, которая обычно называется CreateObject(). Он делает один дополнительный шаг, использует вспомогательную функцию CLSIDFromProgID() для сопоставления имени с номером, затем вызывает CoCreateInstance. Излишне говорить, что иногда это может и не получаться.
Все COM-классы - также известные как CoClass(-ы) - и интерфейсы идентифицируются по их GUID (также известны как CLSID и IID соответственно). У CoClasses также есть ProgID, что является своего рода дружественным именем.
Все они хранятся в реестре, когда регистрируется компонент COM или сборка COM-Visible (соответственно, с помощью RegSvr32.exe или RegAsm.exe), и ссылаются друг на друга.
Для ProgId, я думаю, документация достаточно ясна по его использованию:
ProgID автоматически генерируются для класса путем объединения пространства имен с именем типа. Однако это может привести к неверному ProgID, так как ProgID ограничен 39 символами и не может содержать знаков препинания, кроме точки. В этом случае ProgID может быть назначен классу вручную с помощью ProgIdAttribute.
Причина, не указанная здесь, заключается в том, что его назначение вручную делает его согласованным для всех сборок.