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.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Are you talking about the AppDeploy Repackager?
Answered 12/15/2008 by: VBScab
Red Belt

Please log in to comment
0
No, another repackager
Answered 12/15/2008 by: ikke
Senior Purple Belt

Please log in to comment
0
...whose name is a secret, evidently. Anyway, bin it, it's junk.
Answered 12/15/2008 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 12/15/2008 by: pgiesbergen
Orange Belt

Please log in to comment
0
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 ?
Answered 12/15/2008 by: ikke
Senior Purple Belt

Please log in to comment
0
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.
Answered 12/15/2008 by: Jamie B
Orange Senior Belt

Please log in to comment
0
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.
Answered 12/15/2008 by: pgiesbergen
Orange Belt

Please log in to comment
0
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).
Answered 12/15/2008 by: Jamie B
Orange Senior Belt

Please log in to comment
0
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?
Answered 01/08/2009 by: GB1
Orange Belt

Please log in to comment
0
Is this better in PS 7.1? In a word, no.
Answered 01/08/2009 by: VBScab
Red Belt

Please log in to comment
0
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?
Answered 01/08/2009 by: GB1
Orange Belt

Please log in to comment
0
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.
Answered 01/08/2009 by: VBScab
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity