Installshield corrupt registry entries
-
slocko
- How helpful is this to you?
- Average Rating 0
- 4904 views
- 07/27/2005
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
[ - ] Hide Comments
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
Answer this question
or Comment on this question for clarity
Answers
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.
Please log in to comment
i can't believe that all you experts never seen this before :)
my guess is that this installshield setup.exe has problems with xp.
i guess i'm going to have identify all the corrupt controls, remove the clsid info, and register them with a command file.
my guess is that this installshield setup.exe has problems with xp.
i guess i'm going to have identify all the corrupt controls, remove the clsid info, and register them with a command file.
Please log in to comment
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
Please log in to comment
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.
Please log in to comment
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.
Please log in to comment
Comments
Please log in to comment