Server.CreateObject Сбой при вызове объекта.Net из ASP в 64-разрядных окнах в 32-разрядном режиме IIS.

У меня есть сервер под управлением Windows 2003 64-разрядный, который запускает IIS в 32-разрядном режиме. У меня есть COM-объект, который был зарегистрирован с помощью следующей команды:

C:\WINDOWS\microsoft.net\Framework\v2.0.50727>regasm D:\Path\To\MyDll.dll /tlb:MyTLB.tlb /codebase

Когда я создаю объект через ASP, я получаю:

Server object error 'ASP 0177 : 8000ffff'

Server.CreateObject Failed

/includes/a_URLFilter.asp, line 19

8000ffff 

Когда я создаю объект в сценарии vbs и использую 32-битную версию cscript (в \Windows\syswow64), он работает нормально.

Я проверил разрешения на DLL, и IUSR имеет чтение / выполнение.

Даже если я добавляю IUSR в группу администраторов, я получаю ту же ошибку.

Это журнал фильтрации ProcessMonitor для пути моей библиотеки DLL (помеченный моими действиями):

[Stop IIS]
1:56:30.0891918 PM  w3wp.exe    4088    CloseFile   D:\Path\To\MyDll.dll    SUCCESS 
[Start IIS]
[Refresh ASP page that uses DLL]
1:56:42.7825154 PM  w3wp.exe    2196    QueryOpen   D:\Path\To\MyDll.dll    SUCCESS CreationTime: 8/19/2009 1:11:17 PM, LastAccessTime: 8/19/2009 1:30:26 PM, LastWriteTime: 8/18/2009 12:09:33 PM, ChangeTime: 8/19/2009 1:22:02 PM, AllocationSize: 20,480, EndOfFile: 20,480, FileAttributes: A
1:56:42.7825972 PM  w3wp.exe    2196    QueryOpen   D:\Path\To\MyDll.dll    SUCCESS CreationTime: 8/19/2009 1:11:17 PM, LastAccessTime: 8/19/2009 1:30:26 PM, LastWriteTime: 8/18/2009 12:09:33 PM, ChangeTime: 8/19/2009 1:22:02 PM, AllocationSize: 20,480, EndOfFile: 20,480, FileAttributes: A
1:56:42.7826961 PM  w3wp.exe    2196    CreateFile  D:\Path\To\MyDll.dll    SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Delete, AllocationSize: n/a, Impersonating: SERVER2\IUSR_SERVER2, OpenResult: Opened
1:56:42.7827194 PM  w3wp.exe    2196    CreateFileMapping   D:\Path\To\MyDll.dll    SUCCESS SyncType: SyncTypeCreateSection, PageProtection: 
1:56:42.7827546 PM  w3wp.exe    2196    CreateFileMapping   D:\Path\To\MyDll.dll    SUCCESS SyncType: SyncTypeOther
1:56:42.7829130 PM  w3wp.exe    2196    Load Image  D:\Path\To\MyDll.dll    SUCCESS Image Base: 0x6350000, Image Size: 0x8000
1:56:42.7830590 PM  w3wp.exe    2196    Load Image  D:\Path\To\MyDll.dll    SUCCESS Image Base: 0x6360000, Image Size: 0x8000
1:56:42.7838855 PM  w3wp.exe    2196    CreateFile  D:\Webspace\SecurityDll\bin SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: SERVER2\IUSR_SERVER2, OpenResult: Opened
1:56:42.7839081 PM  w3wp.exe    2196    QueryDirectory  D:\Path\To\MyDll.INI    NO SUCH FILE    Filter: SecurityDll.INI
1:56:42.7839281 PM  w3wp.exe    2196    CloseFile   D:\Webspace\SecurityDll\bin SUCCESS 

[Refresh ASP page that uses DLL]
[Refresh ASP page that uses DLL]
[Refresh ASP page that uses DLL]

Эта dll отлично работает на других серверах под управлением 32-битных окон. Я не могу думать ни о чем другом, что сделало бы эту работу. Какие-либо предложения?

UPDATE>

.Dll отсутствует в GAC, он скомпилирован как 32-разрядный и имеет строгую подпись.

5 ответов

Да, если библиотеки.NET DLL скомпилированы для 64-битных систем, забудьте об этом:(. 32-битные и 64-битные модули не могут смешиваться (COM или без COM) в одном процессе.

Пара вещей для проверки:

  • Проверьте, находится ли этот.dll также в глобальном кэше сборок (этого не должно быть). Посмотрите в панели управления | Средства администрирования для конфигурации.NET Framework 2.0, которые позволят вам проверить GAC
  • Сборка должна быть строго названной, сборка (подписанная и все такое)

Взгляните на страницу MSDN регазма.

Кроме того, этот.dll не был скомпилирован для 64-битного, не так ли? (просто чтобы исключить очевидное...)

Я пытался сделать то же самое, но с Win 7 и IIS 7.5. В конце концов мне удалось заставить его работать, используя как 32-битную, так и 64-битную версии REGASM, но я не смог точно определить, какая из них обеспечивала работу системы.

Вы, ребята, должны научиться читать - это не asp.net.

  • Хорошо, во-первых: 32-битный это хорошо, но 32-битный режим IIRC НЕ для ASP, ТОЛЬКО для ASP.NET.
  • Таким образом, ASP (классический ASP, на который указывает ваш URL) все равно будет 64-битным.
  • И так как вы не можете загрузить 32-битный компонент в 64-битном пространстве процесса - все готово. Ошибка объяснена.

В основном я предлагаю вернуться и установить 32-битную ОС здесь, а затем среднесрочную (как можно скорее) удалить ASP для ASP.NET.

Другие вопросы по тегам