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
- :
- Bug found with Mobile Devices Installer build
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
Mar 16, 2008
08:51 PM
Bug found with Mobile Devices Installer build
After over a week of building and testing a Windows Mobile release using InstallShield 2008 Premier, I have finally isolated the fault. I went to open a service ticket on this item, but cannot because that apparently requires a different signin than the forums and I have to wait for an email first :confused:
Several people, some in Houston and some in Taiwan, have been trying to diagnose this issue. For the longest time we thought the problem was that InstallShield was not signing the CAB file, although it clearly looked like it was supposed to support it. But when we ran setup.exe and InstallShield launched the Add/Remove programs applet of ActiveSync, when the cab was launched on the device we continued to get the "Unknown Publisher" warning dialog on the device-side.
If I went to the [FONT="Courier New"][SIZE="2"][is_project_dir]\Product Configuration 1\[releaseDir]\CEApps[/SIZE][/FONT] folder and copied the CAB file from this location and then manually copied it to the device and manually executed the CAB file, I would not get the "Unknown Publisher" warning dialog on the device. Too, if I examined the CAB file on the desktop it looked like the file was correctly signed.
The trick to finding the fault was navigating to the [FONT="Courier New"]\Windows\AppMgr\Install[/FONT] folder on the device. Next, run setup.exe on the desktop, and when I got the "Unknown Publisher" dialog on the device, I quickly copied the CAB file from the device before it was deleted. This CAB file is not signed.
I then looked again at the build log, which I looked at so many times before, and could see it was telling me what was wrong, but I didn't understand
[FONT="Courier New"]...
Creating INF file for Application "Fred"...
Building CAB files for Application "Fred"...
Adding CAB files for Application "Fred" to Binary table... <-- Adds first
Started signing Fred.PPC500_StrongARM-XScale.CAB ... <-- then signs (out of sequence)
Succeeded
...[/FONT]
When IS "adds cab file to binary table", it's not just adding a reference in a table, it's adding the file. THEN it signs the CAB file.
I'm putting this here in hopes we can get a resolution quickly. I still haven't received the email with the information that will let me open a support ticket.
In the next week, our teams have to produce 22 Windows Mobile installations. Currently the only work-around is to first build the CAB and sign it, then open a new project in IS to build the setup.exe (selecting "use existing CAB"). The process is already complicated enough.
I can think of no reason why InstallShield would sign the CAB file after it added it to the setup.exe build, other than it being a bug, as the log indicates.
Thanks!
Mike
keywords: signcode signtool cab troubleshooting windows mobile pocketpc pocket pc pain grief suffering
Several people, some in Houston and some in Taiwan, have been trying to diagnose this issue. For the longest time we thought the problem was that InstallShield was not signing the CAB file, although it clearly looked like it was supposed to support it. But when we ran setup.exe and InstallShield launched the Add/Remove programs applet of ActiveSync, when the cab was launched on the device we continued to get the "Unknown Publisher" warning dialog on the device-side.
If I went to the [FONT="Courier New"][SIZE="2"][is_project_dir]\Product Configuration 1\[releaseDir]\CEApps[/SIZE][/FONT] folder and copied the CAB file from this location and then manually copied it to the device and manually executed the CAB file, I would not get the "Unknown Publisher" warning dialog on the device. Too, if I examined the CAB file on the desktop it looked like the file was correctly signed.
The trick to finding the fault was navigating to the [FONT="Courier New"]\Windows\AppMgr\Install[/FONT] folder on the device. Next, run setup.exe on the desktop, and when I got the "Unknown Publisher" dialog on the device, I quickly copied the CAB file from the device before it was deleted. This CAB file is not signed.
I then looked again at the build log, which I looked at so many times before, and could see it was telling me what was wrong, but I didn't understand
[FONT="Courier New"]...
Creating INF file for Application "Fred"...
Building CAB files for Application "Fred"...
Adding CAB files for Application "Fred" to Binary table... <-- Adds first
Started signing Fred.PPC500_StrongARM-XScale.CAB ... <-- then signs (out of sequence)
Succeeded
...[/FONT]
When IS "adds cab file to binary table", it's not just adding a reference in a table, it's adding the file. THEN it signs the CAB file.
I'm putting this here in hopes we can get a resolution quickly. I still haven't received the email with the information that will let me open a support ticket.
In the next week, our teams have to produce 22 Windows Mobile installations. Currently the only work-around is to first build the CAB and sign it, then open a new project in IS to build the setup.exe (selecting "use existing CAB"). The process is already complicated enough.
I can think of no reason why InstallShield would sign the CAB file after it added it to the setup.exe build, other than it being a bug, as the log indicates.
Thanks!
Mike
keywords: signcode signtool cab troubleshooting windows mobile pocketpc pocket pc pain grief suffering
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Apr 03, 2008
11:33 AM
Since nobody replied here, I'm posting my findings for others.
After going through our paid corporate maintenance agreement channel I was able to get a response from the company, which as of April 1, 2008 is no longer Macrovision. I was told that they were aware of the bug and was sent a DLL via email that solved the issue. Ironically, an installer wasn't included with the patch file :rolleyes:
So if anyone else runs into this issue, at least you'll know the fault is not your own. I spent a LOT of time on this issue that they already know about and even have a fix for. I wonder why they have not posted in an update? Not sure what's going on with that.
After going through our paid corporate maintenance agreement channel I was able to get a response from the company, which as of April 1, 2008 is no longer Macrovision. I was told that they were aware of the bug and was sent a DLL via email that solved the issue. Ironically, an installer wasn't included with the patch file :rolleyes:
So if anyone else runs into this issue, at least you'll know the fault is not your own. I spent a LOT of time on this issue that they already know about and even have a fix for. I wonder why they have not posted in an update? Not sure what's going on with that.
![](/skins/images/7DF1852B2C95702E61A73F170B191DAC/responsive_peak/images/icon_anonymous_message.png)