Hmm. Not good.
At BorCon, Allen told us that Delphi 2005’s refactoring metadata was based on the actual uses list, not just on what’s in the .dpr. But it’s looking like that’s not the case. If a unit isn’t shown in Project Manager (i.e., if it was removed with Project > Remove from Project, or was created while that project wasn’t open and then never added with Project > Add to Project), then it’s invisible to Find References, even if it’s still compiled into the EXE (by being included indirectly, via someone else’s uses clause). You can’t find references that occur inside that not-in-project unit, and you’ll have problems if you try to find references to something that’s declared in that unit.
This is bad news. We don’t add all of our units to our project files; it’d be a source-control nightmare if everyone had to check out the project every time they added a new unit. Even worse, we’ve got one codebase that’s used by several different projects — so every new unit would have to be added to every project (but only the ones that need it).
So Delphi 2005, and those refactoring tools I was so pumped about, are basically useless to us.
(Well, we can use Sync Edit, I suppose, and we can probably refactor unit-private stuff. But that’s about it.)
Oddly enough, the refactoring engine does have some awareness of units that aren’t in the project. If I declare a procedure in unit X (not in the project), and call it from units A and B that are in the project, it knows that both of those calls are to the same procedure. I can’t do a Find References from inside unit X (the menu item is grayed out), but I can do a Find References from the call site in unit A, and it’ll show the call from A and also the call from B. So it had to have built a parse tree for unit X. But it won’t use it. It won’t show me calls to that procedure that come from units X or Y (also not in the project).
It knows those methods are there, it just won’t show them to me.