|
#1
|
|||
|
|||
Unable to create ActiveX object
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? |
#2
|
|||
|
|||
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 |
#3
|
|||
|
|||
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. |
#4
|
|||
|
|||
Quote:
Quote:
|
#5
|
|||
|
|||
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? |
#6
|
|||
|
|||
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. |
|
|