Microsoft.Vbe.Interop missing

[mwolfe02]

I just changed my development user account from "Standard user" to "Administrator" and re-installed Rubberduck. The install seemed to go OK, but the first time I tried to open the VBA IDE, I got the following error message:

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

I did some digging and it looks like the problem originated with the RegAsm.exe /codebase command. There was no error during installation, so I tried running the RegAsm command directly from a command window. Here are the results:

C:\Windows\Microsoft.NET\Framework\v4.0.30319>regasm /codebase "C:\ProgramData\Rubberduck\Rubberduck.dll"
Microsoft .NET Framework Assembly Registration Utility version 4.0.30319.18408
for Microsoft .NET Framework version 4.0.30319.18408
Copyright (C) Microsoft Corporation.  All rights reserved.

RegAsm : warning RA0000 : Registering an unsigned assembly with /codebase can cause your assembly to interfere with other applications that may be installed on the same computer. The /codebase switch is intended to be used only with signed assemblies. Please give your assembly a strong name and re-register it.
RegAsm : error RA0000 : Could not load file or assembly 'Microsoft.Vbe.Interop, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified.

The key part is the following:

Could not load file or assembly 'Microsoft.Vbe.Interop, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified.

My environment:

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

[retailcoder]

So... the solution is to package every possible version of the DLL?

[mwolfe02]

I think there are some less drastic options (but I'll admit this is not my area of expertise).

[mwolfe02]

Option A: Embed Interop Types

[rubberduck203]

Hmm.... Embedding interop types might undo our ability to package the unit testing as a separate dll. Which, is okay I suppose.

[mwolfe02]

Option B: Use NetOffice instead of the Office Primary Interop Assemblies

[rubberduck203]

We've discussed NetOffice before. There wasn't a need at the time. @retailcoder perhaps we should revisit.

Although, I'd still like to know why RD isn't finding the extensiblity library. Shouldn't it be installed with every office installation?

[retailcoder]

This isn't an ordinary interop assembly here, it's the VBE Extensibility library. Does NetOffice package that?

[mwolfe02]

That's a good question. I don't know off-hand.

[mwolfe02]

Option C: If possible, use an older version of the 'Microsoft.Vbe.Interop' library

Depending on what functionality you are relying on, this is a possibility. I don't know what this would require as far as Rubberduck developers having this older copy. This may or may not be practical.

[mwolfe02]

Option D: Tell me (and all the other laggards) to get a recent version of Office already ;)

This is not an unreasonable approach by any means.

[retailcoder]

LOL! 😆 I was getting there @mwolfe02! haha.. seriously, I think the first thing to check is whether we're embedding the interop types for that assembly.

[rubberduck203]

I can confirm that we're not. I was just looking at it the other day when I was splitting RD into multiple projects. Maybe we should be.

FYI: [NetOffice has a VBIDE library](http://netoffice.codeplex.com/SourceControl/latest#Assemblies/Any CPU/VBIDEApi.xml) and has an MIT license.

[rubberduck203]

@mwolfe02 I just noticed why it used to work for you, but doesn't now. The machine that I built the installer on has Office 2007 installed on it. @retailcoder built that last installer on his machine, which has a newer version installed than my dev machine.

[retailcoder]

@ckuhn203 eh, tag 1.3.0.1 was created by you, remember 😉

[rubberduck203]

I absolve myself of all responsibility for the 1.3 release. 😸

[retailcoder]

The VBIDE dependency wasn't embedding its interop types in all projects (only the SourceControl project was actually) - I'm going to close this issue as fixed, keeping in mind that it might come back and bite us later.

[retailcoder]

Embedding all interop types causes build issues. @mwolfe02 is not embedding interop types and turning "copy local" to true an option?

Having Microsoft.Vbe.Interop.dll and Office.dll in the bin folder doesn't feel right though...

[rubberduck203]

@retailcoder we can always just fold the unit testing back into the main project. That should resolve the build issue you saw.

[rubberduck203]

Per this conversation, the idea was to make it so that the references required for unit testing would stop breaking on each update, so folding it back into the Rubberduck.dll might not be a great idea. Idk.

[rubberduck203]

Added this to 1.4. I think we have no choice but to deal with this before the next release.

[Hosch250]

Now that the unit tests are back in Rubberduck.dll, is this issue also fixed?

[retailcoder]

Office Core and VBIDE don't seem to have an issue with embedded interop types anymore, so I'm closing this issue.

[nemphys]

So, is this issue resolved? Because I have exactly the same setup as the OP and I am getting exactly the same messages ("Rubberduck could not be loaded" inside VBE and the Interop missing stuff when trying to run regasm from the command prompt).
Any help would be appreciated...

[rubberduck203]

@retailcoder have you seen @nemphys' reply here? I was just wondering if anyone's looked at this recently.

[retailcoder]

@ckuhn203 this issue predates the switching over to NetOffice PIA's, no?

[rubberduck203]

Yeah, which we never actually did because the NetOffice PIAs broke the office interface contract.