RubberDuck should warn about ghost projects

[ThunderFrame]

The VBIDE sometimes persists a project, even after the host document is closed. That sometimes results in what appears to be duplicate projects, if a workbook/project with the same name (but not necessarily the same path) is subsequently opened. That can lead to confusion about which project is real, and which is a "ghost". Iirc, changes to a ghost project aren't saved when you press Ctrl-S in the VBE. Typically, the host application must be restarted to remedy the problem.

This ghosting issue seems to be caused by host application COM addins, that appear not to release a pointer to the project's host file. For example, in my Excel 2010, the PowerQuery COM Add-In causes this behaviour in VBE, but the problem goes away after I disable PowerQuery.

RubberDuck could address this VBE deficiency, and warn when there are ghost projects, and/or when a save won't actually save.

[retailcoder]

The irony? Current state of 2.0 is that closing the current project and opening a new one will send everything up in flames. That will definitely be fixed though.

The problem is that, accessing a project that's not really there will throw a COMException - but we can't presume we're getting a COMException for that reason... a COMException basically means "something isn't right", but there's no telling exactly what is wrong. So we'll swallow it and pretend it never happened. Or we can show some meaningless error message to the user, and then get support tickets for things we can't fix.

[ThunderFrame]

I think you can inspect the FileName property, but you'll get that getters error. If that property is an error, AND any of the document module properties don't work, then you probably have a ghost?

[ThunderFrame]

There's potentially a side issue here, in that if a ghost project is present, AND a real copy of that project is open, so you have a VBE with 2 projects that have the same name, then, IIRC, Code Explorer and Test Explorer (and probably TODO Explorer) all end up with duplicate entries under a distinct project name. That is, duplicate project names cause problems for the resolver.

[retailcoder]

Duplicate project names shouldn't cause problems, since equality for a QualifiedModuleName isn't relying on the projects' names, but on the projects' object references, which would point to different addresses.

[ThunderFrame]

Sorry, my typo. I meant 2 projects that are the same Project name and same document path, so they have the same references. I think that means that one of them must have been a ghost project.

I actually saw the duplicates in Test Explorer and Object Explorer, under CorrlDraw, under this scenario.

[retailcoder]

Oh great. 😞