Unable to create ActiveX object

[deramor]

Hello-

I am using VBP 8.0 x64 version. I am trying to get a previously working build to work with this version. The previous build was working in 32-bit VBP 8.0.

I am trying to run a VBScript step. I try to create an Installshield object:
Set objInst = CreateObject("ISWiAuto16.ISWiProject")
I get the following error:
(ActiveX component can't create object: 'ISWiAuto16.ISWiProject')

I know little about COM however I do know that the type is registered under CLSID as well as its GUID. I was doing some Google searches and came across this blog entry:
http://blogs.msdn.com/b/helloworld/a...t-machine.aspx

This article states that for a 64-bit pc, you need to run your script which contains 32-bit objects with the 32-bit cscript. This follows all other Microsoft programming models since they do not allow mixing different bitness in the same process. I know that Installshield is a 32-bit native program and VBP is a native 64-bit application. They would need to be in separate processes. How does VPB launch a script? Does it take the provided text from the editor and generate its own temp vbs file and then launch it? I believe if this is the case, on a 64-bit system with a 64-bit native program, it will use the 64-bit native cscript.exe. Likely getting the registered app to run that file extension (which is the 64-bit cscript on Win7 64-bit). This will not work with 32-bit objects which are the majority of the world. Even all of the Visual Studios currently released are 32-bit processes. Is there a way to force the script to run the 32-bit version of the cscript.exe?

[kinook]

As mentioned in that article, to run the 32-bit cscript.exe from a 64-bit executable such as the x64 edition of VBP v8, run

%WINDOWS%\SysWOW64\cscript.exe

[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.