Когда менять GUID в библиотеке типов
Я знаю, что когда вы добавляете / меняете / удаляете методы в COM-интерфейсе, вы должны изменить GUID интерфейса / компонентного класса, но как насчет библиотек типов. Когда следует менять GUID библиотеки типов? Вы меняете его, если GUID внутри библиотеки типов изменился? Или вы должны изменять его только тогда, когда изменяется что-то, у которого нет собственного GUID в библиотеке типов.
Ответы 2
Основной принцип заключается в том, что COM-интерфейсы и библиотеки типов должны быть неизменными (то есть никогда не должны меняться). Если вы изменяете один элемент внутри COM-интерфейса, новая версия должна быть полностью отдельной сущностью от предыдущей версии. Единственный способ сделать это - изменить GUID для каждого интерфейса в библиотеке и GUID для самой библиотеки типов. Также неплохо (для вашего личного здравомыслия) изменить имя библиотеки типов.
В идеале вы никогда не должны менять COM-интерфейс. Вместо этого создайте новый производный COM-интерфейс и опубликуйте его в новой библиотеке типов.
У меня похожий вопрос.
У меня был оригинальный элемент управления с CLSID_A, который реализовал интерфейс IID_A в некоторой библиотеке типов 1.0 с GUID_A
Позже я решил добавить новый интерфейс к исходному элементу управления. Затем он будет реализовывать интерфейсы IID_A и IID_B. Я подумал, что мне, вероятно, следует сохранить тот же CLSID, но не знал, что делать с самой библиотекой типов. Я в основном занимался написанием программ на VC++ по книге, в котором задействован QueryInterface, и меня не волновало управление версиями и библиотека типов. Вы хотели создать объект с определенным CLSID, вы просто запросили экземпляр CoCreated ... а затем запросили интерфейс для потенциальной поддержки нового интерфейса ...
Теперь, когда я попадаю в более изящные среды, такие как LabVIEW, или среды разработки во время разработки, такие как Microsoft .NET, вещи MFC, кажется, ломаются.
В своем ответе вы упоминаете об изменении всего GUID. Неужели вся парадигма адаптации приложения на основе доступной функциональности мертва, что новое приложение все еще может использовать свои базовые функции со старой версией элемента управления? Возможно, я не уловил более позднюю волну, а именно: нет смысла адаптировать приложение для работы с использованием старой контрольной версии, просто требуется определенная контрольная версия. Это могло быть причиной того, что M $ также выпустили проект ASSEMBLY.
Не вся история! Вы можете добавлять новые интерфейсы и типы без обновления существующих GUID, включая GUID библиотеки типов. Вы можете также добавить новые интерфейсы к существующим классам. Это означает, что вы можете добавлять новые функции, не нарушая существующий скомпилированный код. См. msdn.microsoft.com/en-us/library/7ydsx43e.aspx. Итак, библиотеки типов может меняйте!