InstallShield Automation无法创建对象

Question

I am working with Installshield 2014 and 2011. I'm using major upgrades and automated build scripts to handle the build. InstallShield is the stand alone build ver. for both.

Now everything worked fine with Installshield 2011 on windows 2003 servers. I could use the automation interface to open a project, change the product code (for the major upgrade) then save it right before building the installer.

The code for such is in a vbs file as such:

Dim oISM, oGUID
Set oGUID = CreateObject("InstallShield.GUID")
Set oISM = CreateObject("IswiAuto17.ISWiProject")

oISM.OpenProject strInstallShieldProjectFile
oISM.ProductCode = "{" & oGUID.CreateGUID( ) & "}"
oISM.SaveProject : oISM.CloseProject : set oISM = Nothing

Now we've upgraded to windows 2012 servers and InstallShield 2014. I've double checked and according to InstallShield the only change needed is the ver number (17 changes to 21).

But now nothing works. If I take the code out and put it in it's own vbs file for testing and run it, I get this:

ActiveX component can't create object: 'InstallShield.GUID'

Looking on google I see that's from running in 64 bit mode.... but I'm not. I'm running a cmd prompt in 32 bit mode. http://helpnet.flexerasoftware.com/installshield18helplib/AutomationInterface64Bit.htm

I tried calling the script with: %WINDIR%\\SYSWOW64\\cmd.exe /c cscript

as suggested here: How do I run a VBScript in 32-bit mode on a 64-bit machine?

and other places. This did not work as I got the same error.

I tried removing that line as I'm sure I can create a guid another way, and reran it.

Then I got this when it tries to create the project: Unknown runtime error: 'CreateObject'

Once again google came up and I checked: https://community.flexerasoftware.com/showthread.php?189788-Automation-error

and couple others. I tried ensuring the dll was registered using the regsvr32 and it said it was successful. But after rerunning, it gave the same error.

I tried directly coping the command from the InstallShield documentation to ensure no spelling mistakes but again same error.

I even tried switching the case of the "sw" as mentioned here: Installshield Automation is failing while running vbscript with error unable to create object

Again though, same error.

I also tried switching to powershell as powershell is much easier to debug and read.

The powershell code is simple and is as follows:

$oIsm =  new-object -comobject IswiAuto21.ISWiProject

$oISM.OpenProject("$file")
$oISM.ProductCode = "{" + [guid]::NewGuid() + "}"
$oISM.SaveProject(); $oISM.CloseProject(); $oISM = $null

But this also does not work despite these saying it should: https://community.flexerasoftware.com/showthread.php?190769-Automation-using-Powershell http://blogs.flexerasoftware.com/installtalk/2011/01/getting-started-with-installshield-automation-and-powershell.html

When I use the 32 bit powershell I get this error:

new-object : Creating an instance of the COM component with CLSID {78D393F9-76E3-438C-9CAB-6664EF5FE1F2} from the IClassFactory failed due to the following error: 800a801d Exception from HRESULT: 0x800A801D.

If I run solely the vbs without a cmd prompt I also see the error of 800A801D in a pop up box.

How can I fix this? I'd like to use powershell but a vbs fix would help as well at this point. I have tried everything I can think of and google says I'm doing it correctly (32 bit powershell/cmd, registering the dll, creating the object, etc).

Answer 1

Did you install the automation interface? Typically it's an optional feature that's set to absent when you install InstallShield.

Answer 2

Typically the HRESULT should tell you what's wrong, or be so generic that it doesn't help. In this case, it's a bit of an enigma as I haven't found its definition anywhere. The leading 0x800A... indicates FACILITY_CONTROL and the trailing ...801d happens to match the tail of TYPE_E_LIBNOTREGISTERED (0x8002801D) , but I don't know whether that's meaningful. Unfortunately FACILITY_CONTROL is defined by the control that issues the error, and that's not clear here.

Let's try to figure out what's wrong. My bet is on COM registration. If you want, you can skip to a likely fix by running regsvr32 C:\\...\\System\\ISWiAutomation21.dll .

So let's follow what CreateObject("IswiAuto21.ISWiProject") will do. First it has to look up the ProgID:

C:\>reg query HKCR\ISWiAuto21.ISWiProject\Clsid

HKEY_CLASSES_ROOT\ISWiAuto21.ISWiProject\Clsid
    (Default)    REG_SZ    {78D393F9-76E3-438C-9CAB-6664EF5FE1F2}

Then it has to look up the CLSID, and in this case, its InprocServer32 key:

C:\>reg query HKCR\Clsid\{78D393F9-76E3-438C-9CAB-6664EF5FE1F2}\InprocServer32

HKEY_CLASSES_ROOT\Clsid\{78D393F9-76E3-438C-9CAB-6664EF5FE1F2}\InprocServer32
    (Default)    REG_SZ    C:\...\ISWiAutomation21.dll
    ThreadingModel    REG_SZ    Apartment

If either of these are missing, it will be unable to find the COM server. In addition, the TypeLib subkey and the Type Library it references are both important:

C:\>reg query HKCR\Clsid\{78D393F9-76E3-438C-9CAB-6664EF5FE1F2}\Typelib

HKEY_CLASSES_ROOT\Clsid\{78D393F9-76E3-438C-9CAB-6664EF5FE1F2}\Typelib
    (Default)    REG_SZ    {92278CC1-987E-4A01-940C-47DCADF27496}


C:\>reg query HKCR\Typelib\{92278CC1-987E-4A01-940C-47DCADF27496}\1.1\0\win32

HKEY_CLASSES_ROOT\Typelib\{92278CC1-987E-4A01-940C-47DCADF27496}\1.1\0\win32
    (Default)    REG_SZ    C:\...\ISWiAutomation21.dll

If any of this information is missing, it will have to be repaired. The COM Server itself may need to probe several additional IDs at this point, so there's a chance that even if this subset is okay, there are others that are missing or corrupted. Self-registering the COM server should fix this. So should running the installation's repair.

Note that all of these queries were done using the 32-bit command C:\\Windows\\SysWow64\\reg.exe , or you can peruse the registry visually with C:\\Windows\\SysWow64\\regedit.exe .