cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
stijnv
Level 3

Why does IScmdBld add a slash after path variables (Installshield does not)?

I have build events to sign using signtool (cannot use Installshield's signing stuff because the certificate is on a Safenet USB token). Such command looks like this:

<MC_SIGNTOOL_PATH> sign /sha1 <MC_SIGNING_CERTIFICATE_HASH> /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 "<ISReleasePath>\<ISProductConfigName>\<ISReleaseName>\DiskImages\DISK1\Setup.msi"

The MC_ values are path variables and have default values, made so all of this works when building from within InstallShield.

When building the same project using ISCmdBld though, it adds a backslash to the path variables after substituting them which leads to an error because the hash passed to signtool ends with a slash now. This is from the verbose output of the build, showing the substitution:

BuildEventThread: launching event command line: '"C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\signtool"\ sign /sha1 3176a76f24ee1382d9d31b3dc11409d4764d83e9\ /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 "c:\build\Product\SINGLE_EXE_IMAGE\DiskImages\DISK1\Setup.msi"'

 

Is there a way to stop this behaviour?

Isn't this actually a bug (because it seems to differ from what InstallShield does, plus because adding backslashes to variables even though they are meant for paths yields different strings)?

 

Labels (1)
0 Kudos
(7) Replies
banna_k
Revenera
Revenera

Hi @stijnv,

Can you check how you are passing the path variable,

can you try the same with path variable value not ends with back slash.

And, you can override the path variable value from the Iscmdbld using -l option. 

-l <path variable>="new path"

Advanced UI, Basic MSI, InstallScript, InstallScript MSI, InstallScript Object, Merge Module, Suite/Advanced UI

Use this parameter to override a path variable that has been specified in the Path Variables view. You can specify this parameter multiple times, once for each path variable override. For example:

ISCmdBld.exe -l VariableName="C:\Path" -l VariableName2="C:\Path2"

To reference a file in a sibling project that is within the same Visual Studio solution folder, use the predefined path variable called VSSolutionFolder. For more information, see Using the VSSolutionFolder Path Variable with Visual Studio Solutions.

 

If the problem still persist, can you build with -v option and attach the log here for more information.

 

-v

Advanced UI, Basic MSI, InstallScript, InstallScript MSI, InstallScript Object, Merge Module, Suite/Advanced UI

This parameter enables you to create a verbose build log file that may be useful if Flexera Support is helping you troubleshoot an issue with your installation.

0 Kudos

Hi,

thanks for your reply.

We are passing the variables without slashes. The slash gets added somewhere during the build proces.

This the commandline used:

"c:\Program Files (x86)\InstallShield\2018\System\IsCmdBld.exe" -p "C:\install\Installer.ism" -l MC_SIGNING_CERTIFICATE_HASH="3176a76f24ee1382d9d31b3dc11409d4764d83e9" -l MC_SIGNTOOL_PATH="C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\signtool" -v

And this is the verbose output:

Launching precompression build events...
BuildEvent: unresolved event '<MC_SIGNTOOL_PATH> sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 <MC_SIGNING_CERTIFICATE_HASH> <ISReleasePath>\<ISProductConfigName>\<ISReleaseName>\DiskImages\DISK1\Setup.msi'
BuildEventThread: launching event command line: '"C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\signtool"\ sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 3176a76f24ee1382d9d31b3dc11409d4764d83e9\ c:\deploy\build\Installer\SINGLE_EXE_IMAGE\DiskImages\DISK1\Setup.msi'
BuildEventThread: event exited with status 1

 

As you can see to both variables a slash gets added. So the error from signtool is (printed on the commandline):

SignTool error : Invalid SHA1 hash format: 3176a76f24ee1382d9d31b3dc11409d4764d83e9\

 

The variables have default values (also without a slash),  and building from within InstallShield does work.

0 Kudos
roman2
Level 7

 

<MC_SIGNTOOL_PATH>   sign

There is is a blank between > and sign. Remove it.

<MC_SIGNTOOL_PATH>sign

0 Kudos

That would make things worse. 'sign' is an argument to signtool.exe, what you propose would make the command '...signtool.exe"sign' which makes no sense.
0 Kudos

Hi @stijnv ,

 

I am not able to reproduce the issue with InstallShield 2018, and even with the latest 2019 also.

Executing the below command build:

iscmdbld.exe -p "C:\Users\Test\Desktop\Triage\PathVar\TestBMSI.ism" -l MC_SIGNTOOL_PATH="C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\signtool" -l MC_SIGNING_CERTIFICATE_HASH="e75a9aa61e50291f9b4fbe964a328482a3b7e4c4" -v

 

Getting Below in the log file without last slash :


BuildEvent: unresolved event '<MC_SIGNTOOL_PATH> sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 <MC_SIGNING_CERTIFICATE_HASH> <ISReleasePath>\<ISProductConfigName>\<ISReleaseName>\DiskImages\DISK1\TestBMSI.msi'
BuildEventThread: launching event command line: 'C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\signtool sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 e75b7dd61e50295f9c5fbe964a324582e4b7e4c4 C:\Users\Test\Desktop\Triage\PathVar\TestBMSI\Product Configuration 1\Release 2\DiskImages\DISK1\TestBMSI.msi'

 

0 Kudos

Can you repeat the above but adding quotes around the path to the .ism? That might matter..

Anyway it's probably not easy to reproduce: during further testing I noticed that the slash is not always appended. We have multiple invocations to the signing and even though the command is always similar the slash is not always there.

I haven't pinpointed the exact problem, but the following is interesting. There's 3 events defined, the last 2 being the same apart from the path variable being used. The path variables have the same default values. But depending on whether the path variable is set on the commandline (with the same value as the default one), the slash appears:

"c:\Program Files (x86)\InstallShield\2018\System\IsCmdBld.exe" -p "C:\install\Installer.ism" -l MC_DESTINATION_PATH="C:\install\installer" -v

BuildEvent: unresolved event '<MC_SIGNTOOL_PATH> sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 <MC_SIGNING_CERTIFICATE_HASH> "<ISReleasePath>\<ISProductConfigName>\<ISReleaseName>\DiskImages\DISK1\Setup.exe"'
BuildEventThread: launching event command line: '"C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\signtool" sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 3176a76f24ee1382d9d31b3dc11409d4764d83e9\ "c:\install\build\SINGLE_EXE_IMAGE\DiskImages\DISK1\Setup.exe"'

BuildEvent: unresolved event '<MC_SIGNTOOL_PATH> sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 <MC_SIGNING_CERTIFICATE_HASH> "<MC_DESTINATION_PATH>\Setup.exe"'
BuildEventThread: launching event command line: '"C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\signtool" sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 3176a76f24ee1382d9d31b3dc11409d4764d83e9\ "C:\install\installer\Setup.exe"'

BuildEvent: unresolved event '<MC_SIGNTOOL_PATH> sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 <MC_SIGNING_CERTIFICATE_HASH> "<MC_DESTINATION_PATHBIS>\Setup.exe"'
BuildEventThread: launching event command line: '"C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\signtool" sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 3176a76f24ee1382d9d31b3dc11409d4764d83e9 "C:\install\installer\Setup.exe"'




"c:\Program Files (x86)\InstallShield\2018\System\IsCmdBld.exe" -p "C:\install\Installer.ism" -l MC_DESTINATION_PATHBIS="C:\install\installer" -v

BuildEvent: unresolved event '<MC_SIGNTOOL_PATH> sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 <MC_SIGNING_CERTIFICATE_HASH> "<ISReleasePath>\<ISProductConfigName>\<ISReleaseName>\DiskImages\DISK1\Setup.exe"'
BuildEventThread: launching event command line: '"C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\signtool" sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 3176a76f24ee1382d9d31b3dc11409d4764d83e9\ "c:\install\build\SINGLE_EXE_IMAGE\DiskImages\DISK1\Setup.exe"'

BuildEvent: unresolved event '<MC_SIGNTOOL_PATH> sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 <MC_SIGNING_CERTIFICATE_HASH> "<MC_DESTINATION_PATH>\Setup.exe"'
BuildEventThread: launching event command line: '"C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\signtool" sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 3176a76f24ee1382d9d31b3dc11409d4764d83e9 "C:\install\installer\Setup.exe"'

BuildEvent: unresolved event '<MC_SIGNTOOL_PATH> sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 <MC_SIGNING_CERTIFICATE_HASH> "<MC_DESTINATION_PATHBIS>\Setup.exe"'
BuildEventThread: launching event command line: '"C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\signtool" sign /tr http://rfc3161timestamp.globalsign.com/advanced /td sha256 /fd sha256 /sha1 3176a76f24ee1382d9d31b3dc11409d4764d83e9\ "C:\install\installer\Setup.exe"'

0 Kudos

So, there's more to it. We reverted to built-in signing using a .pfx file and there seem to be similar problems. In the past we always used a path like <ISProjectFolder>\Codesigning.pfx?auto for the file. Now we changed that to use a path variable instead to have it configurable. Some of these attempts make signing fail with 'fatal error -1027' which essentially means the signing cannot find the .pfx file. Results:

- using <MyPfxPath>?auto where MyPfxPath = d:\CodeSigning.pfx => error -1027

- using <MyPfxPath>\Codesigning.pfx?auto where MyPfxPath = d:\ => error -1027

- using <MyPfxPath>\Codesigning.pfx?auto where MyPfxPath = d: => the only one which works

So from my perspective: all 3 of the above cases should resolve to the exact same path but they don't, combined with results from my previous tests it really looks like there's a bug in path variable substitution and slashes get added incorrectl.

0 Kudos