Closed retailcoder closed 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.
@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.
Also, I don't have any other add-ins installed on my machine.
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.
So, first thing to try is to Mashal.ReleaseCOMObject
on the projects/components we're trying to discard.
Haven't had a repro on this issue in a while. Closing.
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.