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

Building same patch on a different machine

Jump to solution

Hello,

I am running into an issue building a patch.  We had built several versions of the setup up until the release candidate on the same machine, a virtual machine.  We then started producing patches on the same machine used to create the RTM installer.

Recently we have cloned this VM to move it to a new host.  Now when building the patch on the new cloned VM on the new host the patch is getting an issue.  The issue being that the patch from the new VM is adding an entry to the Class table and the patch is uninstallable. 

The leading cause candidate is this warning:
'ISDEV : warning Val0015: The Class table contains new content. Therefore, if you are packaging this upgrade as a patch, you will not be able to make it an uninstallable patch.'

For testing purposes we have followed the same process on the previous VM and the new VM and from the old VM the patch is uninstallable.  The patch from the new machine has the Class table change and is uninstallable.

 Have gone through and looks like everything between the previous VM and the new VM are the same.  Could be missing something however.

Has anyone run into issues where changing to a different machine to produce a patch causes issues?

Bit of a Installshield Novice - thanks for any tips.
Thanks,
Chris

Labels (1)
0 Kudos
(1) Solution

Hi @chrisfox2385 ,

It may be due to the difference in the COM extraction settings.

Firstly, I am suggesting you to upgrade InstallShield to the latest version (InstallShield 2020). We made some improvement in COM extraction in the latest versions.  

InstallShield provides three different methods to extract the COM information, but at a time InstallShield extract the information based on the method configured in the registry. UseAPIRegistryHooks registry value located in HKEY_LOCAL_MACHINE\Software\InstallShield\RegSpy key (on 32-bit machines) or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\InstallShield\RegSpy  key(on 64-bit machines) holds the method configured to extract the COM information.

Value

Description

0

COM information captured by hooking Windows Registry API, old method.

1

COM information captured through Registry redirection API

2

COM information captured through Kernel mode registry filtering; latest method introduced in InstallShield 2012.

 

Value "2" is the latest method, which is more efficient than all others. But, in some cases value can be changed to the suitable method if the default one(value "2") is not working.

InstallShield provides a utility tool named RegSpyUI to cross check the values extracted from COM component, extracted by the method specified in the registry. RegSpyUI tool is available in the InstallShield support folder(C:\Program Files (x86)\InstallShield\2019\Support), this tool can be used to verify the COM extraction done by InstallShield.

See, RegSpyUI  able to extract the COM information with the registry value 2 and then see with value "1". 

RegSpyUI is a COM extraction utility available in InstallShield, located under the <InstallShield Programs File Folder>\Support folder.

More information on RegSpyUI can be found at the below link:

https://community.flexera.com/t5/InstallShield-Knowledge-Base/Extracting-COM-Information-with-RegSpy...

View solution in original post

(4) Replies
chrisfox2385
Level 3

Hello,

After some more investigation found some more interesting details.

If we use the RegSpyUI.exe for one dll that is causing the Class table to be updated as part of a patch.  On the virtual machine the patch does not cause changes to the Class table the COM data is extracted one way.  On a cloned copy of the virtual machine and even other machines, we run the RegSpyUI.exe on the same dll.  The COM data is extracted in a significantly different manner.  Looks like COM Extract/RegSpyUI.exe is getting different results on the same file and the same version only on different machines.

Has anyone come across this before?


Thanks,
Chris

0 Kudos

Hi @chrisfox2385 ,

It may be due to the difference in the COM extraction settings.

Firstly, I am suggesting you to upgrade InstallShield to the latest version (InstallShield 2020). We made some improvement in COM extraction in the latest versions.  

InstallShield provides three different methods to extract the COM information, but at a time InstallShield extract the information based on the method configured in the registry. UseAPIRegistryHooks registry value located in HKEY_LOCAL_MACHINE\Software\InstallShield\RegSpy key (on 32-bit machines) or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\InstallShield\RegSpy  key(on 64-bit machines) holds the method configured to extract the COM information.

Value

Description

0

COM information captured by hooking Windows Registry API, old method.

1

COM information captured through Registry redirection API

2

COM information captured through Kernel mode registry filtering; latest method introduced in InstallShield 2012.

 

Value "2" is the latest method, which is more efficient than all others. But, in some cases value can be changed to the suitable method if the default one(value "2") is not working.

InstallShield provides a utility tool named RegSpyUI to cross check the values extracted from COM component, extracted by the method specified in the registry. RegSpyUI tool is available in the InstallShield support folder(C:\Program Files (x86)\InstallShield\2019\Support), this tool can be used to verify the COM extraction done by InstallShield.

See, RegSpyUI  able to extract the COM information with the registry value 2 and then see with value "1". 

RegSpyUI is a COM extraction utility available in InstallShield, located under the <InstallShield Programs File Folder>\Support folder.

More information on RegSpyUI can be found at the below link:

https://community.flexera.com/t5/InstallShield-Knowledge-Base/Extracting-COM-Information-with-RegSpy...

Hello banna_k,

Thanks for your response! 

This is for a version of the software that has been released to customers we are providing smaller-ish patches.  In our current release version we have updated to the InstallShield 2020 version.

I looked in the registry at the key you mentioned.  And sure enough there were differences between the two machines.  Working machine was using the 2 value and difference machine was using the 1 option.  Changed so that both are using 2 and RegSpyUI returned the same values now!

Early indications are that this is the change I have been looking for!  I am running a test setup build after making the registry change to be sure.  If successful will comeback and mark your response as the Accepted Solution.  (Don't want to jinx it by accepting it too soon LOL!)

Thanks,
Chris

0 Kudos

Greetings!

After checking/updating the UseAPIRegistryHooks  to use the 2 value we are no longer seeing the issue!

In a bit of curious note, after cleaing registy andinstalling InstallShieild2016SP2StandaloneBuild.exe on a Windows 10 machine the value of UseAPIRegistryHooks was set to 1 not 2.

Either way we found our problem and are able to move forward.

Thanks very much for the suggestion!
-Chris

0 Kudos