Rubberduck: Non-Admin user Installation help

[ufo2mstar]

Hey guys, thanks for this cool project!
I am having some issues getting this add-in to install on my non-admin-privileged machine.

I did manage to nab the Rubberduck.dll and other files from the ProgramData of another machine I was able to run the executable installer on and then ran the following registry command on my PowerShell:

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

New-Item -Path 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns64\Rubberduck.Extension' -Force
New-ItemProperty -Path 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns64\Rubberduck.Extension' -Name Description -PropertyType String -Value 'Rubberduck'
New-ItemProperty -Path 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns64\Rubberduck.Extension' -Name FriendlyName -PropertyType String -Value 'Rubberduck'
New-ItemProperty -Path 'HKCU:\Software\Microsoft\VBA\VBE\6.0\AddIns64\Rubberduck.Extension' -Name LoadBehavior -PropertyType DWord -Value 3

It is not _super clear_ on your installation help page as to what i do after that.
As I have not work on this platform a lot, I would really like appreciate some help to get this up and running.

[retailcoder]

Thanks for the feedback!

The installer requires admin privs to register some COM interop types (e.g. AssertClass in Rubberduck.tlb, for the unit testing API). The installer also registers Rubberduck as a VBE add-in, and that's why a non-admin install is a problem, because VBE add-ins must be registered under the HKCU hive.

So after installing (with admin privs), you need to log on as the user that will use Rubberduck and create the registry keys that tell the VBE to load Rubberduck at start-up: that's precisely what that PowerShell script does (if you ran all of that, then you registered it for both 32 and 64 bit hosts... shouldn't matter, but one of these keys is likely not even probed by the VBE, depending on the actual bitness of your host application).

Once the add-in is registered as such under HKCU for the user that will be using Rubberduck, you should be all set: bringing up the VBE in any VBE host should get the VBE to look for add-ins under that HKCU key, and from there (if the installer ran correctly) it should know where to find the _Extension class, which is our entry point.

So you ran the installer and then logged on as the end user, and ran the PowerShell script: when you start Excel and bring up the VBE, you should see the Rubberduck splash screen for a few seconds, and then the VBE should be there, with a new Rubberduck menu and a Rubberduck command bar docked at the top, featuring a 'Pending' button that may go through a number of states and end up saying 'Ready' - if it doesn't start automatically then you'll have to click it to launch the parser.

Let me/us know if you hit any other issues!

[ufo2mstar]

ooh, so I do need admin privileges to run the installer before running the same as a non-admin is it!
Aww :worried: Is there no way I can do a good old copy the DLLs to the right directory and hack at the registry trick I can pull off in my severely constrained office laptop?
I was hoping there would be at least be a way to get this to work using the source code and building locally (or something to that effect) as I cannot admin into my machine at all (without painfully getting some approvals from people I would have to convince to use this)

[Inarion]

