Is there an annotation for auto importing References so that they are turned on?

[AlpsDevABE]

The other day as I was perusing some of the documentation I thought I encountered a super secret page that I can no longer find, and I've just scoured everything in the wiki and the site.

I thought I saw something that say you could annotate:
'@ImportReference mscorlib
'@ImportReference Microsoft Scripting Runtime
'@ImportReference Path/To/Utils.xlsm

and then if you have rubberduck it would auto import the libraries. I think this could be really neat feature, especially if you can use the Rubberduck Reference Add/Remove feature to help write the specific annotation into a blank module that would just be for auto imports.

That way, you can explicitly declare what references are required in the project and use a quick-fix or just occurs on RD Parse.

Is this something that would interest others, can I make that a feature request? Or did I really find a hidden annotation and somebody can enlighten me to use it.

Like a Python's requirements.txt for PIP

[retailcoder]

There isn't, because we specifically did not want to hijack an entire module or otherwise force our users to include project components that serve no purpose without Rubberduck, like a blank/comment module would.

Because they're project level, having them as annotations in any particular given module makes no sense and opens up the possibility of introducing conflicts and confusion, not to mention what to do with a typo or an annotation referring to a library that cannot be found.

In v3.0 we redefine what a VBA project is, and moving the "source of truth" to a workspace folder (from the VBE in 2.x); RD3 projects will be entirely defined in a dedicated .rdproj file that lists all the libraries that need to be referenced (among other metadata); making sure the in-VBE project is actually referencing all the libraries listed in the project file is already part of its scope and doesn't need any additional development or features: it's just part of what synchronizing a RD3 workspace entails. Developing this in 2.x might be temporarily useful, but it's ultimately wasted effort since the feature necessarily becomes moot in 3.0.

That said in over 25 years of Classic-VB development experience I have never encountered disappearing project references and I'm curious about how one ends up in a situation where a project is actually coded against a library but the library isn't referenced (anymore?), without it involving a manual step that explicitly removes the library reference (why then?).

RD3 also introduces project templates, so it's going to be very easy to create a new project that references libraries X, Y, and Z without needing to think about adding the reference to the project, and then workspace synchronization can easily skip libraries that aren't actually used in a project/workspace.

Sorry that's probably not what you wanted to hear 🫤

[AlpsDevABE]

I read your blog posts on RD3; I'm very excited about this development!!!

Your argument makes sense and I accept the viewpoint as-is.

To enlighten the mystery of library references disappearing/ or not.

This is mainly caused by the development pipeline, legacy team shackles being broken and aspirations of what should be in Git but isn't. Ideally the way the sheet looks and the formulas in them, it would be nice if those were versioned too that way disaster recovery can be completed through git code alone. The team manages some 200 plus odd macros with an infrastructure where there are two files per macro. One file is the actual file in use by the user, whereby there can be copies by date, by client etc.. and they all connect to the second have which is centralized. This is so that updates can be made and push across all files without having to update the individual copies which would be a nightmare.

My reasoning is that GIT stores the code but, if one of the corporate virus scans; corporate backups or what have you completely nukes a file, it would have to be recreated through what is in git. Obviously if you are compiling the code, you'll see that there are missing reference if you ever had to create a file from scratch again.

This comes also from a team that used to have extreme prejudice against early binding, probably steaming from Outlook or other office libraries changing version numbers between upgrades. However instead of making those judgements reference by reference it was always cross cutting and became prejudice against all early bindings. Teams change, times grow, lessons learned, there's never an issue with Microsoft Scripting Library and mscorlib.

As an aside:
I love me some arraylists. I also saw and double checked your other post on Stack Overflow about Collection's speed vs Arraylist speed and that made me sad.

So its a combination of

• what would the disaster recovery steps look like
• Technically it would be nice to explicitly state intent for a module or class that it is early binding a reference that is required to be loaded
• And with 200 plus files, there is quite of few imports that require added references (albeit rare)
• And the discovery of using rubberduck annotations to make default members and iterators being pretty darn awesome!! (albeit, a bit buggy; Not removable by deleting annotation, at least when I tested it)

[retailcoder]

Awesome, this is great info, thanks for circling back!

I've been lucky to work in environments where all users had the same Office version installed! Indeed early bound references could be a problem otherwise, and late binding at least the deployed version (toggle a precompiler constant?) is a good idea then. Another alternative could be to "build" and save a copy for each Office version, using that specific version: if they're installed in sequential order (by release date) you can normally run different Office versions side by side. Side note, running different Office versions side by side that were registered out of order is about guaranteed to break Rubberduck's COM interactions with the Office library (which defines the CommandBar API).

Not removable by deleting annotation

Annotations synchronize with corresponding attributes via inspections (kind of annoyingly so, but that's another story!); if there's an attribute without an annotation, unless the inspection is disabled a result for "missing annotation" should be issued, offering quick-fixes to either add the comment or remove the hidden attribute.
It's a bit of a mess because it's different inspections flagging different situations at different severity levels (by default anyway) and under different categories.

I read your blog posts on RD3; I'm very excited about this development!!!

☺️ Thank you!! There's another RD3 update coming by the end of the week! I also post small updates (including screenshots that may or may not end up being "it") between blog posts on the Ko-fi platform as I progress (and find some time to then write about it). These posts are "paywalled" behind whatever amount you're comfortable with though: they're the way I've found to give Ko-fi supporters a little something in return (both one-off and monthly - not enough monthly members to worry about coming up with something else anyway 😅).