У нас есть приложение, которое использует COM dll.Now, мы нажимаем обновления этой DLL. Мы скопируем новую dll (перезаписываем существующую) и зарегистрируем dll. Это хорошая практика. Или мы должны сначала отменить регистрацию dll уже на машине клиента.Обновление com dll
Пока старый DLL COM реализует те же интерфейсы, что нет никаких оснований для отмены регистрации/регистрация
Две вещей, которые вы должны учитывать, если вы хотите просто заменить Com Dll:
в противном случае вы должны UNREG/рег ваш COM DLL
При обновлении DLL, COM, мы не должны изменить старые интерфейсы т.е. идентификаторы IID (основное правило COM), так что он не будет ломать клиентов, которые используют старые интерфейсы.
Так что нет необходимости удалять старые DLL COM, просто зарегистрируйте новую DLL. После регистрации новой dll, поскольку старый интерфейс использует тот же IID, он не будет разорвать клиентов, которые используют старый интерфейс.
Ну, предположим, что вы пишете свой COM-сервер, используя VB6 (общий случай за пару лет до этого), вам нужно установить его бинарным совместимым, чтобы VB сохранял одинаковые идентификаторы GUID для компонента.
Поскольку объекты для классов в DLL большую часть времени создаются с использованием фабрики классов, встроенной в одну и ту же DLL, если идентификаторы GUID не соответствуют тем, которые Class Factory знает об этом, не могут создавать объекты для старых идентификаторов GUID даже если никаких изменений в интерфейсах не было.
Это было частью DLL Hell, помните?
Если вы знаете, что все клиентские платформы работают под управлением Windows XP или более поздней версии, возможно, вам стоит использовать Registration Free COM и тем самым избежать всей проблемы.
Для получения более подробной информации см. my answer to "How to register COM libraries at runtime?". В статье "Registration-Free Activation of COM Components: A Walkthrough" on MSDN есть полный обзор того, что делать.