2014-01-08 2 views
3

У нас есть проект .NET exe (.NET 3.5, VS 2010 SP1, VB.NET), который является COM видимым. Приложение VB6 использует CreateObject для создания объекта из этой сборки.
Это работает без проблем, если мы не подписываем сборку. Если мы подписываем сборку (с PFX-сертификатом), CreateObject завершается с сообщениемCreateObject сбой для сборки COMVisible после его подписания

не удается создать объект «Our.ClassName»

К сожалению, не существует никаких записей в журнале событий , .NET exe можно запустить без каких-либо проблем, чтобы все зависимости были на месте. Мы также включили ведение журнала привязки .NET, но при создании CreateObject ничего не записываем (поэтому мы подозреваем, что создание не удалось до загрузки сборки).
Мы отслеживаем все изменения, единственное различие, которое имеет значение, заключается в том, подписана сборка или нет. Также мы пробовали разные сертификаты, но поведение не меняется.

Испытывал ли кто-либо такое поведение раньше и может предоставить решение? Существуют ли какие-либо способы, которые могут дать нам больше информации об отказе?

+0

Помогает ли http://stackoverflow.com/a/3747593/11683? – GSerg

ответ

1

Еще один подробный обзор реестра показал, что причиной было изменение номера версии сборки. Некоторое время назад была зарегистрирована версия 3.0.0.0 - очевидно, в версии без сильного имени. После некоторых изменений в процессе сборки версия была сброшена до 1.0.0.0.

REGASM зарегистрированная версия 1.0.0.0 в реестре, но (конечно) не удалось удалить версию 3.0.0.0 под ключ HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{00000000-0000-0000-0000-000000000000}\InprocServer32 в реестре, когда мы попытались перерегистрировать сборку.

CreateObject использует самую высокую версию при разрешении сборки и, таким образом, получает ссылку на сборку без сильного имени. Эта ссылка была привязана к сборке с версией 1.0.0.0 (поскольку она не была сильной, разница в версии не соблюдалась), чтобы она работала правильно для сборки без сильного имени.
Мы вернем версию до ее старого значения, чтобы поддерживать согласованность.

1

Сильное именование сборки изменяет свой PublicKeyToken. Которая является частью полного имени сборки, она записывается в реестр при регистрации сборки. В качестве примера запустите Regedit.exe и перейдите к HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{00000100-0000-0010-8000-00AA006D2EA4}\InprocServer32, значение сборки. Вы увидите:

дао, Version = 10.0.4504.0, культура = нейтральной, PublicKeyToken = 31bf3856ad364e35

Так регистрируя сборки еще раз после того, как вы его подписать это жесткое требование. Запустите Regasm.exe снова.

И не забывайте, что, если вы не используете параметр/codebase, вам нужно поставить сборку в GAC. Что является обычной причиной, чтобы дать сборке сильное имя в первую очередь.

+0

+1 для вашего всестороннего объяснения. Оказалось, что изменения в версии вместе с сильным именем привели к этой проблеме. Спасибо. – Markus

Смежные вопросы