.NET Core Support

[NME]

Thanks for the reply but I'm a bit disappointed and confused.

I manage a test software platform which uses a custom UI built on the simple UI example (\TestStand 2023\UserInterfaces\Simple\CSharp) provided with TestStand. That UI example is based on .NET Framework 4.8 - and this is still true for TestStand 2024.

My UI has migrated easily enough - since there are basically no differences in the simple UI example between TS 2019 and 2024. But it puts me in the position where my platform is forced to contain both .NET8 assemblies (for the TS-callable components called by my process model and utility functions callable by test programs built on my framework) and .NET Framework 4.8 for the user interface. This in turn causes platform incompatibilities between my UI code and other support modules.

I'm trying to figure out how to work around this incompatibility (some form of a remote-procedure-call library built in .NET Standard) - but haven't achieved it yet and not 100% sure it's achievable or worth doing.

Based on your response, it looks like I'll probably stay on TS 2023 until a new TestStand UI model is deployed which gets rid of ActiveX and moves away from .NET Framework. The published roadmap says that's in development for 2025+. Can you provide any insight on how far out the "+" might be?

I'm also curious to know more about the performance trade-offs you mentioned - is this just related to the differences between the .NET frameworks or is there more to it? I think a very large portion of your C# user base (100% of which until now has been on .NET Framework) is going to run into this same migration wall. Microsoft hasn't announced any end of support for .NET Framework on Windows - only that they're not continuing to develop it. Seems like a mistake to just drop support for it.

Thanks again for the discussion.

[David_Jackson]

Hello NME (and other users stuck on TestStand 2023),

Over the past year I have completed some investigations into the migration path from a TestStand 2023 Q4 deployment based on.NET framework modules to TestStand 2024 and later that require .NET modules to be modern .NET compatible.  This is what I have learned from the process.

• If you are able to remove any dependency on .NET framework technologies from your .NET module then it will load.  In my case, replacing my WCF based message application with a gRPC one meant I could call this from TestStand 2025.Where this runs into problems is when you are unable to do so due to dependencies of modules you need. Here are some examples:
• DAQmx dependencies:  NI do not have to my knowledge a modern .NET build of DAQmx.  When you install DAQmx it places dependencies in the GAC.  The GAC does not exist in the world of modern .NET.  A workaround that was successful for me was to find those dependencies and manually copy them from the GAC to the folder where my DAQmx based driver is installed.  It seems it would not be too hard for NI to offer a .NET 8 based DAQmx driver and would make life easier if they did.
• A lot of my instrument drivers communicate via VISA.  Within the last year both NI and Keysight have offered modern .NET  VISA builds that you can install via NuGet. I have managed to update a couple of drivers with these builds and built .NET 8 versions that work from TestStand.
• We also depend on IVI drivers.  In the past year the IVI foundation have released a new modern .NET IVI Shared Components based on the IVI Generation 2026 standard.  These are accessible from the NuGet repo NuGet Gallery | ivifoundation.  It is now up to instrument manufacturers to update their drivers to use these and release modern .NET versions.  Rohde & Schwarz have already begun and they now have some popular instrument drivers available via NuGet.  KeySight advised me that they would start updating their drivers from May 2026, so a bit of a wait there.
• We have one driver that uses NI Measurement Studio analysis libraries and UI components.  i have heard via my NI support contact that NI have no plans to update Measurement Studio to support .NET modern.  So we will be needing to code those out with new modern .NET compatible libraries.  I did consider at one time using a gRRC based client-server arrangement where the sever is the original .NET framework driver and calling this from a modern .NET client (gRPC will support this).  But I'm a little scared of the extra handshaking involved and have not had time anyway.  Has anyone here tried such a wacky idea?

In short, I am confident that there will be an upgrade path, once I have the updated IVI drivers from Keysight that we need and have sorted out the Measurement studio replacement.  There must be a lot of TestStand users like myself that have dependencies on 3rd party drivers (some of which are NI's) who are unable to upgrade.  I do not think that NI thought through the impact on their users of rolling out this upgrade.  As a result, I along with many others cannot utilize the latest enhancements available in later versions of TestStand. 

I hope that this post proves helpful in some way.

David