How to debug modified OpenTAP code with custom plugins

Ecosystem
#1

I’d like to understand the recommended process for modifying OpenTAP source code, and debugging (stepping through) the modified code, while also using my custom plugins.

I have a KS8400A license for the TAP Editor. I’ve cloned the OpenTAP repository, made a modification, and ran a successful build.

Upon building the OpenTAP solution, I see the binaries do not go to the %TAP_PATH& directory. And running the solution brings up the Community Edition Editor. So the freshly built OpenTAP binaries are not living with my plugin binaries. Manually copying the binaries works, but is cumbersome.

What is the recommended method for debugging OpenTAP modifications with my own plugins?

#2

For the OpenTAP project, it builds into bin\Debug of the directory you have the repo mapped to. So, probably the easiest way would be to add a Post Build Event to the Tap.Engine project to copy the OpenTAP.dll:

copy /Y "$(OutputDir)Opentap.dll" "$(TAP_PATH)Opentap.dll"

Alternatively, you could create a test project that installed your plugins into the bin\Debug directory.

1 Like
#3

In the scenario where I’m modifying OpenTAP code, I most likely want to step through the OpenTAP code. So it sounds like I need all my plugin binaries copied to OpenTAP’s bin\Debug directory. There are many of them, sometimes across multiple solutions. Can you expand on what you mean by a test project?

Maybe another alternative is to change the output folder in the OpenTAP solution to %TAP_PATH%.

1 Like
#4

You could use the same xcooy process to also copy the pdb file generated. That should be all you need.

I didn’t want to recommend making %TAP_PATH% your default output directory as that will become difficult to clean up when you no longer want the debug build.

To avoid that you could either output to a specific directory rather than the root directory (just be careful as you may end up with duplicate DLLs) or you can clone your entire %TAP_PATH% directory and create a “Test Automation Debug” directory and update the Tap.Engine project to output there.
That would

  1. Clone all your plugins in an easy way
  2. Keep the debug files separate from your install.
1 Like
#5

This is a noob .NET question, but how does the pdb file help me in this scenario?

1 Like
#6

Basically, it is what allows to link to a debugger, but here is a more detailed description:

2 Likes
#7

Very cool, I’ve confirmed I can break on exceptions in opentap source code by including the pdb file along with the binaries.

2 Likes
#8

Great! Given you had some issues with this, it may be worth submitting an issue in Gitlab to improve the documentation around this.

2 Likes