HKEY_CURRENT_USER vs HKCU

Hi all,

I was laid off from my workplace, but since called back and I am once
again working on their installs.  In my absence, user configuration
registry keys were moved from HKCU to HCU.  This was done because a
large company evaluating our software for purchase did not like
Windows Installer self repair behavior when our app was initiated.
I have been told that moving the keys to HKU sidesteps this behavior or
appears to.

I know I am going to have to change some .exe's fired as custom actions
to look to this new location, but how does Windows Installer handle
this....

If I have a system search for a registry key under HKCU, which is then
used as a launch condition, will it now look to HKU if not found in
HKCU (which it will now not be).

I hope I am clear on this as I really need some help guidance with
writing to HKU.  I have never done so before as there was never any
need.

Unfortunately, a release made it to the field with this change right
before I got back here and its starting to rear its ugly head.

Any information is GREATLY APPRECIATED!

In addtion to any HKU help, is there a way to silence the WindowsInstaller

In addtion to any HKU help, is there a way to silence the Windows
Installer self repair dialogs.  This may be another solution instead
of trying to hack through with placing stuff in HKU.

If the app self repairs when first launched then there is something wrongwith

If the app self repairs when first launched then there is something wrong
with it. For example, maybe a custom action removes an installed file (or
registry key), tand hen the shortcut causes a repair to restore the file. So
to prevent the repair:

Best: The component containing the file (or registry key) can have a null
component Id. Ref Component table docs.
Worst?: Use non-advertised shortcuts that do not cause repair. Ref:
DISABLEADVTSHORTCUTS property.

The idea that moving registry keys from one hive to another makes repair go
away is incomprehensible to me. Maybe there is more to it than that? How can
this solve the problem?  Do they have a technical explanation or just "well
it went away so we figured that was the solution" comment? There are proper
supported ways to prevent some repairs, and one of those is the right way to
go.

The other thing I do not understand is that hkey_users is a repository for
every user on the system and for default settings. If they wrote the HKU
then I assume they actually wrote to HKU\.DEFAULT or something strange.

--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972

wrote:Sogoanwellerto1590592972Yep, Phil, you guessed it - it worked so I guess

So
go
an
well
er
to
1590592972

Yep, Phil, you guessed it - it worked so I guess it solved the problem
was their approach.  They could not see the forest through the trees or
whatever the saying is.

The reason their is self repair is that we require Admin to install
but Power User (on XP now) can run the app.  When the non-installing
user initiates the app, there are user keys that get written for that
user.

I was thinking if they went the HKU route, they probably should have
just went HKLM, but I worry about permissions all the time so I do not
know if that would have been a good solution either.

We're currently in the process of reverting our install back to pre-
HKU changes, but I think this issue (getting around the self repair)
is going to raise its head again at some point if this top shelf
customer wants to purchase.  Aside from possibly silencing the self
repair - not sidestep, just make the dialogs not display (if possible
at all) - I would guess that writing to HKLM instead would be a better
approach. ???

Any further thoughts, pointers, etc on this is greatly appreciated.

Hey Phil, have you written any other Windows Installer books lately.
I have The Definitive Guide to Windows Installer (2004) but was
wondering if there was something more recent to maybe cover the new
stuff in the engine.

Thanks again!

Writing to HKLM is generally a better choice.

Writing to HKLM is generally a better choice. For a multi-user app, these
would be the default set of registry items. The app can then copy these to
HKCU and update them as required when the user first runs the app. HKLM is
readable for limited users. There is not really a practical way to populate
the HKCU items for all potential users of the system. Ironically, the MSI
way to do this is with HKCU key path registry items and have the MSI repair
do them when the user first runs the app, hence the repair dialog.  It
should happen only once anyway, so maybe it is possible to persuade the
customer that this is the way to get the registry populated for all users,
even a user that does not even exist yet. I do not know of any way to suppress
the repair progress dialog in your situation.

Writing a book is very tedious. By the time you have seen the same text 20
million times in all the edits you are ready to go nuts. I'd do the update if
I had more time, because it is very time consuming too.
--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972



Yep, Phil, you guessed it - it worked so I guess it solved the problem
was their approach.  They could not see the forest through the trees or
whatever the saying is.

The reason their is self repair is that we require Admin to install
but Power User (on XP now) can run the app.  When the non-installing
user initiates the app, there are user keys that get written for that
user.