Debugging the easy way

[Mike.Sheen]

I don't know why I never tried this earlier, but I have now and I've discovered an easier way to debug my plugins.

Some of you may have already known this, but I didn't and I thought I'd share in an effort to make everyone's lives a little better.

Previously, when debugging a Jiwa plugin, I'd always just put in a line of code System.Diagnostics.Debugger.Launch(); and System.Diagnostics.Debugger.Break(); which would cause the registered debugger (Visual Studio in my case) jump up and start debugging.

That itself was a huge step up from the bad old days of debugging VB Script, and that might be why I never bothered to explore what other ways there were. I sort of did have an inkling the newer way I'm about to show was possibly, as it's similar how I debug the services we have, but never invested any time into it.

The drawback of the Debugger.Launch() / Break() method is you need to edit the plugin and then logout of Jiwa, log back in and then perform the right actions to hit your breakpoint. Sometimes this is just darn inconvenient, particularly if you've got a lot of actions / steps to replay to get to the point / state you want to be.

Anyway, this new method is as follows - I'm using as an example a plugin which does stuff within the Sales Order form.

This is the plugin - nothing unusual here:

The plugin has on the Forms tab an entry for the Sales Orders form, as you'd expect. This plugin simply displays a messagebox when a sales order is being saved.

To debug this, Jiwa.exe needs to be running already.

Open Visual Studio and select the "Continue Without Code" option

Then, on the Debug menu, select Attach to Process

Debugging_VS_Debug_Attach_Process.png (15.46 KiB) Viewed 7203 times

A dialog will appear - locate the Jiwa.exe process and Attach

Now, select the Open File tool (or use the File Menu, either way)

Debugging_VS_Open_File_Tool.png (11.65 KiB) Viewed 7203 times

Now locate the source file for the plugin. This will be in the ProgramData folder, and you want the .cs or .vb file which is the same name as the plugin name. The folder path is C:\ProgramData\Jiwa Financials\Jiwa 7 then Jiwa version, then windows user, then SQL server name, then database name, then Plugins, then Jiwa user, then Compile then the plugin name. Select the file and press the Open button on the dialog

Visual studio will display the plugin code - locate where you want a breakpoint and click on the line of interest and press F9 to set a breakpoint

Then, back in Jiwa, perform an action to trigger the breakpoint - in my example I set a breakpoint in the Setup method of the FormPlugin class - so Visual Studio jumped in as soon as I opened the sales order form.

And from there you can step through the executions, inspect variables, add watches and all that good stuff.

Enjoy!

[pricerc]

I found it to be the only method you can reliably use if you're debugging a Windows service or IIS-based web service.

Debugger.Launch() / Break()

I usually use:

Code: Select all

If Debugger.IsAttached() Then
    Debugger.Break()
End If


of

Code: Select all

if(Debugger.IsAttached())
{
    Debugger.Break();
}


And then leave them in my plugins until I'm debugging something completely different and it starts annoying me.

[Mike.Sheen]

And then leave them in my plugins until I'm debugging something completely different and it starts annoying me.

I too have been annoyed by this practice of yours. I've been handed service tickets to solve along with a database which must have originated from something you were involved in, as I found the conditional debugger breaks littered around the place.

[SBarnes]

I usually do this so that I can insert debug statements where ever I want with a Debug.DoDebug(); and simply disable them by commenting out two lines, simple but it works

Code: Select all

 public static class Debug
    {

        public static void DoDebug()
        {
            System.Diagnostics.Debugger.Launch();
            System.Diagnostics.Debugger.Break();
        }
    }


[SBarnes]

you need to edit the plugin and then logout of Jiwa, log back in and then perform the right actions to hit your breakpoint. Sometimes this is just darn inconvenient, particularly if you've got a lot of actions / steps to replay to get to the point / state you want to be.

Actually this is inconvenient in general is there any way to have a changed or newly imported plugin reloaded without the whole logout and login process.

[pricerc]

you need to edit the plugin and then logout of Jiwa, log back in and then perform the right actions to hit your breakpoint. Sometimes this is just darn inconvenient, particularly if you've got a lot of actions / steps to replay to get to the point / state you want to be.

Actually this is inconvenient in general is there any way to have a changed or newly imported plugin reloaded without the whole logout and login process.

