Разоблачение .NET сборки как COM 101 - PullRequest
Новая
       5

Разоблачение .NET сборки как COM 101

1 голос
/ 25 марта 2010

У меня проблема с выставлением сборки .NET в COM. Кажется, что я, должно быть, пропускаю какой-то базовый шаг, потому что я думаю, что следовал всем учебникам и документации, которые нашел, а также здравому смыслу, но все же, когда делаю (в тестовом VBScript): 

Set o = CreateObject("MyLib.MyClass")

Он продолжает говорить, что объект не может быть создан.

Вот шаги, которые я сделал:

  1. У меня есть простой класс с одним методом, без атрибутов.
  2. Класс находится в библиотеке классов, в которой в Visual Studio установлен флажок "Сделать сборку видимой для COM" .
  3. Библиотека классов подписана.
  4. DLL регистрируется через RegAsm.exe с параметром / codebase (я не хочу / не могу добавить DLL в GAC).

Просто чтобы быть уверенным, я попытался скопировать библиотеку в тот же каталог, что и тестовый VBScript, но это не помогло.

Редактировать: Я должен был упомянуть, что я могу создать экземпляр класса в COM, если я помещу DLL в GAC.

Редактировать: Решено. У меня нет полного объяснения, но в конце концов я обнаружил, что это было вызвано с помощью:

% Windir% \ Microsoft.NET \ Framework \ v2.0.50727 \ regasm.exe

а не 64-битная версия:

% Windir% \ Microsoft.NET \ Framework64 \ v2.0.50727 \ RegAsm.exe

Я сравнил сгенерированные ключи реестра двух RegAsm, и они были одинаковыми. Так что догадываясь, что они генерируют что-то еще, а не ключи реестра.

Ответы [ 4 ]

2 голосов
/ 25 марта 2010

Да, это предусмотрено 64-разрядными операционными системами. Многие COM-компоненты являются внутрипроцессными DLL-библиотеками и доступны только как 32-битные DLL-библиотеки. 64-битная программа не может загрузить любой 32-битный код. Чтобы предотвратить их сбои, реестр виртуализирован; разные программы имеют разные представления реестра.

32-битные программы на самом деле видят ключи в HKLM \ Software \ Wow6432 \ Classes. 64-битные программы видят обычные ключи. Это автоматически позволяет избежать сбоев COM-сервера.

.NET-серверы необычны тем, что могут работать как в 32-битном, так и в 64-битном режиме, об этом позаботится JIT-компилятор. Обычно вы должны запускать обе версии Regasm.exe. Один из папки Framework зарегистрирует сервер для 32-битных программ, другой из папки Framework64 зарегистрирует его для 64-битных программ.

2 голосов
/ 25 марта 2010

Вы должны добавить несколько атрибутов:

для интерфейса: 

[Guid("4200ead6-8252-412c-8c7e-c3b586ac40d6")]
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]

для класса: 

[Guid("9f718717-bc09-48f1-8ab1-00fa3abf4147")]
[ClassInterface(ClassInterfaceType.None)]
[ProgId("MyLib.MyClass")]
1 голос
/ 25 марта 2010

Вы можете использовать Microsoft Fusion Logger http://msdn.microsoft.com/en-us/library/e74a18c4.aspx, чтобы узнать, почему ваша сборка не загружается (или не привязывается, как она называется).

0 голосов
/ 25 марта 2010

У меня нет полного объяснения, но в итоге я обнаружил, что это было вызвано использованием: 

%windir%\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe

, а не 64-битной версией: 

%windir%\Microsoft.NET\Framework64\v2.0.50727\RegAsm.exe

Я сравнил сгенерированные ключи реестра двух RegAsm, и они были одинаковыми.Так что догадываясь, что они генерируют что-то еще, а не ключи реестра.

...