Inno Setup installs to the HKCU of the administrator account

[mwolfe02]

The new Inno Setup installer registers the add-in to the HKCU hive. This is likely a hard requirement for an Office VBE extension.

The problem is that the installer must run under elevated privileges. For some users (like me), this means that it gets installed under a different user account than the one used for development work. The result is that the install completes without error, but the add-in is simply not available.

If I try running Access or Excel as an administrator (i.e., under the account I used to run the installer), I get the following error when I try to switch to the VBA IDE:

'Rubberduck' could not be loaded.
Remove it from the list of available Add-Ins?

Please note that Rubberduck installed without problems for me under the previous installer. I personally use Inno-Setup for all of my own installers, so I'm not suggesting we abandon it. I do think it needs to be tweaked with this situation in mind.

My environment:
Windows 7 (64-bit)
MS Access 2002 (aka, Access XP; 32-bit)
MS Excel 2007 (32-bit)

[mwolfe02]

One possibility is to look into using the PrivilegesRequired attribute in Inno Setup:

[Setup]
PrivilegesRequired=lowest

The help document warns to be sure the installer would still work using this attribute, so it may introduce different problems.

[christophocles]

HKCU is definitely NOT a requirement. HKLM is the default for registration of any DLL, including Office VBE addins. Previous versions of the installer did use HKLM.

The entire point of registering the addin in the per-user HKCU registry hive is so that the installer would NOT require elevation, and individual users could install the addin for themselves without any administrator privileges. However, the installer currently still requires elevation. I really hope to see this corrected, but I have not yet had time to delve into the installer configuration myself.

[christophocles]

One other thing... the installer also defaults to C:\Program Files as the installation directory. Installing to this folder would require elevation. If the installer is run from an account without admin privileges, the installer must default to a user-writeable directory such as %APPDATA%, or else it still won't work.

[retailcoder]

@christophocles we changed that in the 1.3.0.1 installer scipt, it installs to all-user %APPDATA% (C:\ProgramData\Rubberduck), to address #440.

[rubberduck203]

@christophocles we're also installing libraries for VBA client code (including the Unit Testing functionality). This disallows a per-user install and is one of the reasons we declined #310. We're sorry that this is an inconvenience for you.

[rossknudsen]

@mwolfe02 I wrote the inno script installer, replacing the InstallShield one. Is this still an issue, chatting with the RD devs, they thought that your issue related to the use of the wrong PIA assemblies rather than an addin registration issue?

[mwolfe02]

@rossknudsen Sorry I've been away for awhile. I just got a new computer with Access 2013 (32-bit) and this is still an issue. The specific scenario is that I normally run with a Standard (i.e., non-Administrator) local Windows account (Principle of least privilege, and all that). I have a separate Admin account that I use for installs, etc.

The problem comes in when I run the installer. The Addin key gets created in the HKCU of the Admin account. When I run Access, I run it as the non-Admin account. Because no key got created in the non-Admin HKCU hive, I don't see Rubberduck when I go into the VBE.

The workaround I used was to manually create an "HKCU\SOFTWARE\Microsoft\VBA\VBE\6.0\Addins\Rubberduck.Extension" key in my non-Admin hive with the same three values as were added in the Admin registry key.

[mwolfe02]

I'm not sure the best workaround for this. I use Inno-Setup extensively myself, and I've not come up with a reliable way to handle this problem. I usually resort to setting these keys via another program that I know will be run by the local user at some point; that's not really an option here.

A quick and dirty option would be to include a .reg file that a user could run only if Rubberduck does not show up in the VBE. The .reg file would not require admin privileges because it would be applying an entry to the local user's registry hive (HKCU). One problem with that is it would prevent a clean uninstall, unless you wanted to loop through each of the HKU folders and remove the key for every user on the machine. As I think about it, you may need to do that no matter what method you use to deal with this issue.

Another possibility would be to consider using PrivilegesRequired=lowest as I mentioned in an earlier comment. I've never actually used that approach myself, so I can't advise you on what some of the pitfalls may be.

[rubberduck203]

MZ Tools has the same problem.

If you want to install MZ-Tools 3.0 for VBA for a non-admin user, you have two approaches:

Add the non-admin user to the "Administrators" group, log-on with that user, install MZ-Tools and remove that user from the "Administrators" group.
Make the admin user to install MZ-Tools (this step will register the dll as COM component on the machine for all users).

With your non-admin user, search the "Windows PowerShell ISE" script editor of your Windows operating system and open it. Then, execute the following statements (this step will register the dll as add-in for the non-admin user):

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

New-Item -Path 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns\MZTools3VBA.Connect' -Force

New-ItemProperty -Path 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns\MZTools3VBA.Connect' -Name Description -PropertyType String -Value 'MZ-Tools 3.0 VBA'

New-ItemProperty -Path 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns\MZTools3VBA.Connect' -Name FriendlyName -PropertyType String -Value 'MZ-Tools 3.0 VBA'

New-ItemProperty -Path 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns\MZTools3VBA.Connect' -Name LoadBehavior -PropertyType DWord -Value 3

I recommend that we use the same workaround and close this issue.

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

New-Item -Path 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns\Rubberduck.Extension' -Force

New-ItemProperty -Path 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns\Rubberduck.Extension' -Name Description -PropertyType String -Value 'Rubberduck'

New-ItemProperty -Path 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns\Rubberduck.Extension' -Name FriendlyName -PropertyType String -Value 'Rubberduck'

New-ItemProperty -Path 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns\Rubberduck.Extension' -Name LoadBehavior -PropertyType DWord -Value 3

[retailcoder]

👍 we could include this as a .ps1 script file bundled with the installer.