Provide CLI to support CI Runners

[robodude666]

Rubberduck is a fantastic tool for development. However, the VBA environment must be running and tools must be accessed manually via menus/shortcuts. It would also make a great tool for quality control in a Continuous Integration environment. In order to support these environments, Rubberduck should provide a CLI interface for commonly used functions.

For example:

• Code Inspection (provide list of failed inspections).
• Run Unit Tests.
• Print out Dependency tree (see #3004).

Some other functions that could be useful:

• "Compile" project - is VBA code even valid?

[rubberduck203]

There are problems with using RD as a CI tool. While I think it's possible that something like the Web Inspector could be made to work from the CLI, there are licensing issues with installing Excel (or any office app) on a server. And for RD to be useful as a CI tool, you would really need access to a host program. I think this could be done, but I'm afraid that we'd be giving users enough rope so they could shoot themselves in the foot.

@contributors thoughts here?

[Hosch250]

Rubberduck does not execute code, so 2 is completely out of the question. We don't have 3 as an internal feature yet, AFAIK, so that is out of the question for now as well. 1 is possible, but I, for one, am not interested in adding a third project to the suite when we can barely keep up with the core RD.

[rubberduck203]

@Hosch250 if someone else implemented it, would you want to maintain it? I'm guessing not.

[retailcoder]

Static code analysis done outside the VBE is definitely possible, and actually not very complicated - a day's work and you have a very decent CLI solution. Ditto with inter-module/procedure dependencies. As for the compile check, ...if you can analyze it, it parses, therefore it compiles. Note, despite our best efforts some compilable code still won't parse (can't think of any specific example though).

As @Hosch250 said, RD doesn't run anything. When RD runs unit tests it merely uses the host application's API to call Application.Run such as execution resumes in our code base after a test runs to completion. I don't think anyone anywhere has ever implemented a VBA interpreter that can work for all possible compilable VBA code... and that's a whole entire can of worms I'm not touching with a 10-foot pole.

[retailcoder]

That said, I think it would be really nice to have a CLI application that exposes some API commands... I could picture something like this:

C:\Dev\VBA\Stuff\> rubberduck -vbp Test.xlsm -inspect -fix suggestion -indent
Rubberduck v2.1.5.44521
-vbp Test.xlsm
Loading Microsoft Excel document...
Loading referenced libraries...
Parsing VBA project...
Resolving declarations...
Resolving references...
-inspect
Inspecting...
-fix suggestion
Hint: Parameter 'foo' can be ByVal; Module1.Test L26C15
Default fix "Pass parameter by value" applied.
Suggestion: Function 'Test' can be implemented as a procedure; Module1.Test L26C10
Default fix "Convert to 'Sub' procedure" applied.
-indent
Indenting modules...
Changes completed.
Host file saved successfully.
C:\Dev\VBA\Stuff\> 

[ThunderFrame]

editing the module content will mean zapping the SRP files, removing p-code content in every module, and updating the project file with the source-code offsets.

[robodude666]

@retailcoder yeah, that'd be freakin' cool.

Also, good point on parses -> compiles.

@ThunderFrame not sure I'm following. If rubberduck launches an instance of Excel.Application (via COM), it can use the host to make changes as it normally would.

Regarding running unit tests, I understand RD doesn't actually execute code. But if it created an Excel.Application object it can still execute Application.Run.

[PeterMTaylor]

@retailcoder Linking this with #803 as the concept was discussed with an idea of a use case via Appveyor. Your vision above ^ showed what possible commands would look like if considered within the test section script I thought could be executed.

[robodude666]

Note: I did get @retailcoder's example from #2923 to work in a simple console application, but haven't figured out how to programmatically generate the *.xml library files.

As I highlighted in that issue as well, it would be really great to see RD split up into libraries that other developers can use for creating tools. It'd be even better if RD didn't directly rely on VBE directly but instead on an abstract interface that could have a VBE implementation but could also have a more basic in-memory implementation.

[Vogel612]

@robodude666 there already is plans for splitting RD into a plugin-based architecture. This should allow users to create specific tools for their needs and integrate them with RD.

Abstracting away from the VBE seems like a very significant step into the direction of a general vb-based language inspection and processing tool, which may be quite the overstep, because that's too diverse an ecosystem.
Overall the idea of abstracting the VBE away isn't terrible from a certain PoV (think MockVbeBuilder and related classes), but doesn't seem like a worthwhile concept to maintain for production code, if only because it's a whole project of similar (or bigger dimensions) in itself.

If we want to abstract away from the VBE, we might as well write our own full IDE, that can fully interpret VBA code with all possible host configurations you can think of, which is - though jokingly suggested in the war room - madness.

Long story short, I think while there are some good suggestions in here, most of them are already more or less implemented / covered by other features, that the good suggestions that aren't are simply too much effort and maintenance to be worth their while ...

[retailcoder]

@Robodude666 FYI RD does depend solely on interfaces.. but interfaces must be implemented - we're implementing them with a whole suite of wrapper classes that wrap up the entire VBIDE library; in theory we could implement them with wrappers around the VB6 IDE extensibility library and have RD run in both the VBE and VB6. But we can't just have interfaces and nothing that implements them - and as @Vogel612 said there's no way we're writing our own IDE to implement the VBIDE interfaces.

As for the xml's, cloning the repo and running a debug build will expose the 'Serialize' command that generates the .xml files out of the project's referenced libraries.

[robodude666]

@retailcoder from my review of the code RD depends on the comwrapper interfaces which depends on the VBIDE COMObjects to exist.

Shouldn't RD's dependency be on a more abstract interface that doesn't have anything to do with COM, and then have a more concrete implementation for the com wrapper classes?

[rubberduck203]

Unit Tests will never work without a host application to actually run the code under test. They call Application.Run under the hood.

[ThunderFrame]

Except for Outlook, which calls Application.EatMyHat a CommandBarButton. 😜

[rubberduck203]

lol. Yes. Except for Outlook.... The point I was making is that RD is a COM plugin for an application that does all of its communication with other processes via COM. It's deeply rooted in the project. Yes, the team has done an amazing job of abstracting this away from the logic of the plugin, but it's still there.

And you still need a host for any of that logic to be useful.

[retailcoder]

The interfaces RD uses are 100% ours, 0% COM. The dependency isn't with the abstractions, it's with the implementations - If you can implement all these interfaces (i.e. write your own IDE), then RD will happily work with those.

[lastlink]

I wonder if we could use some kind of vba engine w/ fakes and mocks for testing outside of microsoft access such as https://github.com/msaccess-vcs-integration/msaccess-vcs-integration that syncs code to access.

[Hosch250]

Now that this came back into my feed, it would be trivial to implement a CLI tool once we get our parser/inspections working off a language server.

[Vogel612]

@Hosch250 that won't work for running unit tests because we delegate those to the runtime and they are usually not installed on a ci server...

[Hosch250]

That is correct. But inspections could be run from the commandline with minimal maintenance effort.