Как зарегистрировать 64-битную DLL без gacutil

Question

У меня есть приложение ASP Classic, которое ссылается на некоторые VB6 COM-ОБЪЕКТЫ. Один из этих COM-ОБЪЕКТОВ VB6 ссылается на другую .Net DLL третьей стороны.

Сторонняя библиотека .Net DLL должна быть зарегистрирована на компьютере под управлением Windows Server 2008 R2 x64.

Я нашел сценарии для регистрации DLL в GAC без GACUTIL с использованием powershell (ref: http://weblogs.asp.net/adweigert/archive/2008/10/31/powershell-install-gac-gacutil-for-powershell.aspx)

Теперь мне нужно зарегистрировать сборку. Я использовал GACUTIL и REGASM на своей локальной машине для разработки (x86) без заминки. Но когда я пытаюсь получить DLL на тестовом сервере, у меня возникают проблемы.

Первый выпуск : НЕТ GACUTIL

На сервере нет GACUTIL, который я использовал, используя скрипт, упомянутый выше. Я понимаю, что его можно установить с помощью SDK, но я не хочу "загрязнять" окружающую среду.

Второй выпуск : REGASM НЕ МОЖЕТ НАЙТИ В СБОРКЕ

REGASM в 32-битной .Net Framework не находит DLL. Сообщение об ошибке: «RegAsm: ошибка RA0000: невозможно найти входную сборку« C: \ Windows \ System32 \ xxxxx.dll »или одну из ее зависимостей».

Итак, я использовал 64-битный вариант RegAsm, и это сработало.

Я обеспокоен тем, что это ложный положительный результат в том, что ASP classic не находит сборку, так как она не зарегистрирована 32-битным RegAsm.

Я запускаю свое приложение, в журнале событий появляются ошибки: «Компонент ActiveX не может создать объект». Вообще говоря, это происходит потому, что он не может найти объект для создания, что означает, что DLL-библиотека, в которой находится объект, зарегистрирована неправильно.

Итак, сейчас я пытаюсь выяснить, существует ли альтернативный метод REGASM, использующий powershell, который регистрирует сборку в 32-битной области.

Кто-нибудь знает, возможно ли это и каков будет сценарий, чтобы сделать это правильно?

Answer 1

Я обнаружил, что помещаю .Net DLL в неправильную папку на тестовой машине для регистрации.

В операционной системе Windows 64Bit у вас есть папки System32 и SysWOW64. Я поместил свою DLL в папку System32, где она должна была находиться в папке SysWOW64.

Ошибка, полученная от RegAsm («RegAsm: ошибка RA0000: невозможно найти входную сборку« C: \ Windows \ System32 \ xxxxx.dll »или одну из ее зависимостей»), должна была заставить меня щелкнуть, но я ее пропустил .

В основном 32-битный RegAsm не смог найти мою DLL, но 64-битный RegAsm мог найти мой файл и, зарегистрировав сборку с 64-битным RegAsm, я поместил DLL в 64-битную область. Мне нужно, чтобы он был в 32-битной области.

Я переместил DLL-форму System32 в SysWOW64, и 32-битный RegAsm обнаружил DLL и зарегистрировал ее в 32-битной области.

Теперь мой COM-объект VB6 может найти .Net DLL, и он работает без ошибки «Компонент ActiveX не может создать объект».

Учитывая все вышесказанное, я не нашел библиотеку или функцию, которая будет выполнять ту же работу, что и RegAsm, без фактического использования RegAsm.

Если кто-нибудь найдет этого мифического зверя, пожалуйста, ответьте на этот вопрос. Заранее спасибо.

Answer 2

Не уверен, но ваша проблема, похоже, связана с побочным эффектом UAC Virtualisation (, эта статья также может помочь ), который существует в Vista и все еще действует здесь.Суть в том, что системные части файловой системы и реестра теперь защищены от доступа пользователей, но если предположить, что старые (32-разрядные) программы продолжают работать в системе, заставьте их поверить, что они пишут на этих частях, но на самом деле он перенаправляет их на пользователя.мест.Загляните в "HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node" в вашем реестре.

Проблема, с которой я недавно столкнулся, состоит в том, что мой MSI был собран с 32-битной библиотекой, поэтому при вызове этих библиотек во время установки на 64-битную машину делаютВиртуализация UAC установить мои ключи реестра в Wow6432Node. Эта интернет-статья помогает мне решить проблему.Я использую Orca, чтобы заменить Installutillib.dll от 32 до 64 бит.

Надеюсь, это поможет

JP