search

rubberduck-vba / Rubberduck

Every programmer needs a rubberduck. COM add-in for the VBA & VB6 IDE (VBE).
https://rubberduckvba.com
GNU General Public License v3.0
1.92k stars 302 forks source link

Run-time error ’-21474672262 (80004002)’: #5558

Closed peternroth closed 4 years ago

peternroth commented 4 years ago

First time use of version 2.5.0 W10 Microsoft Access 2019

In Microsoft Access, click on Insert Module, RubberDuck throws

Run-time error ’-21474672262 (80004002)’: Unable to cast object of type ‘VBClassicExtensibility.VBProjectClass’ to type ‘Microsoft.Vbe.interop._VBProject’.

And throws the error at least once more. Looks like the cast is in a loop?

retailcoder commented 4 years ago

Looks like a non-standard setup wrecking COM registrations or something. VBClassicExtensibility.VBProjectClass is not something you normally see in a VBA host.

Perhaps VB6 was installed after Office 2019? Installing Microsoft products in non-chronological order tends to break COM registrations that way, too - although I'm wondering how it successfully dealt with the IVBE interface at startup if IVBProject is a problem.

Not sure what we can do other than fail more graciously, ...but then again if RD can't invoke VBProject.VBComponents then I'd say RD is essentially bricked. The multiple exceptions are likely just different calls to some wrapper; to insert a module we need to access the project, then that project's components collection, then a method on that collection that pipes the command through the VBIDE Extensibility API. What's weird is that if something is off with the types involved, then the add in should blow up way earlier than that - looks like only a few specific CLSIDs were broken.

retailcoder commented 4 years ago

Linking Carlos Quintero's (MZ-Tools author) comment on #3837: https://github.com/rubberduck-vba/Rubberduck/issues/3837#issuecomment-392195463

retailcoder commented 4 years ago

The type involved in the cast is defined by MZ-Tools; Carlos explains it in the linked issue, but the problem is ultimately that the IDE is loading two .net-based add-ins, and the two are marshaling COM types into .NET types, and if one "wins" then the other "loses": you can try configuring the MZ-Tools add-in to not load at startup and try to load it manually after Rubberduck finished initializing, but basically in order to fix this interaction we have to "shim" the .NET runtime itself [or use the same wrapper libraries as MZ-Tools, I think - but then that wouldn't address interactions with other .NET add-ins) and that is a lot more work and research than I'm personally willing to pour into fixing that particular issue - especially with .NET Core 5 being just around the corner and making COM shims entirely moot.

alexis-idigo commented 1 year ago

@retailcoder Thanks, I had the same issue, and it was MZ-Tools incompatibility.