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.91k stars 300 forks source link

Closing a project keeps it in the VBE #1155

Closed retailcoder closed 8 years ago

retailcoder commented 8 years ago

Per this SO answer, MZ-Tools and Smart Indenter have the same problem.

However in our case, a TargetInvocationException gets thrown as soon as we reparse, which takes down the host app.

When the project gets correctly removed, opening a new or existing project blows everything up as well.

Lovely COM interaction at its best. Tagging with [code-parsing], since it seems to be related to parser state. Not sure how to fix.

ThunderFrame commented 8 years ago

Iirc, the ghost projects are due to certain COM addins in the host app. When I disable the Power Pivot for Excel COM Add-In, the ghost projects aren't in VBE anymore, but they are in RD explorers, based on build of a 1-2 days ago.

retailcoder commented 8 years ago

@ThunderFrame thing is, the RubberduckParserState instance is holding on to object references (VBComponent objects) that become stale when the project is closed; if I attempt anything to get rid of these references, the VBE keeps the project in the Project Explorer - if not, it gets removed correctly... but then, it boils down to how would you like your VBE / host app to crash - because it craches either way.

retailcoder commented 8 years ago

Also, I don't have any other add-ins installed on my machine.

ThunderFrame commented 8 years ago

Hmm, I wonder if we have a 2-dots problem... This is an article for VB.NET, but there's an SO post for C# here

Using Two Dots when calling xlApp.Workbooks.Add creates an RCW (Runtime Callable Wrapper) for the Workbooks object. If you invoke these accessors, the RCW for Workbooks is created on the GC heap. However what’s worth noting is that the reference is created under the hood on the stack and are then discarded. Because of this there is no way to call MarshalFinalReleaseComObject on this RCW. Therefore, if all references have not been released on the RCW, the COM object does not quit and this results in an instance of your Excel Application (in this case) being left in Task Manager.

retailcoder commented 8 years ago

So, first thing to try is to Mashal.ReleaseCOMObject on the projects/components we're trying to discard.

retailcoder commented 8 years ago

Haven't had a repro on this issue in a while. Closing.