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
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)
Please log in to answer
Posted by:
MSIPackager
18 years ago
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.
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
Posted by:
MSIram
18 years ago
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.
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
Posted by:
chaosnl
18 years ago
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
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
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.