Quote:
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.
Quote:
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.