What target framework should I look at using if I’m developing a plugin?
And would a different target framework be more suitable for different uses?
@jason.hicks I’m assuming you mean .NET Framework vs .NET Standard here correct?
We do have plugin templates for both. In general, I would default to the netstandard template. This is the easiest to use and uses the OpenTAP Nuget package (https://gitlab.com/OpenTAP/opentap/-/blob/release9x/doc/Developer%20Guide/Getting%20Started%20in%20Visual%20Studio/Readme.md#nuget-package) by default. It also does some nicer things like compiles to a bin directory vs your install directory, so you can keep debug and install separate. Obviously, these will also be able to work cross platform if you wanted.
The .NET Framework template should be used if you will have any WPF or WinForms UI dependencies in your plugin (Dockable Panel, custom components, etc.).
This is really a .NET limitation for now, but once .NET 5 comes out (when Microsoft plans to merge .NET Core and .NET Framework) we may be able to merge to a single template as well.
2 Likes
@brennen_direnzo Cheers man!
2 Likes
So is there a roadmap/schedule for .NET 5 support?
2 Likes
Not yet from an OpenTAP perspective. .NET 5 is not yet officially released yet even. It’s planned for Nov this year though. And seems to still be on track. They released an RC 2 last week.
From there, it will likely be community driven. We haven’t seen a large push for cross platform support, but it has been increasing.
I’m interested to hear if better support there would be valuable to anyone in the community, of it most people are Windows based and plan to stay that way.
1 Like
.NET 5 will be introduced at the .NET Conference Nov 10.
As I see it, .NET 5 together with other parts depending on it like WinUI 3, will set a milestone in SW dev.
I’m very much waiting for it to implement my Operator GUI/Test exec based upon OpenTAP.
So, yes please!
2 Likes
@brennen_direnzo I 've been wondering whether I should be migrating my plugins from .NET Framework to .NET Standard, and you just answered my question. We utilize wpf for several custom IControlProvider UI elements. Sounds like I need to stay on .NET Framework.
2 Likes
Ya, it sounds like it would probably be best to stay on .NET Framework in your case. That said, you may want to consider still moving to the OpenTAP Nuget package. This can be done independently of netstandard vs netframework. It helps with some problems I know you have had like putting your debug code in directory different from your install directly, being able to explicitly which TapPackages to use (and therefore which dependencies will be added), as well as being able to build against a different version of OpenTAP than what you have installed.
1 Like
OK, sounds like migrating will be a good thing to do at some point, though something tells me it will be a hairy operation. Thanks for the link.
1 Like
It’s not to bad. You can also reference this plugin here:
But I have created an issue to help improve this with more detailed documentation:
2 Likes
@rolf_madsen or @asger_iversen do we have any thinking around when OpenTAP may look to move to .NET 5? It looks like they adjusted their planning some and .NET 5 does not get deliver on the promise of merging .NET Framework and .NET Core, but that is still the end goal.
1 Like
I’m writing some plugins(without any UI) for OpenTAP. I want to use openTAP just in windows. What type of project should I use for developing plugins?
As proposed in OpenTAP docs, I build a .net standard project. But this .net standard does not support working with serial port.
If OpenTAP completely support plugins which build with .NetFramework, I prefer to use that. Which version of .NETFramework is supported?
How about .Net Core 3.0/3.1 or .Net 5? Does OpenTAP supports plugins built by these frameworks?
1 Like
@teder.ted if you intend to only run on Windows, technically, either will work. However, our plan is ultimately to move to .NET 5 (and 6). So, starting there will make it easier to migrate forward. Especially if you won’t have a UI anyway.
Currently we only support .NET Core 2 and .NET Framework 4.6.2, but as .NET 5 stabilizes we plan to migrate to that. Skipping .NET Core 3.
As for Serial Ports, there is a Nuget Package that works .NET standard: NuGet Gallery | System.IO.Ports 4.4.0-preview2-25405-01. Personally, I have found the Nuget Packages for Serial control work better than the built in Serial.IO.Ports from .NET Framework. I’ve had issues in the past with not being able to update baud rate correctly.
1 Like
As of 9.17 we have officially migrated to .NET 6:
2 Likes