HKEY_CURRENT_USER vs HKCU

[maw...@rcn.com]

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've been told that moving the keys to HKU sidesteps this behavior or
appears to.

I know I'm 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'm clear on this as I really need some help guidance with
writing to HKU. I've 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!

[maw...@rcn.com]

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.

[Wilson, Phil]

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 don't 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's 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 don't 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

<maw...@rcn.com> wrote in message
news:e3c303f2-dc85-462d...@p19g2000vbq.googlegroups.com...

[maw...@rcn.com]

On Nov 18, 3:22 pm, "Wilson, Phil" <ph...@wonderware.nospam.com>
wrote:

> 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 don't 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's 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 don't 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 Installerhttp://www.apress.com/book/view/1590592972
>

> <mawa...@rcn.com> wrote in message

>
> news:e3c303f2-dc85-462d...@p19g2000vbq.googlegroups.com...
>
>
>
> > 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've been told that moving the keys to HKU sidesteps this behavior or
> > appears to.
>
> > I know I'm 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'm clear on this as I really need some help guidance with
> > writing to HKU.  I've 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!- Hide quoted text -
>
> - Show quoted text -

Yep, Phil, you guessed it - it worked so I guess it solved the problem
was their approach. They couldn't 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 don't
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!

[Wilson, Phil]

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 isn't 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's possible to persuade the
customer that this is the way to get the registry populated for all users,
even a user that doesn't even exist yet. I don't know of any way to suppress
the repair progress dialog in your situation.

Writing a book is very tedious. By the time you've seen the same text 20
million times in all the edits you're ready to go nuts. I'd do the update if
I had more time, because it's very time consuming too.
--
Phil Wilson

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

<maw...@rcn.com> wrote in message
news:6d813cb6-2cdb-43f2...@v37g2000vbb.googlegroups.com...