Есть ли смысл указывать Guid при использовании ComVisible (false)? - PullRequest
37 голосов
/ 27 февраля 2010

Когда вы создаете новый проект C # в Visual Studio, сгенерированный файл AssemblyInfo.cs содержит атрибут, указывающий GUID сборки. В комментарии над атрибутом указано, что он используется «если этот проект открыт для COM».

Ни одна из моих сборок не содержит типов, которые должны быть видимы для COM, поэтому я пометил свою сборку [assembly: ComVisible(false)]. Так есть ли смысл указывать GUID?

Мне кажется, что ответ "нет" - так почему файл AssemblyInfo.cs по умолчанию содержит как [assembly: ComVisible(false)], так и [assembly: Guid("...")]?


Edit:

Подведем итоги ответов:

Между ними ответы объясняют, что указание GUID требуется тогда и только тогда, когда используется COM-взаимодействие. Так что в моей ситуации GUID не нужен.

sharptooth дополнительно объясняет, что [assembly: ComVisible(false)] не подразумевает не использование COM-взаимодействия, так как возможно переопределить ComVisible для отдельных типов. По этой причине файл AssembyInfo.cs по умолчанию содержит как [assembly: ComVisible(false)], так и GUID.

Ответы [ 3 ]

15 голосов
/ 27 февраля 2010

Наличие [assembly: ComVisible(false)] и [assembly: Guid("...")] одновременно имеет смысл в некоторых случаях . Вы начинаете с пустой сборки и, возможно, захотите открыть что-то из нее для COM. Таким образом, вы помечаете сборку как не ComVisible, а позже помечаете сущности для показа как ComVisible. Вот почему GUID существует по умолчанию .

Независимо от того, если вы действительно не хотите выставлять что-либо из вашей сборки в COM, оставьте флажок «Зарегистрироваться для взаимодействия COM» не установленным в настройках проекта.

9 голосов
/ 27 февраля 2010

Согласованные GUID абсолютно необходимы в COM. Атрибут [assembly: Guid] генерирует библиотеку типов LIBID. Конечно, шаблон проекта автоматически генерирует его, чтобы убедиться, что программист не забывает предоставить его, когда он / она переключает ComVisible в true.

Если сборка [Guid] не предоставлена, Tlbexp.exe синтезирует ее из имени сборки, версии и открытого ключа. Это не совсем хорошо, у библиотек типов уже есть версия. Изменение [AssemblyVersion] приведет к созданию другого LIBID. Особенно плохо, когда вы используете опцию автоинкремента для версии (например, 1.0. *), Вы можете быстро заполнить реестр кучей мертвых ключей реестра TypeLib.

Короче говоря, он избегает многих неприятных неудач.

4 голосов
/ 27 февраля 2010

Нет, нет реальной причины, чтобы включить его. Это действительно довольно ненужно, за исключением очень специфических сценариев взаимодействия COM. Хотя я полагаю, что может быть что-то полезное в том, чтобы иметь GUID, к которому вы можете получить доступ с помощью отражения. Но так как это не гарантировано, это не значит, что вы можете на это положиться.

...