Как предотвратить Windows от кеширования Com Class info?
Windows 7 кэширует некоторую информацию о COM-классе. Старые ОС этого не делали. После того как ОС просмотрит значение HKCU\Software\Classes\CLSID\{GUID}\LocalServer32, оно кэширует значение и больше не ищет его.
Когда мы обновляем наше программное обеспечение, мы размещаем новые обновления в другом каталоге, а затем обновляем значение HKCU\Software\Classes\CLSID\{GUID}\LocalServer32, чтобы отразить новый путь. В следующий раз, когда программное обеспечение запустится, он будет использовать последние файлы, если работает под старыми ОС Windows. Однако в Windows 7 он будет продолжать использовать старый файл, пока ОС не будет перезагружена.
Я запустил монитор процесса и обнаружил, что в Windows 7 он никогда не читает раздел реестра после первого чтения. В более старых ОС он каждый раз читает этот ключ.
Мой вопрос: есть ли способ заставить Windows 7 перечитывать информацию LocalServer32 из улья HKCU каждый раз, когда создается новый из COM-объекта proc?
Ответы
Ответ 1
Я смог решить эту проблему только...
1: остановка процесса
2: явно отменить регистрацию с использованием regsvr32 в библиотеке (или exename/unregserver)
3: Регистрация нового компонента
4: Запуск процесса резервного копирования.
Я подозреваю, что это часть Un Reg, которая терпит неудачу для вас. Если вы просто меняете ключ реестра напрямую, тогда вы должны вызвать RegSvr32/u.
Также убедитесь, что новое расположение каталога является текущим каталогом при вызове RegSvr32.
Обратите внимание, что я всегда останавливал процесс, а затем незарегистрирован, это, вероятно, значительная деталь.
Ответ 2
Поскольку это самый высокий результат в Google для этой узко-проблемной проблемы, я подумал, что было бы полезно добавить мой результат устранения неполадок для этой проблемы.
Я нашел этот ответ на SO: С#: Как изменить реестр Windows и вступить в силу немедленно
И связанное решение из этого ответа: Registry Watcher С#
Оба варианта кажутся жизнеспособными для управления измененными ключами без принудительной перезагрузки. Для нас (например, OP) это было при установке обновлений. Для нас (возможно, в отличие от OP) это редко, и мы решили, что усилия по внедрению и тестированию исправления, как описано, перевешиваются простым решением, требующим перезагрузки: процесс, который пользователи Windows ожидают от установки программного обеспечения в любом случае.