I tried as best I could to get the addin running without needing our admins. Which involved installing RD (normally, via installer) on my private PC and extracting all relevant bits and pieces from the registry. I then extracted all files from the installer file and tried registering all the .dll files in there (with the regasm.exe /regfile command, so I didn't need admin rights). In the end I replaced all occurences of HKLM in the obtained regfiles (both from regasm.exe and from my home PC) with the corresponding path in HKCU.
It just did not work out. The conclusion I drew from this is: Windows won't let you register certain components only for the current user (thus HKCU) - you can make all the entries to the registry you want, but Windows won't read them. :(

[retailcoder]

@Inarion that's correct: the docked toolwindows and other COM components need to be registered under HKLM, for that's where the VBE will be looking for the keys. Yet... the actual VBE add-in registration needs to be under HKCU.. which is why non-admin installs require a bit of gymnastics... actually we could probably make a non-admin build that doesn't include unit testing or any of the COM API.. truth is, we got the current single-installer-for-both-32-and-64-bits setup working around v1.22 after days (and nights!) of messing around and failing and trying again, and never dared to change any of it after we got it to work. COM registration is.... picky, to say the least.

[retailcoder]

@ufo2mstar I need to run VS as administrator to build the solution, otherwise the COM stuff won't register. MZ-Tools managed to get their add-in to install without administrative privs, so there's probably a way to "switch off" unit testing and everything that requires registering Rubberduck.tlb and get a VBE add-in that works, and there were efforts made quite early on in the project to get unit testing out into its own assembly, but things started breaking and we decided to leave it in the main assembly.. which leaves us with a requirement for admin privs to build/install.

I'd recommend you try Rubberduck at home and get a feel of its limitations and issues before filing a request with your IT department, especially if IT needs to get involved every time you wish to upgrade.

[Inarion]

@retailcoder regarding:

especially if IT needs to get involved every time you wish to upgrade.

Is that the case? To be more specific: Do we need to re-register certain components each time the files change? Or only if the files change in a way that warrants a re-registering?
I had our IT install RD to a location where I have write access, so I hoped that would be enough. (Not that it would be a problem if IT needs to be involved - they are nice guys and rather quick to react)

[retailcoder]

I guess that's for the IT guys to figure out, but the recommended course of action for upgrading is to perform a full uninstall from control panel's "add/remove applications" (so as to have the installer script cleanly remove and un-register everything), and then run the installer for the latest & greatest.

At least until we stabilize the plug-in architecture, every release is going to see breaking changes - when we're done, we'll be able to ship a standalone Rubberduck.Inspections.dll library upgrade, or even a Rubberduck.Inspections.Excel.dll standalone Excel-specific inspections package, which can be simply dropped into the "\rubberduck-install-folder\Plug-ins" directory and should "just work"... but we're not there yet.

[ufo2mstar]

@retailcoder and @Inarion
Thanks for the info guys. And that's a good point, I will play around with RD on my personal laptop for a bit. But I am very sure it is much much better than the century old VB IDE :stuck_out_tongue: and probably even worth the trouble of going through the IT guys.
And I hope you guys can get a portable version out there, would really help people in similar situations.
Cheers! :blush:

[retailcoder]

@ufo2mstar the only "thing" I have with "non-admin install" is that as far as I understand things, there's no way we could ship our unit testing API without it. It could eventually become an admin-privs-requiring plug-in though... but shipping Rubberduck without the unit testing API... I mean that feature is what started Rubberduck in the first place - up until recently there was still code that was directly ported from the VBA ancestor of Rubberduck's unit testing mechanism to C#... somewhere around commit 1.

[ufo2mstar]

@retailcoder ya, somehow circumventing the _registration by the installer_ part.
I was referring to some feature like where 7zip and others tools have portable versions that give us Win context menu integrations without having to play with the registry

which can be simply dropped into.. ..directory and should "just work"...

where, if possible, you guys can get past the system registry authentication mechanism and get a plug-and-play version. Or maybe it is that this problem is not solvable on windows at all, i'm not too sure..

[SystemsModelling]

+1 for some kind of install script that IT support can use on corporate images without knowing anything about Excel, VBA, or Rubberduck. Other than giving them a link to github to show it's respectable.

[rubberduck203]

@retailcoder the Source Control lib also requires COM registration. So, that would either need to be moved to a plug-in or simply removed. It's never worked quite right anyway, and I'll be honest, I no longer work with VBA so I've little motivation to make it work.

[FolkCoder]

Through painstaking trial-and-error, I've managed to get Rubberduck installed entirely in the HKCU registry hive, avoiding the need for administrator access. Everything seems to be working properly on my computer (64-bit Windows 10, 32-bit Office 2013), but I wouldn't guarantee that it would work on other configurations. I've learned way more about COM registration than I ever wanted to know, and I'm sure I'm only scratching the surface...

VBA code modules available at https://github.com/FolkCoder/RegisterRubberduck. Hopefully someone can get some use out of it.

[bclothier]

@FolkCoder cool, thanks! That will be useful for proving the idea that we can install the whole thing without an admin. The only concern I do see is that you hard-code all the GUIDs to be registered -- if we update or add new classes, this would need to be updated to be registered correctly. At least we can get thinking about a more generic solution.

[FolkCoder]

@bclothier Yes, I couldn't think of a better way to do it other than writing an application to parse the source code and generate a .reg file from the GUIDs defined there, generating new ones for the classes with no GUID assigned. This is at least proof-of-concept that it's possible to register a VBE add-in without administrator access, and provides a template (hopefully accurate) to where everything gets registered.

[bclothier]

FWIW, if a class has no GUID, they are likely not meant to be COM-visible, so we should not generate any new GUIDs beyond what the regasm.exe writes to the registry in the classes node.

[bclothier]

BTW jogged my memory - there is a tool that will get us all the registry information we need. It's Wix's heat tool. In particular the command to extract the registry information. IIRC, that will extract all the registry entries that must be made. That can be then run through a XML transformation (or something) to update all entries from HKLM to HKCU.