This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: 1639 from Blank Command Line Property
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 19, 2013
05:41 PM
1639 from Blank Command Line Property
[InstallShield 2012 Spring - InstallScript MSI - built and installing 32-bit app on Windows 7 64-bit]
At the start of the feature install, I'm having a fatal 1639 error, which is a command line argument problem. I've tracked it down in the logs and it's obvious what's going wrong, but not why.
[CODE]
00020: (Unknown): ******* CommandLine: [some properties...] ADDLOCAL=Feature1,Feature2,Feature3 ="" ALLUSERS=1 [more properties...]
[/CODE]
So InstallShield seems to be generating this no-name, no-value property that it's feeding to the Windows Installer through the command line. The Windows Installer properties are delivered in alphabetical order, and I've found this list of properties in MSDN docs:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa367538(v=vs.85).aspx
The following properties occur alphabetically between ADDLOCAL and ALLUSERS, so it seems like it should be one of these. On the other hand, none of them really make sense to be the problem.
Unfortunately these installer properties aren't simply listed in InstallShield, other than where noted. I have no fear of modifying tables with the Direct Editor in IS, but I simply have no idea what IS table values are used to create most of these corresponding Windows Installer properties. I've done my best to browse through the tables looking for blank entries, but I haven't been able to find anything that looks out of place. It might even be the case that some well formed property indicates to IS that there should be some other property-value pair which does not in fact exist (such as ALLUSERS to AdminToolsFolder).
I've tried my best on this but the trail's gone cold. Any ideas?
Ps. I also found this related post from years ago, which has the same symptoms:
http://community.flexerasoftware.com/showthread.php?187535-Error-quot-the-wizard-was-interrupted-before-could-be-completely-installed-quot&highlight=1639
At the start of the feature install, I'm having a fatal 1639 error, which is a command line argument problem. I've tracked it down in the logs and it's obvious what's going wrong, but not why.
[CODE]
00020: (Unknown): ******* CommandLine: [some properties...] ADDLOCAL=Feature1,Feature2,Feature3 ="" ALLUSERS=1 [more properties...]
[/CODE]
So InstallShield seems to be generating this no-name, no-value property that it's feeding to the Windows Installer through the command line. The Windows Installer properties are delivered in alphabetical order, and I've found this list of properties in MSDN docs:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa367538(v=vs.85).aspx
The following properties occur alphabetically between ADDLOCAL and ALLUSERS, so it seems like it should be one of these. On the other hand, none of them really make sense to be the problem.
- ADDSOURCE - Can be in Property table, but it isn't there in my project and docs say not to put it there.
- AdminProperties - Belongs in Property Table, but I don't use it so it's not present.
- AdminToolsFolder - Docs say "If the ALLUSERS Property is set (which it is), this property points to the file system directory that contains the administrative tools for all users of the computer." I don't have this property set, but I have another project with the same situation (ALLUSERS is set, but not AdminToolsFolder) and there's no problem.
- AdminUser - The article talks mainly about Vista (not relevant), but basically this is set at run time so it shouldn't be something I'm breaking.
- Advertise -Like ADDSOURCE, can be in the Property table, but it shouldn't be, and it isn't.
- AFTERREBOOT - Added by the installer after a reboot takes place, which isn't happening.
Unfortunately these installer properties aren't simply listed in InstallShield, other than where noted. I have no fear of modifying tables with the Direct Editor in IS, but I simply have no idea what IS table values are used to create most of these corresponding Windows Installer properties. I've done my best to browse through the tables looking for blank entries, but I haven't been able to find anything that looks out of place. It might even be the case that some well formed property indicates to IS that there should be some other property-value pair which does not in fact exist (such as ALLUSERS to AdminToolsFolder).
I've tried my best on this but the trail's gone cold. Any ideas?
Ps. I also found this related post from years ago, which has the same symptoms:
http://community.flexerasoftware.com/showthread.php?187535-Error-quot-the-wizard-was-interrupted-before-could-be-completely-installed-quot&highlight=1639
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 27, 2013
12:36 PM
I do not know the answer to your issue, but the MSI link that you referenced is explaining the sequence in which those particular properties are evaluated by the msi engine that processes the in-script actions. That document in my understanding does not imply that those properties need to be on the command line in any particular order. I suspect that your issue is not related to those particular properties.
I would look at the Releases view and the Setup.exe tab and check that the 'MSI Command-line Arguments field is correct (or rather does not have extra stuff). I think I would also attempt to produce a similar test project and see if the problem is reproducible. If not, as I suspect, I would then compare the broken project file to the working project file, in an XML editor (or in Direct Editor), to see if I could find the difference. In the General Information view you can set the Project File Format to XML, which I find is useful for finding strange InstallShield issues. I rather doubt that this issue will show up in the Direct Editor.
Alternatively if the above field is not set in your project, you might want to set something and see how the InstallScript setup.exe passes that information to the MSI. It might be that setting that field in your project will cause the IDE to re-write that portion of the project file and correct the problem, but I am just guessing.
I would look at the Releases view and the Setup.exe tab and check that the 'MSI Command-line Arguments field is correct (or rather does not have extra stuff). I think I would also attempt to produce a similar test project and see if the problem is reproducible. If not, as I suspect, I would then compare the broken project file to the working project file, in an XML editor (or in Direct Editor), to see if I could find the difference. In the General Information view you can set the Project File Format to XML, which I find is useful for finding strange InstallShield issues. I rather doubt that this issue will show up in the Direct Editor.
Alternatively if the above field is not set in your project, you might want to set something and see how the InstallScript setup.exe passes that information to the MSI. It might be that setting that field in your project will cause the IDE to re-write that portion of the project file and correct the problem, but I am just guessing.
