Debug/Developer Commands

Our plugin has several test commands we use to debug or trial a new feature – is there any suggestions for how to remove or disable these from release versions? I’ve attempted setting build conditions to exclude these .cs but was breaking the build (potentially user error here, was following this: MSBuild Exclude Files). Have also looked at hiding via Test/Style.Hidden, which works but but is kind of annoying then having all the other Test commands appear, and not a great experience.

Goal would be to control which commands included/excluded from plugin versions, almost like feature flags.

For context newbie to plugin development, so any suggestions are welcome!

I assume you use Visual Studio for your plugin development? If so you can create another build profile called “Testing” and do #define like

#if Testing
// Test commands

Thanks @user1986 – I had previously tried using #if DEBUG which I think this is essentially the same? I’ll give it another go.

I would use the conditional compile tag to do this. So based on configuration choose what to include, what not

    Condition=" '$(Configuration)' == 'ReleaseTrial' " />

With above sample the file will be included only when ReleaseTrial configuration has been selected. This means you have to add the configuration in your solution for it to exist with that name.


The advantage of using a custom preprocessor flag is that you can set these as build arguments or somewhere else in the code.

I just want to point out that this is only required if you don‘t want these commands to be compiled with. The problem with these are , that you basically compile more than one version of your source code. It can indeed lead to a problem where this divergence makes bug hunting problematic. The more code you build differently, the less you can smoke test reliable. In this regard it indeed makes sense to ship the test commands and only hide them.

Another thing, as you said, you are rather new to plugin development. Are you aware of the possibility to attach a debugger? There are certain use-cases for test commands, but only in rare occasions if you know how to properly debug!

1 Like

Thanks @TomTom – this makes sense.

Attaching Debugger? We use debug mode in Visual Studio extensively if that’s what you’re asking?

I think I’m probably talking about test commands in two different ways: 1) I have a bunch of user-testers that I want to test a new feature (command), so commands should be included in the build, however because we’re testing they might break or do weird unintended things, so I don’t want everyone using them (accidentally or otherwise), however I also I don’t want to keep track of which people are on which version (its easier for debugging that everyone is always on the latest build). This is where the feature flag or “testing” mode would be helpful, something like testing commands, but just for our plugin.

Secondly there’s commands that we use in development that are shortcuts for testing things or quickly demoing how a particular feature works – it might be something like arraying a box on a grid 20 times, or generating a simple room, setup type stuff. We could have saved files/templates for this but its easy if its a command so its not reliant on other stuff. These are the ones shouldn’t get compiled (testing commands works here, but personally I find it annoying to use).

Hope that helps explain the user case – any suggestions would be appreciated, but since commands are registered when the plugin loads I’m not sure how this would could work?

Also @nathanletwory thank you for the suggestion but I keep getting bloody Rhino plugin OnLoad errors with this approach (it could well be I’m not building correctly). I did modify your example to set Include as a whole directory in my project which could be the problem, although that seems logical, rather than keeping track which commands have an include tag in the project file…

A beta version could come with .pdb files. You can attach the VS compiler to a Rhino process at any time then, also remotely. It even works on release builds without .pdb when using DNSpy. This way you can actively debug during testing and only on demand.

Regarding 1.) If you want others to test your code it is important to always know what they are testing. Most important for beta-testing is logging. Log a lot and always ask for a log file when an error is reported. Log files should contain the binary version of your application, and if possible a git commit hash. Logging is so important, because (if done well), you can always recreate what the user did and see anything weird. Logging is more important in production code than anything else.

Regarding 2.) You could also provide an additional plugin or dll, which creates a test environment for beta-testers. I truly believe in modularisation, and I would prefer such a solution over conditional compilation

1 Like

Thanks @TomTom – didn’t know about attaching a debugger/releasing with pdb files…

I’ve previously looked at using serilog or even MS logger because of the fact its really difficult to identify whats gone wrong without having a debugger, wasn’t too sure how to implement so I put on the backburner.

Can you explain more about what you mean by test environment/additional dll?

Also @nathanletwory thanks again, this ended up working for me:

    Condition=" '$(Configuration)' == 'Release' " /

My plugin load bug was because I had a release directive somewhere else for our github build action that wasn’t doing anything when I released locally. :man_facepalming: