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
- :
- Re: ISSelfReg order while uninstall
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
‎Apr 25, 2008
07:33 AM
ISSelfReg order while uninstall
When installing the package, the files are registered in the correct order as specified in the order-column of the ISSelfReg-table.
But when uninstalling the package, the order isn't reversed.
see Log:
A InstallShield bug?
But when uninstalling the package, the order isn't reversed.
see Log:
Action 14:02:44: ISUnSelfRegisterFiles.
InstallShield 14:02:44: Initializing Property Bag...
InstallShield 14:02:44: Getting file count from property bag
InstallShield 14:02:44: File Count : 15
InstallShield 14:02:44: Sorting Based On Order...
A InstallShield bug?
(8) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 25, 2008
07:13 PM
Probably could be considered a bug, but I would seriously consider dumping SelfReg in the first place. MSI best practice is to use the COM/Registry tables instead. It took me about 1 year of MSI to believe this but in the end it's a more reliable install.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 28, 2008
02:01 AM
I know that "Com Extract at build" is considered as best practice. But this is not an option for me because my ActiveX-DLLs change a lot and I want get rid of the VAL0009 warnings...
So anyone have an idea to reverse the order while uninstalling?
Or can Macrovision confirm this as a bug?
So anyone have an idea to reverse the order while uninstalling?
Or can Macrovision confirm this as a bug?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 28, 2008
09:27 AM
I'm not sure that I'd trade in an ICE warning for an antipattern. Still, let's say it's not confirmed/fixed as a bug, it wouldn't take much work to replace the standard custom action. All you would need to do is query the table, reverse the sort order, evaluate the Component action state of each record and then populate the CustomActionData property. Then in an uninstall deferred CA look through the CAD property and call the DllUnRegisterServer() function.
I only say this in case IS is unresponsive and you need to get this resolved asap within your design constraints. While I don't actually reccomend this ( see com extraction ) it should only take a couple of hours to implement and test.
I only say this in case IS is unresponsive and you need to get this resolved asap within your design constraints. While I don't actually reccomend this ( see com extraction ) it should only take a couple of hours to implement and test.
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 28, 2008
11:25 AM
I looked through the database quickly, but I wasn't able to find anything.
Unfortunately, it looks like the uninstallation does not reverse-order the unregistration of your DLLs. I don't know if this is classified as a bug or a limitation yet.
However, Self-Registration should be reserved for situations where you have literally no other option (for example, the DLL requires system specific information to register correctly). As far as excessive COM registration changes, I'm not sure the best way to approach that. I might suggest major upgrades between versions.
The main issue with self-registration is that if the unregistration process failed, you would have COM Data orphaned anyway. So either way you go you're kinda in the same boat.
Unfortunately, it looks like the uninstallation does not reverse-order the unregistration of your DLLs. I don't know if this is classified as a bug or a limitation yet.
However, Self-Registration should be reserved for situations where you have literally no other option (for example, the DLL requires system specific information to register correctly). As far as excessive COM registration changes, I'm not sure the best way to approach that. I might suggest major upgrades between versions.
The main issue with self-registration is that if the unregistration process failed, you would have COM Data orphaned anyway. So either way you go you're kinda in the same boat.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 29, 2008
02:04 AM
Tx Bryan for the quick answer.
Do you have the possibility to look in detail in the Macrovision KB if this is tracked as a bug and perhaps if a hotfix for IS2008 exists? Or could you ask your colleagues if they accept this behavior to be a bug?
Do you have the possibility to look in detail in the Macrovision KB if this is tracked as a bug and perhaps if a hotfix for IS2008 exists? Or could you ask your colleagues if they accept this behavior to be a bug?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 29, 2008
06:38 AM
Without getting into internal symantecs of defect classificiations, I'd call it a bug since normal setup design expectations dictate reverse order uninstall/upgrade processing.
BTW, if the majority of your DLL's are not order dependent and a couple of them are... you could turn SelfReg off for the ones that are and use a custom action instead.
BTW, if the majority of your DLL's are not order dependent and a couple of them are... you could turn SelfReg off for the ones that are and use a custom action instead.
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 29, 2008
08:19 AM
Do you have the possibility to look in detail in the Macrovision KB if this is tracked as a bug and perhaps if a hotfix for IS2008 exists? Or could you ask your colleagues if they accept this behavior to be a bug?
I spoke with one of the developers and he was sure no one has really brought this up to the development team before.
I created the Bug Work Order IOC-000070835 for now based on your feedback; however, I'm not sure if this will remain a bug or be changed to a feature request.
For now, we do not have a hotfix or any kind of time table I could provide.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 29, 2008
08:34 AM
Tx for your efforts Bryan.
If this behavior would be corrected, does Acresso deliver hotfixes or service packs? How could I be notified?
If this behavior would be corrected, does Acresso deliver hotfixes or service packs? How could I be notified?