I know that .NET allows you to dynamically load assemblies - I've had to do a fair bit of that with some projects - but successfully unloading them again, while technically possible, is a bit more challenging. Especially if you've hooked a whole lot of code into them, which you will be doing with a Jiwa plugin.

I do some work with a product built on top of Microsoft's "Windows WorkFlow Foundation" which, like Jiwa, has its own code editor that allows you to write custom "Activities" in C# - it allows you to write and compile the code *once* before requiring that you restart the program after any future changes...

[Mike.Sheen]

I know that .NET allows you to dynamically load assemblies - I've had to do a fair bit of that with some projects - but successfully unloading them again, while technically possible, is a bit more challenging. Especially if you've hooked a whole lot of code into them, which you will be doing with a Jiwa plugin..

When plugins were early in development, the first thing we recognised was that we'd all want to be able to edit a plugin and not have the invasive process of exiting the process and starting up again.

So, we added the Isolate option to the plugins (the little checkbox on the top right of the plugin maintenance form). The Isolate option is for isolating the plugin into its own application domain. Application domains can be unloaded - so by checking that box, the plugin is loaded into its own application domain, and when modified that domain is unloaded and re-loaded after compilation.

Before anyone gets too excited, there are serious limitations to this which has led to us not using it ourselves. The main limitation is you can't interact with an object in another application domain. What that means is your plugin can't listen to events of say the Sales order business logic that was loaded inside the main Jiwa application - and it can't manipulate forms loaded in another application domain. We experimented with some ways around that - which is why the interface classes of plugins all inherit from MarshalByRefObject - that DOES allow you to have your classes reachable by another application domain - that was required by the Jiwa plugin framework to be able to invoke the plugin classes when isolated to their own application domain.

But, having a plugin which is isolated that couldn't interact with the Jiwa process (when I say Jiwa process it's any process which instantiates a JiwaApplication.Manager) wasn't much use, so we generally don't use it for plugins ourselves.

.NET Core 3, .NET 5 onwards allow you to unload assemblies at runtime - so if we could move to .NET 6 (or 7) that would allow us to have edit-and-continue plugins. We added DEV-9429 to look into this. We're only held back by a 3rd party component - Crystal Reports - that has no plans to support .NET 6 or later. Other 3rd party components - Infragistics, Farpoint Spread, Actipro Syntax Editor - all support .NET 6 Winforms.

DEV-9429 is looking into ways we can put the Crystal Reports generator and viewer into a separate process that we could invoke from the Jiwa process which would work around this problem.

[Mike.Sheen]

Actually this is inconvenient in general is there any way to have a changed or newly imported plugin reloaded without the whole logout and login process.

Well, yes - as I said anything loaded into an application domain cannot be unloaded, but you can unload the application domain - which is what the Isolated checkbox on plugin maintenance does - it makes each plugin it's own application domain and when you modify an isolated plugin when you compile it (which is performed automatically on save) it first unloads the application domain, then compiles and then loads the newly compiled plugin into a new application domain.

[SBarnes]

What restriction if any does isolation introduce for instance I think when I tried it before you can get issues with trying to interact with user interface controls?

[Mike.Sheen]

What restriction if any does isolation introduce for instance I think when I tried it before you can get issues with trying to interact with user interface controls?

Not just controls, if my memory serves me correctly - as per my previous post:

Before anyone gets too excited, there are serious limitations to this which has led to us not using it ourselves. The main limitation is you can't interact with an object in another application domain. What that means is your plugin can't listen to events of say the Sales order business logic that was loaded inside the main Jiwa application - and it can't manipulate forms loaded in another application domain. We experimented with some ways around that - which is why the interface classes of plugins all inherit from MarshalByRefObject - that DOES allow you to have your classes reachable by another application domain - that was required by the Jiwa plugin framework to be able to invoke the plugin classes when isolated to their own application domain.

Keep in mind it was around 10 years ago I last was working on unloading plugins - so there may have been improvements since then, but that's unlikely given one of the benefits of moving to .NET 5 or later is the ability to unload an assembly - if that was there in .NET Framework it wouldn't be considered a benefit.

I recall looking at MEF, which as Ryan pointed out does allow unloading of dynamically loaded code, but as I recall that too relied on application domains.

And I also recall there was a very good reason for us not making all our classes inherit from MarshalByRef to make them immediately accessible across app domains... I just don't remember what it was. I'm betting adding that as an experiment would yield the reason pretty quickly - if you're bored and want to find out.