Unable to create ActiveX object

[deramor]

Well I am running a run script VBP step. I can not see a setting to force the step to execute using the 32-bit cscript.exe. It defaults to the 64-bit version. I can of course write my own script, save the vbs file, and use a run program to launch the correct cscript but this is functionality that worked in the 32-bit version and now is not working. I have no problem making modifications to the step to make it use a different cscript but changing the step entirely is more serious.

This is the difference between 64-bit and 32-bit apps.
Further, I had issues with all of my Microsoft Visual Source Safe steps since the ss.exe could not be automatically determined. Likely, VBP is looking at the registry in a location but since VSS is a 32-bit program with a 32-bit installer, the appropriate registry key is in the 32-bit portion of the registry. This would be under the WOW3264Node.

The lookup fails so I assume that VPB does not take into account that the lookup is being performed in the 64-bit portion of the registry. This is a fundamental difference between different bitness processes.

[kinook]

Originally Posted by deramor

Well I am running a run script VBP step. I can not see a setting to force the step to execute using the 32-bit cscript.exe. It defaults to the 64-bit version. I can of course write my own script, save the vbs file, and use a run program to launch the correct cscript but this is functionality that worked in the 32-bit version and now is not working. I have no problem making modifications to the step to make it use a different cscript but changing the step entirely is more serious.[/I]

When using the 64-bit version of Visual Build, it uses 64-bit COM and can't call 32-bit COM objects (that's just the way Windows works). If InstallShield doesn't provide a 64-bit version of their COM components, you would either need to use the 32-bit version of Visual Build to call it from a Run Script action, or call from an external script via the 32-bit cscript.exe.

This is the difference between 64-bit and 32-bit apps.
Further, I had issues with all of my Microsoft Visual Source Safe steps since the ss.exe could not be automatically determined. Likely, VBP is looking at the registry in a location but since VSS is a 32-bit program with a 32-bit installer, the appropriate registry key is in the 32-bit portion of the registry. This would be under the WOW3264Node.

The lookup fails so I assume that VPB does not take into account that the lookup is being performed in the 64-bit portion of the registry. This is a fundamental difference between different bitness processes.

We will investigate whether the SourceSafe action looks up the 32-bit location properly in the 64-bit build. Most actions do handle this situation, but the SourceSafe action hasn't been updated in some time and may not have been updated. You can also work around this for now by specifying the full path in the Override field on the Options tab, or use the 32-bit version of Visual Build.

[deramor]

Yes, for the Source Safe action I did enter the path manually.

As far as the scripting goes, I was not aware that VBP was executing the script in process. Many times I notice that some steps generate temp files and execute those out of process so I though this may have been the case here. Running a .bat file comes to mind for example. I will use the 32-bit version for now until I can get a 64-bit automation API from Acresso.(not likely soon)

What are Kinook's plans for 32-bit support?

[kinook]

You are correct that actions which run other programs are executed in another process, but ActiveX scripting integration is in-process.

We don't have any plans to change or reduce support for the 32-bit edition.