Run and Debug Opentap with .NET 6.0


is it possible to run and debug OpenTap in .Net 6.0?

I already have read several stuff about this topic but couldn’t really find a final solution.

This is my Situation:

There is a “Visual Studio SDK CE”. Unfortunately this SDK is only visible in VS2019 and the target framework is 4.7.2. I would like to work with VS2022 and .NET 6.0

This is what I have done:


I created a general project and added the OpenTap-Packages.


The target framework is .NET 6.0.

I added a simple test like the existing test templates from VS2019.

I also added Debug-Breakpoints.

In the csproj-file I added a new ItemGroup with the entry (just copied the lines from the VS2019 template).

Here I am not sure which version of “Developer’s System CE” to use? I heard the CE and Commercial version differ.

This is what happens:

The test runs but there is no hit of the Debug-Breakpoint.


What am I doing wrong?

Is there a working solution for .NET 6.0 and debugging?

Thanks for any help!

Kind Regards

Hi @busn_bach,

.NET 6 is not supported on OpenTAP on Windows. Editor.exe is a .net framework application and Visual Studio will just get confused if you try to debug a .NET Framework application in a .NET 6 context, causing the behavior you see.

.NET 6 is only supported on linux for now.

Is there any specific reason why you need to develop for .NET 6?

Hello rolf_madsen,

thanks for the quick answer!

In fact, I just would like to use .NET 6.0 because of LTS (long term support) reasons.

If I would start today a big new project, I would choose.NET 6.0. Not because I think of porting my solution someday to Linux or something else, just because of having the newest version of .NET (Core) and all the following updates.

You gave me one good point. The Editor is a .NET Framework application. I always used the Editor just because this is the standard setting. I think there is also the possibility to run the tests without the Editor (via cmd). Would that be a working possibility? Or did I miss anything?

Kind Regards

Ok, I get that.

We recommend targeting .netstandard2.0 for your plugins. That way they will work in both .net framework on Windows and .net 6 on Linux.

tap.exe on Windows is also .net framework, but you can run the test plan using the command line if you want. I strongly suggest you to try it. Just do “tap run path-to-testplan” in your terminal.

You can also try out Editor X and TUI if you want to try UIs that works on Linux or Mac.

Thanks again for the details!

I am focusing Windows only. Somehow I thought the tap.exe is .NET6.0, but that was my misunderstanding.

What I did is what you mentioned to try the .NETStandard. I did that in the same way like before, the test runs but there is an additional info in the log. The Breakpoints don’t hit.

I can build with .NETStandard 2.1, but with .NETStandard 2.0 I get an error message in VS2022:

My question:

  • Shouldn’t the Breakpoint be triggered in this case?
  • Where comes the .NET Standard mismatch from?

Kind Regards

Ok, so I don’t use Visual Studio (Rider does not have this problem). As I remember it, when you debug a .netstandard project it assumes that you want to debug a .net 6 project if you have that sdk installed.

To fix it, you can either target net462 in your debug builds or create a separate project called MyProject.Debug as a .net462 project that is the one you always debug.

You should not target .netstandard2.1, it is not compatible with .net framework. Maybe you are using some feature that is not available in .netstandard? Anyway, I am not sure… maybe selecting a newer language version will work.

  • Where comes the .NET Standard mismatch from?

It’s as the warning says, you have the nullable property set on your project but this is not valid for C# 7.3, which is the default for .NET Standard 2.0.

You have two options:

  1. Remove the nullable property from your project and do not use nullable annotations.
  2. If you want to keep the nullable feature enabled, add the LangVersion property and set it to 8.0 or higher, or to “latest”.

If you choose to keep nullable enabled then you can optionally also use the Nullable package to add better support for nullability attributes and better static analysis results.