Installshield corrupt registry entries
I'm working on repackaging an installshield application called Reconnect by UAR.
I am having a hard time making it work with the installshield engine so I decided to see how easy it would be capture.
After capturing I noticed that a lot of registry entries were corrupt in the .wsi. I decided to check the machine where I did the native installation and they were also corrupt. The only thing in common is that they seem to be the controls found in merge modules. Here is an example:
default=[!comdlg32.ocx]
Improceserver=[~]jS%qqk4+~=jj%kyRg&,dCrystalReports_DLLs>-S}(z(Bof(0l9efGjyo1[~]
If I unregister and re-register comdlg32.ocx, the corruption is cleared up.
Anyone seen this before?
I am having a hard time making it work with the installshield engine so I decided to see how easy it would be capture.
After capturing I noticed that a lot of registry entries were corrupt in the .wsi. I decided to check the machine where I did the native installation and they were also corrupt. The only thing in common is that they seem to be the controls found in merge modules. Here is an example:
default=[!comdlg32.ocx]
Improceserver=[~]jS%qqk4+~=jj%kyRg&,dCrystalReports_DLLs>-S}(z(Bof(0l9efGjyo1[~]
If I unregister and re-register comdlg32.ocx, the corruption is cleared up.
Anyone seen this before?
0 Comments
[ + ] Show comments
Answers (8)
Please log in to answer
Posted by:
DavidLock
19 years ago
Looks like you have captured something that was already in MSI format.
The [!filename] is the formatted data type which will be expanded to the short path to the file at install time by MSI.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/formatted.asp
The second part looks like a darwin descriptor...might be wrong.
But anyway do it properly, create a transform do not repackage this installer.
The [!filename] is the formatted data type which will be expanded to the short path to the file at install time by MSI.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/formatted.asp
The second part looks like a darwin descriptor...might be wrong.
But anyway do it properly, create a transform do not repackage this installer.
Posted by:
slocko
19 years ago
Posted by:
slocko
19 years ago
Posted by:
DavidLock
19 years ago
Posted by:
WiseUser
19 years ago
That's not corruption - it's perfectly normal.
You've captured an advertised CLSID entry point ("Darwin Descriptor") for "Comdlg32.ocx".
You can delete the "InProcServer" entry because it's invalid. The default entry ("[!comdlg32.ocx]") will resolve to the full short path of the "Comdlg32.ocx".
This is one of the reasons that you should not try to recapture MSI installs.
Check this web page for more detailed information:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/wi_integration.asp
You've captured an advertised CLSID entry point ("Darwin Descriptor") for "Comdlg32.ocx".
You can delete the "InProcServer" entry because it's invalid. The default entry ("[!comdlg32.ocx]") will resolve to the full short path of the "Comdlg32.ocx".
This is one of the reasons that you should not try to recapture MSI installs.
Check this web page for more detailed information:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/wi_integration.asp
Posted by:
slocko
19 years ago
Posted by:
WiseUser
19 years ago
It's not "Installshield Engine Crap". It is generated by Windows Installer when a Class ID is advertised through the "Class" table.
You have recaptured a "darwin descriptor" which provides an entry point to a different MSI to yours (which will most likely not be installed on the machines where your package will be installed). It is therefore invalid.
Your package will generate it's own entry points assuming you use the "advertising" tables (rather than the self-reg or registry tables).
I've edited my previous post to provide some more information for you to read.
You have recaptured a "darwin descriptor" which provides an entry point to a different MSI to yours (which will most likely not be installed on the machines where your package will be installed). It is therefore invalid.
Your package will generate it's own entry points assuming you use the "advertising" tables (rather than the self-reg or registry tables).
I've edited my previous post to provide some more information for you to read.
Posted by:
slocko
19 years ago
I don't mean the entries. I'm trying to strip out the installshield integration with the native msi. I really don't like using the installshield engine unless I really have to. I alway try to decouple it from the msi. Cleaner that way in my opinion.
Originally I was worried that the original installshield msi was corrupt because of those entries I captured that were also present on the machine where I ran setup. But your explanation about advertised entries made sense, so I'm back to making it work using the native msi.
Originally I was worried that the original installshield msi was corrupt because of those entries I captured that were also present on the machine where I ran setup. But your explanation about advertised entries made sense, so I'm back to making it work using the native msi.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.