Estou no processo de atualização de algumas automações de VBScript datadas para o Powershell em um de nossos servidores que executam o Windows Server 2012 R2. Atualmente, estou trabalhando na substituição de um script que requer a criação de um objeto COM de uma DLL de 32 bits de terceiros. Primeiro, instalei o programa de terceiros que contém a DLL; instalou bem e funciona corretamente. Em seguida, tentei criar o objeto COM no Powershell, que falhou e me devolveu o erro "80040154 Classe não registrada" com um CLSID que não era todos os zeros.
Eu tentei solucionar problemas e descobri que ele criava o objeto COM se eu usasse o Powershell (x86). Imaginei então que talvez a DLL não estivesse registrada para o Powershell de 64 bits e usasse o sysWoW64 / regsvr32 para registrar a DLL. Isso não resolveu o problema, então eu também o registrei com system32 / regsvr32 que também não resolveu isso.
Voltei então ao Google e encontrei essa solução a partir de 2009: Link da solução . Isso realmente resolveu o problema, permitindo que o objeto COM fosse criado e usado no Powershell de 64 bits. No entanto, isso é muito mais um truque e ter que editar o registro manualmente não é a solução mais sustentável.
Então, minha pergunta é: como devo configurar corretamente uma DLL de 32 bits para executar com o Powershell de 64 bits? Qual é a maneira "correta" de executar a solução acima?
Se você está preso a esse tipo de DLL, provavelmente terá a melhor sorte se executar o script com a versão de 32 bits do Powershell ou VBscript do caminho SysWow64. Pode parecer ao contrário, mas os EXE de 64 bits estão localizados no System32.
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
C:\Windows\SysWOW64\cscript.exe