> The generic class `HostApplicationBase<TApplication>`, under `Rubberduck.VBEditor.VBEHost`, has a finalizer that calls `Marshal.ReleaseComObject()` to release the host app instance:
For some reason that needs to be investigated, `Application` can be `null` at that point, and `ReleaseComObject` throws a `NullReferenceException` when that's the case, that isn't handled.
> This SO question might help. I'm willing to award a +500 bounty to whoever has an answer that translates into RD 2.0 supporting unit tests in Outlook.
> Probably related to the fact that [Master] has no reference to Microsoft.Office.Interop.Outlook, and Application is referring to Microsoft.Vbe.Interop.Application - see OutlookApp.cs on Master
[Cardshifter/Cardshifter]Phrancis pushed commit 63b47bc8 to mods: Documentation is like sex; when it is good, it is very, very good; and when it is bad, it is better than nothing. (attempt at documenting Orde of Things)
> @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-Ad
> 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
So, I took a look at the August Challenge and thought, "hey, I should try that" - but given I only really know VBA, I did it in excel. Maybe that's not the intention, but I did it anyway. Experience it on github.
First thing to do is create the racetrack -
Sub CreateGrid()
ActiveSheet.Name ...
exactly. because we're trying to run code that's in a standard module; for Outlook VBA unit tests to work it seems we need to have them in ThisOutlookSession
> [MZ Tools has the same problem](http://www.mztools.com/v3/faq.aspx).
> 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 PowerSh
> Nice thinking @ckuhn203. Makes sense that MZ-Tools would also have this issue as it is simply a limitation of the Windows user security/profile model.
@retailcoder You may want to avoid a Powershell script as PowerShell's default [ExecutionPolicy](https://technet.microsoft.com/en-us/library/hh849812.aspx) will not allow it to run:
> Restricted: Does not load configuration files or run scripts. "Restricted" is the default execution policy.
> I'll happily take a PR with any reasonable solution that means anyone installing Rubberduck can double-click on a file and the thing just works :smiley:
So, I took a look at the August Challenge and thought, "hey, I should try that" - but given I only really know VBA, I did it in excel. Maybe that's not the intention, but I did it anyway. Experience it on github.
First thing to do is create the racetrack -
Sub CreateGrid()
ActiveSheet.Name ...
VBA Rubberducking
VBA Rubberducking