/build/static/layout/Breadcrumb_cap_w.png

Capturing HKCU information created when launching an application

Do most people launch an application during the capture process and include any HKCU information generated at runtime? Or do you only capture keys installed as part of the setup itself?

Is there any benefit in doing the former if the particular application already has internal logic to create HKCU and user profile data in the event it is missing?

The way I see it this would just complicate things, becoming particularly tedious and cumbersome when working with large applications and having to manually associate 100s of file components to HKCU primary keys to correct ICE38s. Not to mention that the application itself would probably create this information faster than a self-repair.

Thoughts?

This question has been driving me nuts.

Cheers

0 Comments   [ + ] Show comments

Answers (6)

Posted by: MSIPackager 18 years ago
3rd Degree Black Belt
0
Hi John,

Personally I always run up the application as part of the capture to include files / reg keys etc created on 1st run.

Depending on how well the application is written the keys may not always be in HKCU - your desktop could be locked down to the point where the user doesn't have appropriate rights. Same goes for files / inifiles created or updated during 1st run. The other main benefit of course being a cleaner uninstall...

Re the ICE38 thing - unless there is a specific reason to have 1 component per reg key then I'd generally use a single 'current user' component to setup the HKCU stuff.

Whichever you decide the golden rule as always is test, test and test again so you don't get caught out [;)]

Cheers,
Rob.
Posted by: John McDermott 18 years ago
Senior Yellow Belt
0
Cheers Rob.

To be more specific, I guess I'm more thinking of situations where there are a large number of files in a large number of different subfolders under the user's application data folder for example.
Posted by: MSIram 18 years ago
Senior Yellow Belt
0
I personally don't capture the HKCU keys which are created on the first launch unless it is specific to configuration.
Why do you keep reg keys which will be created on launching the application?
Always keep the reg keys and files which are installed into the place where user doesn’t have access to, so that he won’t run into access problem on launching the application. User profile keys and file which are created by the application on first launch can be ignored except in few specific scenarios.
If the keys are related to configuration and suppressing the initial dialog boxes like tips, registrations, ect. Include it in you MSI.

MSIRam.
Posted by: YRKUMAR 18 years ago
Senior Yellow Belt
0
Can any one of you please give me some important steps to package an app for Citrix environment? I am using WISE for Windows Installer to create MSIs. I need some information especially how to take care of Registry within MSI..(HKCU etc...)

Thanks for your help.
Posted by: chaosnl 18 years ago
Senior Yellow Belt
0
Packaging for Citrix is not that easy and it differs from application or organisation.
There are some things that i normally do before packaging for Citrix.

First the ROOTDRIVE, Citrix uses for example M: (for Windows) and N: (fo program Files)
so you can change the rootdive in your MSI or you make a package on a machine where you change C: to M: and D: to N:.
Then i always use ALLUSERS=2.
Never put any Current User settings in Your MSI, export them to an regfile and import them with Citrix Powerfuse.
Be Aware of Shortcuts you have to change them also.
I think i forge a lot of things and i know there very different ways of packaging for Citrix.

Good Luck

ChaosNL
Posted by: YRKUMAR 18 years ago
Senior Yellow Belt
0
Chaosnl,

Thanks for your response..Very informative..Can you please eloborate a little bit HKCU information? Export and import stuff...also how to use Citrix Powerfuse...Thanks for your time...
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