How do I mix perUser and perMachine installs properly

[StephenBullen]

Hi All,

I'm trying to create a Wix 4 installer to properly install a C# COM Addin for MS Office. That needs to:

• Contain 32-bit and 64-bit DLLs
• Register the DLLs as COM objects (writing to HKCR, so needs Admin rights)
• Add some entries to the user's HKCU to tell Office the COM object exists (Office doesn't see these entries in HKLM)
• Register only the 32-bit dll on an x86 machine
• Register both dlls on an x64 machine

To do that I have:

• A Wix 4 bundle (x86) that contains two MSIs (one x86, one x64), installing one of them based on the VersionNT4 attribute
• Each MSI has a single Component
• The Component contains
  -- the entry for the dll,
  -- lots of <RegistryValue Root="HKCR" entries for the COM registration
  -- some <RegistryValue Root="HKCU" entries to tell Office the COM object exists

That all works fine if the installing user has elevated (admin) rights.

The Bundle gets created as a 'perMachine' bundle, so when run as a normal user, it pops up an elevated rights prompt, asking for an admin id and pwd. When I run that, the install works, but all the HKCU entries get written to the admin user's hive, not the local user. Is there anything I can set to ensure the HKCU entries get added to the hive for the user running the setup exe, not the admin giving the permission?

I've also tried pulling just the HKCU entries into a separate MSI and marking that as perUser, but when I do, that makes the Bundle a perUser bundle, doesn't pop up the Admin permission request and fails to install.

Can I configure the setup bundle so it installs some of the MSIs as perMachine (to register the COM Dll) and some as Per-User (to write the user's entries)?

[barnson]

Register the DLLs as COM objects (writing to HKCR, so needs Admin rights)

MSI redirects HKCR based on install scope:

msidbRegistryRootClassesRoot | 0x000 | 0 | HKEY_CLASSES_ROOT The installer writes or removes the value from the HKCU\Software\Classes hive during installation in the per-user installation context. The installer writes or removes the value from the HKLM\Software\Classes hive during per-machine installations.

So make the MSI per-user.

[StephenBullen]

Thanks barnson. Works fine for the admin user and if I install as an admin user before a normal user, but if I set the Package to have Scope="perUser", I then get an installation error when doing a first-install as a normal user that it can't write the Dll to Program Files.

For the file itself, I have:

<StandardDirectory Id="ProgramFiles6432Folder">
	<Directory Id="INSTALLFOLDER" Name="!(bind.Property.Manufacturer)\!(bind.Property.ProductName)" />
</StandardDirectory>
<ComponentGroup Id="AppComponents" Directory="INSTALLFOLDER">

Does that need to be something else with a perUser scope - and where would an admin file go (for HKLM to refer to)?
And what (if anything) should the KeyPath be set to refer to with that setting?

[barnson]

That directory requires a per-machine package.

[StephenBullen]

Yes, I'm tearing my hair out trying to work out the magic combination of what I need to put where and how to tell Wix to do that.

From what I've read, the combinations should be:
Admin user: DLL goes to Program Files, Classes to HKCR (redirects to HKLM), Office registration to HKCU
Non-admin user: DLL goes to AppData, Classes to HKCR (redirects to HKCU), Office registration to HKCU

So how do I specify the StandardDirectory that switches between Program Files and AppData, depending on the install type (and how do I determine the install type and write the conditions?)

[chrpai]

Strictly speaking HKCR doesn't exist. It's a view of HKLM\SOFTWARE\Classes and HKCU\SOFTWARE\Classes and when installing per-user you are actually writing to HKCU\SOFTWARE\Classes which does not require admin.

Also strictly speaking. .NET ComVisible and COM are two different things. This difference is less important but I wanted to make sure you were aware.

Is ProgramFiles redirection still a thing in Windows? I seem to recall that at least back in the Vista days that a non-priv attempt to install there would get virtualized in the user profile. Not that I like that. I'd probably author the installer to go to AppData\Local.

Your scenario sounds pretty easy and straight forward to me in case you'd like some consulting help.

[StephenBullen]

Thanks for the offer, but I'm a learn-by-doing person, so just trying to understand the right/best combination to use. Sounds like putting the dlls in AppData and HLCU would be the best thing to do.

[chrpai]

Hit me up if you change your mind. We could do it together. First hour is always free and in your case I'm pretty sure we'd be done in an hour and you might come away with a completely new perspective on how to make WiX a lot easier.