Наши тестеры сообщают о некоторых странных поведении. Мы регистрируем некоторые COM-видимые компоненты .Net 2.0, используя RegAsm..Net DLL, зарегистрированная через RegAsm, даже если DLL переименована. Как так?
По какой-то причине тестеры переименовали зарегистрированную DLL, и странно, что приложение продолжает загружать все компоненты. Я этого не ожидал!
Система отслеживает зарегистрированные файлы для изменения имени?
Не зная, что используемая вами командная строка Regasm.exe делает это предположение, немного ненужным. То, что вы не знали, что это важно, наверняка уже является хорошим объяснением, почему вы не ожидали результата теста. Простое объяснение состоит в том, что они просто переименовали неправильную DLL.
Regasm.exe настоятельно рекомендует вам установить сборку в GAC и громко жалуется, когда вы этого не сделаете, и используйте/codebase. Это хорошая идея, DLL Hell - довольно большая проблема в COM, если клиент не использует манифест. Поэтому, если вы сделали это правильно, маловероятно, что они взломали GAC, его трудно найти, а каталог довольно недоступен в версиях .NET до версии v4. И, конечно, DLL Hell достаточно, чтобы объяснить, что они наблюдали :)
Вы сокращаете его, просматривая записи реестра с помощью Regedit.exe. Если вы не знаете, где искать, вы можете использовать утилиту SysInternals ProcMon. Используйте его во время запуска Regasm.exe, вы увидите, что он записывает ключи реестра. Если вы не используете атрибут [Guid] на классах ComVisible, безопасный способ, то эти места, которые вы будете искать в реестре, зависят от версии вашего интерфейса и класса. Внесение изменений в них изменяет автоматически генерируемый guid.