Debugging example plugins

1

Hi everybody

How to debug a plugin - I have ran Example Plugin from both within the repository and in the download (in debug)everything runs in the Editor but the break point is not hit. The .pdb file and .dll are in the C:\Program Files\OpenTAP\Packages\SDK\Examples\bin\Debug\

As I understand it the Editor will run in above folder so should find the .pdb ?

Is there additional steps or file moving that needs doing ?

Where should we create our custom plugins ? in Packages or the opentap folder ?
Many regards Andy

1 Like
2

Hi Andy,

This depends a bit on how you attach the debugger. Which .sln file do you load to do this?

3

Hi Rolf
Iā€™m opening Examples.sln in C:\Program Files\OpenTAP\Packages\SDK\Examples

Thanks Andy

4

I hit same issue, any solution for this issue?

5

Hi Ronghuaw,
No unfortunately - Iā€™m not sure if Keysight are using everything in Linux , Iā€™ve abandoned Opentap for now and written my own app as we only have a couple products and only me as test/production engineer so not at the enterprise level yet :grinning:

regards Andy

6

I can verify that everything should work on Windows. That is still our main platform.

But in any case, debugging should work.

Which kinds of development environments are you using?

8

Hi Andy,

Thank you. Iā€™m sorry to hear you abandoned OpenTAP, framework always a good fridend to ease your life :grinning:

regards Ronghuaw.

9

Visual Studio 2019, everything works fine except i canā€™t debug when open Examples.sln in C:\Program Files\OpenTAP\Packages\SDK\Exaamples (follow the youtube training video). thanks.

10

I found the issue.

Since the TargetFramework is netstandard2.0 in the Directory.Build.props file, Visual Studio thinks it should debug the process with the .net6/netcore debugger. This is not the case, because Editor.exe is a .net framework executable.

To fix this, change
<TargetFramework>netstandard2.0</TargetFramework>

To

<TargetFramework>net480</TargetFramework>

in Directory.Build.props.

6 Likes
11

Thanks rolf, i can debug now, does that mean if you like to create the custom plugin and like to debug, only can use the .net framework instead of .net core?

1 Like
12

Thatā€™s a Christmas :star: for Elf Rolf - Maybe Iā€™ll have another look at OpenTap in the new year :grinning:

1 Like
13

@ronghuaw, thatā€™s right. If youā€™re using Visual Studio to debug your custom plugin, youā€™ll need to target the .NET Framework in order for debugging to work. However, even if youā€™re using the .NET Framework for debugging purposes, your project will still work on .NET Core. So you can use either .NET Framework or .NET Core for your project, but you may need to use the .NET Framework for debugging purposes if youā€™re using Visual Studio.

Thanks @andy1, your always welcome :star:

1 Like
14

Thanks rolf, itā€™s more clear now for the custom plugin debug.

1 Like
15

Examples debugging seemed to work fine in VS2019 but caused problems in VS2022. All projects needed switching to .NET Framework. Probably because of the update to .net6 as @rolf_madsen points out. Is there a way to switch debuggers instead of changing TargetFrameworks?

16

There is a workaround. You can have an extra project called e.g MyProject.Debug. And that can target .net framework,while everything else targets .netstandard. So when you click F5 and Myproject.Debug is selected it starts the right debugger and everything works as expected.

1 Like
18

I ran into the same problem today creating an OpenTAP plugin from scratch targeting netstandard2.0 and using the OpenTAP Nuget package along with TUI to debug. I wanted to say thank you for helping me understand the problem and also share a slightly different workaround I decided to use instead of a dummy project.

First, I created a new configuration called DebugPlugin, then added a conditional PropertyGroup to the CSPROJ file and included TUI as an additional OpenTAP package:

  <PropertyGroup Condition="'$(Configuration)'=='DebugPlugin'">
    <TargetFramework>net48</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="OpenTAP" Version="9.20.4" />
    <AdditionalOpenTapPackage Include="TUI" />
  </ItemGroup>

Along with the following launchSettings.json:

{
  "profiles": {
    "Run with TUI": {
      "commandName": "Executable",
      "executablePath": ".\\tap.exe",
      "commandLineArgs": "tui"
    }
  }
}

Now with the DebugPlugin configuration selected and my plugin set as the startup project, I can use F5 to launch a debugging session using TUI that will hit breakpoints properly.

1 Like
19

Hi @Jim_B,

You can do that too. You risk issues on other platforms (e.g Linux) if you build against ā€œ.NET Frameworkā€, but if that is not a big concern for you, then I think your solution is fine.

Otherwise, if you want cross platform projects that are also debuggable (in VS), then I suggest to add a separate ā€˜debugā€™ project which is built against .net framework. Also if you want to build on Linux (more stableand cheaper)

1 Like
20

Iā€™ve just hit this issue with a project that has been debugging as expected for some time. Suddenly Iā€™m getting a warning that the breakpoint wonā€™t be hit because the symbols arenā€™t loaded.

The only thing I think has changed on my system is I installed the .net 8 sdk earlier this month. Could this have messed something up?

Project file looks like this.

  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <LangVersion>9.0</LangVersion>
    <Configurations>Debug;Release;Remote_FTest</Configurations>
  </PropertyGroup>
  
  <PropertyGroup Condition="'$(Configuration)'=='Debug' Or '$(Configuration)'=='Remote_FTest'">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
  </PropertyGroup>
21

Hi @benstreek,

Did you check if your are debugging a release build?

Otherwise, maybe you have a duplicate DLL in your output folder. For example if you build A.dll, but there is also a file called A.dll in a subfolder, that can be confusing to the debugger too.

22

Hi @rolf_madsen,
Thanks for the suggestions - thankfully it just fixed itself the next day. No idea what happened.

1 Like