While reviewing a repackaging application we noticed that the repackager does not sort all the com r
While reviewing a repackaging application we noticed that the repackager does not sort all the com registration keys in the correct component.
When the repackager is not able to sort the registration with the correct component, it adds the key to a component with all other classes root keys that it cannot sort out. This component gets the attribute leave installed on uninstall, so these keys are'nt removed from the system.
What do you think of this method? The advantage is that since the keys aren't removed , the system cannot be broken on uninstall, the disadvantage is that orphan registry key are left on the system, since the dll's that were registered by these keys, are removed by the system.
Does this have a significant impact on the system or not. Perfomance loss.
The repackaging tool is used by several clients an aparently the vendor does not receive complaints from the system administrators that are using the application.
For your info, the repackaging application opts to use nor the selfreg table, nor the classid, typelib or progid table to contain registration , because they below you have the least trouble with registation in the "registry table"
Merge modules are added when they have a perfect math of the merge module files and files in the msi.
When the repackager is not able to sort the registration with the correct component, it adds the key to a component with all other classes root keys that it cannot sort out. This component gets the attribute leave installed on uninstall, so these keys are'nt removed from the system.
What do you think of this method? The advantage is that since the keys aren't removed , the system cannot be broken on uninstall, the disadvantage is that orphan registry key are left on the system, since the dll's that were registered by these keys, are removed by the system.
Does this have a significant impact on the system or not. Perfomance loss.
The repackaging tool is used by several clients an aparently the vendor does not receive complaints from the system administrators that are using the application.
For your info, the repackaging application opts to use nor the selfreg table, nor the classid, typelib or progid table to contain registration , because they below you have the least trouble with registation in the "registry table"
Merge modules are added when they have a perfect math of the merge module files and files in the msi.
0 Comments
[ + ] Show comments
Answers (12)
Please log in to answer
Posted by:
anonymous_9363
15 years ago
...whose name is a secret, evidently. Anyway, bin it, it's junk.
Posted by:
pgiesbergen
15 years ago
I've seen Installshield do this if I can recall correctly. You can call it a "solution"... Wise is better at it, but makes some mistakes with the interface keys. Anyone should always move the regkeys to the correct components to prevent upgrade and uninstall problems.
Posted by:
ikke
15 years ago
But if the component with the registry keys is set to "leave installed on uninstall" , Then nothing can be broken at uninstall, isn"t it ? Do the orphaned registry keys have a serious performance impact on a pc ?
Posted by:
Jamie B
15 years ago
What is it you are evaluating? MSI Studio Professional?
Leaving keys behind on uninstall (where they are not shared components) is generally against best practice. You may as well just install the legacy installs and do away with MSI!
I wouldnt like to be managing those desktops after 6-12 months of application upgrades.
Leaving keys behind on uninstall (where they are not shared components) is generally against best practice. You may as well just install the legacy installs and do away with MSI!
I wouldnt like to be managing those desktops after 6-12 months of application upgrades.
Posted by:
pgiesbergen
15 years ago
How can you be sure that everytime the orphaned keys are the same for every package? What if a vendor gets it right (unlikely) and puts all his keys in the correct component? If they happen to be part of your 'leave installed component' they are removed. Windows installer does not manage or care for all the keys in your component, only the one that is the keypath.
Posted by:
Jamie B
15 years ago
Self repair may also be limited as there would only be one key path for all of the registry keys. If that keys exists none of the other keys in the component would be repaired.
Mind you, even Wise doesn't get it right all the time, hence the creation of the component Registryxxx (where xxx denotes a random number) after a capture where it cannot automatically place into the correct component or you are modifying resources on the machine that your installer isn't actually installing (they are already present on the box for example).
Mind you, even Wise doesn't get it right all the time, hence the creation of the component Registryxxx (where xxx denotes a random number) after a capture where it cannot automatically place into the correct component or you are modifying resources on the machine that your installer isn't actually installing (they are already present on the box for example).
Posted by:
GB1
15 years ago
Which packaging tool do people find best for automatically sorting registration information to the correct component?
Using Wise Package Studio 6.1, if I import from a reg file created by WiseComCapture.exe, some of the entries seems to get correctly associated to the component (the dll or ocx) but a lot of other entries end up in a separate registry component.
The result vaires depending on if I extract advertising information from a registry file on the component in question or if I just import the reg file. Not sure why there is a difference, as the latter adds more entries.
Is this better in PS 7.1?
Using Wise Package Studio 6.1, if I import from a reg file created by WiseComCapture.exe, some of the entries seems to get correctly associated to the component (the dll or ocx) but a lot of other entries end up in a separate registry component.
The result vaires depending on if I extract advertising information from a registry file on the component in question or if I just import the reg file. Not sure why there is a difference, as the latter adds more entries.
Is this better in PS 7.1?
Posted by:
GB1
15 years ago
Hmm.
I edited my question to add some more (while sorting out my typos), but probably after you had replied:
The result vaires depending on if I extract advertising information from a registry file on the component in question or if I just import the reg file. Not sure why there is a difference, as the latter adds more entries.
What is the majority vote approach for correctly adding registration info? I guess advertised or not is a preference? Selfreg seems to be out of favour. So what are the recommnedations on importing or capturing the information to the reg table or the advertising tables and keeping it all assigned to the correct component?
I edited my question to add some more (while sorting out my typos), but probably after you had replied:
The result vaires depending on if I extract advertising information from a registry file on the component in question or if I just import the reg file. Not sure why there is a difference, as the latter adds more entries.
What is the majority vote approach for correctly adding registration info? I guess advertised or not is a preference? Selfreg seems to be out of favour. So what are the recommnedations on importing or capturing the information to the reg table or the advertising tables and keeping it all assigned to the correct component?
Posted by:
anonymous_9363
15 years ago
My vote would be to have WPS add the advertising info at the capture stage. It makes a fair job of it with that option selected. As you've discovered, importing a .REG can result in a bit of a mess.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.