> I think I'd be more interested in knowing how it arrived to the `Worksheet` instead of the `_Worksheet`.

If I go up through the `ParentDeclaration`, it describes the `_Worksheet` as a `ClassModule`; there is no mention of the `Worksheet` anywhere in the chain.

This is what I see when describing both (ran from immediate window while in break mode in file `RubberduckTests\Symbols\SelectedDeclarationProviderTests.cs` at line 839:

```
?state.DeclarationFinder.DeclarationsWithType(Decla

> Here's what I get:

```
?state.DeclarationFinder.DeclarationsWithType(DeclarationType.ClassModule).Where(x=>x.ComponentName == "Worksheet").First()
(ClassModule) Public "Worksheet" As "Worksheet" | {L1C1}
Accessibility: Public
Annotations: Count = 0
AsTypeContext: null
AsTypeDeclaration: (ClassModule) Public "Worksheet" As "Worksheet" | {L1C1}
AsTypeIsBaseType: false
AsTypeName: "Worksheet"
AsTypeNameWithoutArrayDesignator: "Worksheet"
Attributes: Co

> Looking at the history here: https://github.com/rubberduck-vba/Rubberduck/commit/862ed33a6e7c0307e98a81f0956206164bc9a27b

It looks like the qualified member calls in are resolving to the underscored/hidden interface/class, and unqualified ones resolve to the non-underscored type - it was probably breaking some inspection, and treating them like one and the same basically fixed the symptoms. I'd pragmatically just make the test pass by tweaking its expectations, and then there's perhaps an u

> > Well, it sounds like getting the test to pass on my machine may cause it to break in AppVeyor, right, @bclothier?

Yes, it did break AV originally and it fails on both VMs with 2019 and 2022, respectively.

I'm in favor of marking it ignored until we can establish what's really going with this. It has the markings of a heisenbug which will take a while to figure out....

> Looking at the script, it’s likely that your machine has its registry reset in entirety and thus the script is not sufficient to fix the issue. As there are a LOT of registry entries that must be made for it to run, running the installer is probably the simplest method in such environment. [You can pass parameters for it to run quietly at login](
https://jrsoftware.org/ishelp/index.php?topic=setupcmdline).

> I've already explained in the first post that per-user mode won't work in companies that have restricted all access to the Installer service (like the one I currently work in), so in such cases you can't do even user-based kind of installations.
Just take a look at the portable version of MZ-Tools and you'll see what I mean - no installation whatsoever, extract the zip in a folder of your choosing and use the provided tool to register/unregister the addon in the HKCU registry userspace. That

> I've already explained in the first post that per-user mode won't work in companies that have restricted all access to the Installer service (like the one I currently work in), so in such cases you can't do even user-based kind of installations.

Just take a look at the portable version of MZ-Tools and you'll see what I mean - no installation whatsoever, extract the zip in a folder of your choosing and use the provided tool to register/unregister the addon in the HKCU registry userspace. Tha

> I've already explained in the first post that per-user mode won't work in companies that have restricted all access to the Installer service (like the one I currently work in), so in such cases you can't do even user-based kind of installations and it makes sense to prevent such installations if you don't want your employees to install whatever they want (do they have the need for what they're installing is another topic).

Just take a look at the portable version of MZ-Tools and you'll see

> Wasn't aware it's Inno... Well, it's true, Inno doesn't rely on the WIndows Installer service, yet, for some (unknown) reasons I get permission errors when I try to do the per-user install.
Nevermind, maybe the current Windows installation is broken somehow. I need to do some investigation so for now I'm closing this one.