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.