Hello Jenifer,  The publisher in my project does match the Signer Information, as shown in the attached files. In my release, I have a Postbuild Event, in which language transforms are embedded within the MSI.  After embedding the MSTs, I manually sign the MSI.  I noticed that the MSIX conversion starts, it decompresses the package into a directory as "C:\TMP\AS\<#>\, and under subdirecory "a" I see the uncompressed MSI.  If I right click the MSI to see its properties, it does NOT have a digital signature.    1.  Could the Postbuild Event be causing the error during signing? 2.  During the MSIX conversion, is it expected for the uncompressed MSI to NOT have a digital signature? I appreciate your help.   Octavio M ... View more

I forgot to mention that I am using InstallShield 2020 R1. Octavio M ... View more

Hello Jenifer, I am having the same problem.   I have a Basic MSI type of project, and when I build, my MSI gets signed correctly, but error 0x800b0003 occurs when attempting to sign the MSIX file. I am using the signtool.exe from the Windows SDK 10.0.18362.0 (C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x86\signtool.exe). If I attempt to use the signtool and manually sign the MSIX using the command <pathToSigntool> sign /fd SHA256 /a /f  <pathToPFX> /p <password> <pathToMSIX>  I get the error:  SignTool Error: This file format cannot be signed because it is not recognized. Please advise. Octavio M   ... View more

Thanks to Flexera (InstallShield) support team, the problem is solved. During the build process, what ever gets defined in the Releases\Product Configuration gets populated into the Upgrades table (as long as you select "Products sharing my Upgrade Code" option). There is no need to define a separate Upgrade item for the new product. Once the MSI is build, he different products have only their respective Upgrade Code in the Upgrade Table. Thank you for helping resolve this mystery. ... View more

In the Upgrades view, for Product A I select "Products sharing my Upgrade Code". This causes the Upgrade Code to be displayed as {00000000-0000-0000-0000-000000000000}. At build time, this gets populated with the Upgrade Code that is defined in the General Information. For Product B, I select "Products having another Upgrade Code", and I enter the valid Upgrade Code instead of the {00000000-0000-0000-0000-000000000000}. The Upgrade Codes for the 2 individual products is fine. The problem is the fact that there are 2 Upgrade items, and both of them are checked with either product. ... View more

What I am trying to accomplish is to have 1 installer (Basic MSI Project) that has 2 different releases: Product A and Product B. Both products need to be upgradable, so I have 2 Major Upgrade entries, one for A and one for B. At install time, Produt A should not care if Product B is installed. A should upgrade A, and B should upgrade B. I do NOT want B to upgrade A, nor A to upgrade B. To answer your questions; Yes, A and B share features. A is a superset of B. They each install to their own directory. I set the destination depending on Release flags. I believe the problem I am getting is that when the FindRelatedProducts action executes, both A & B Upgrade Codes get checked because I have the 2 Major Upgrade entries. There is no way to associate Product A to the Major Upgrade entry for A, and Product B to Major Upgrade entry for B. The only way I see to resolve this issue is to modify the MSIs (post-process), and delete the Major Upgrade entry that is not associated with the product. I really do not want to do this because modifying the database is always risky! I hope this explains a little bit more what my goal is, and what is the problem I encounter. Again, any feedback is appreciated. Octavio ... View more

Yes, I have made sure that both Upgrade Code and Product Code are unique for each product. I've got 2 entries in the Upgrade table: One for A and one for B. When B is already installed, running the A installer detects B as a candidate for an upgrade. UpgradeCode for A is {B7F69531-...} and its ProductCode is {0691458F-...} UpgradeCode for B is {A350DD7B-...} and its ProductCode is {0B2AA47D-...} Please take a look at the section of the log: .InstallShield 12:03:46: Getting records from Upgrade table InstallShield 12:03:46: UpgradeCode: {B7F69531-1D50-4EFF-B281-AC7C0D08F9C3} MinVersion: 12.5.0 MaxVersion: Language: Attributes: 256 InstallShield 12:03:46: No related products for UpgradeCode {B7F69531-1D50-4EFF-B281-AC7C0D08F9C3} found InstallShield 12:03:46: UpgradeCode: {A350DD7B-FE1A-422D-904C-A80AA79E1722} MinVersion: 12.0.0 MaxVersion: Language: Attributes: 0 InstallShield 12:03:46: Checking related product {0B2AA47D-60D9-4283-962A-36903DCA9599} MSI (s) (BC!0C) [12:03:46:511]: PROPERTY CHANGE: Adding IS_MAJOR_UPGRADE property. Its value is 'Yes'. InstallShield 12:03:46: Bluebeam Vu x64 2016 {0B2AA47D-60D9-4283-962A-36903DCA9599} 0 16.0.3 ***Related*** InstallShield 12:03:46: ALLUSERS of related product {0B2AA47D-60D9-4283-962A-36903DCA9599} is = 1 . . . MSI (s) (BC:74) [12:03:48:960]: Note: 1: 2727 2: MSI (s) (BC:74) [12:03:48:960]: Doing action: RemoveExistingProducts Action ended 12:03:48: InstallValidate. Return value 1. Action start 12:03:48: RemoveExistingProducts. MSI (s) (BC:08) [12:03:48:960]: Resetting cached policy values MSI (s) (BC:08) [12:03:48:960]: Machine policy value 'Debug' is 0 MSI (s) (BC:08) [12:03:48:960]: ******* RunEngine: ******* Product: {0B2AA47D-60D9-4283-962A-36903DCA9599} ******* Action: ******* CommandLine: ********** MSI (s) (BC:08) [12:03:48:960]: SRSetRestorePoint skipped for this transaction. I really do not know why A determines that product B needs to be upgraded. Any help is greatly appreciated! Octavio M ... View more