Когда менять GUID для библиотеки типов

Question

Я знаю, что когда вы добавляете / меняете / удаляете методы в COM-интерфейсе, вы должны изменить GUID интерфейса / coclass, но как насчет библиотек типов. Когда вы должны изменить GUID библиотеки типов? Вы меняете его, если изменился GUID внутри библиотеки типов? Или вы должны изменить его только тогда, когда что-то, у кого нет собственного GUID в библиотеке типов, изменится.

Answer 1

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

В идеале, вы никогда не должны менять интерфейс COM. Вместо этого создайте новый производный интерфейс COM и опубликуйте его в новой библиотеке типов.

Answer 2

У меня похожий вопрос.

У меня был оригинальный элемент управления с CLSID_A, который реализовал интерфейс IID_A в некоторой библиотеке типов 1.0 с GUID_A

Позже я решил добавить новый интерфейс к исходному элементу управления. Затем будут реализованы интерфейсы IID_A и IID_B. Я подумал, что, вероятно, мне следует сохранить тот же CLSID, но я не знал, что делать с самой библиотекой типов. В основном я занимался программированием на языке VC ++, которое включало QueryInterface и меня мало интересовало управление версиями и typelib. Вы хотели создать объект с определенным CLSID, вы просто запросили экземпляр CoCreated ... и затем запросили интерфейс для потенциальной поддержки нового интерфейса ...

Теперь, когда я попадаю в более причудливые среды, такие как LabVIEW, или в среды разработки с отложным внедрением во время разработки, такие как Microsoft .NET, MFC, похоже, ломается.

Вы упоминаете в своем ответе, чтобы изменить все GUID. Является ли целая парадигма адаптации приложения на основе доступной функциональности мертвой, что более новое приложение все еще может использовать свои базовые функциональные возможности с более старой версией элемента управления? Возможно, я не уловил более позднюю волну: нет смысла адаптировать приложение для запуска с использованием старой версии элемента управления, просто требуется специальная версия элемента управления. Это было бы причиной, по которой M $ также выпустил сборку.