Я нахожусь в процессе обновления некоторой устаревшей автоматизации VBScript для Powershell на одном из наших серверов под управлением Windows Server 2012 R2. В настоящее время я работаю над заменой сценария, который требует создания COM-объекта из сторонней 32-разрядной библиотеки DLL. Сначала я установил стороннюю программу, которая содержит эту DLL; он установлен нормально и работает правильно. Затем я попытался создать COM-объект в Powershell, но это не удалось и вернуло мне ошибку «80040154 Class Not Registered» с CLSID, который НЕ состоял полностью из нулей.
Я попытался устранить неполадки и обнаружил, что он создает COM-объект, если я использовал Powershell (x86). Тогда я подумал, что, возможно, DLL не была зарегистрирована для 64-битной Powershell и использовал sysWoW64 / regsvr32 для регистрации DLL. Это не решило проблему, поэтому я также зарегистрировал ее с помощью system32 / regsvr32, которая также не решила ее.
Затем я обратился к Google и нашел это решение 2009 года: Ссылка на решение. Это действительно решило проблему, позволив создавать и использовать COM-объект в 64-битной Powershell. Однако это во многом хитрость, и необходимость редактировать реестр вручную - не самое удобное решение.
Итак, у меня такой вопрос: как мне правильно настроить 32-битную DLL для работы с 64-битной Powershell? Каков «правильный» способ выполнения вышеуказанного решения?
Если вы застряли с такой DLL, вам, вероятно, больше всего повезет, если вы запустите скрипт с 32-битной версией Powershell или VBscript из пути SysWow64. Это может показаться отсталым, но 64-битные EXE расположены в System32.
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
C:\Windows\SysWOW64\cscript.exe