.NET Core Support

[Anand_Jain]

Hi, 

Yes, we are working on it. A future release of TestStand will support .NET 8.

Regards, 

Anand Jain

NI

[testergi]

@Anand_Jain.  That is good news.  Thanks for the update.

[David_Jackson]

I received this update following the recent NI Connect event, so am assuming that this information was provided there.  Looks like TestStand support for .NET 8 is coming later in 2024/2025.  However, there are other things on my wish list there, such as support for Git.  It is encouraging to see NI looking to provide more cross platform support in the future.  The stumbling block for us is the lack of IVI Shared library support for .NET 8.  I have an outstanding question with the IVI foundation as to whether this is on their roadmap.

Regards,

David

[maxmont]

Hi all,

I see "Modern Operator Interface" in the road map. Does someone know what it is?

Does it WPF interface connected to RPC server?

Because I'm developing a new OI interface (with legacy API). Maybe, I should wait for that ...

[jungledede]

Do we have a date for the release, or better, do we have somewhere a preview/rc/beta version?

[crossrulz]

Considering all the talk about LabVIEW 2024Q3, I would expect a release in quarter 3, which starts in 5 days (July, August, September).  This is my personal speculation.

[BapiM · Accepted solution]

All,

TestStand 2024 Q4 release has support for executing .NET 8.0 assemblies through the TestStand .Net adapter.

Refer to the list on features and improvements that are part of the TestStand 2024 Q4 release using the below link:

https://www.ni.com/docs/en-US/bundle/teststand/page/teststand-new-features-and-changes.html

[NME]

The support for .NET8 is great - and my group will have some welcome work in front of us in finally being able to migrate away from .NET Framework 4.8 - but it appears that compatibility with Framework has basically been broken in the meantime. In addition to other apparent compatibility issues, I am unable to step into .NET Framework assemblies (using Visual Studio 2022).

I have been looking in the adapter options for a way to select between Framework and .NET8 but am not finding it. Would it be possible to provide such an option, at least until the TestStand UI model moves away from ActiveX?

We have a large codebase which we're looking forward to migrating, but it's not a simple effort and will take time. I'd like to be able to keep my install base on the current release of TestStand as we perform the migration, but lacking support for .NET Framework I won't be able to do that.

Thanks for your consideration!

[NME]

Wish I would have seen @David_Jackson's post sooner! - thanks for the kudos by the way, it led me here:

https://forums.ni.com/t5/NI-TestStand-Idea-Exchange/Add-support-to-call-modules-built-with-NET-Core/...

Looks like we're in the same boat - right down to the WCF dependency 🤣

It sounds like maybe in both our cases we wouldn't need to be able to call both .NET8 and Framework steps within a given execution, so probably don't need separate adapters for both. Rather if the .NET Adapter Configuration (or something similar that can be configured per execution) had a selection for one or the other that would apply to the current execution, then we could update our test programs as time/resources permit - some test programs could stay on Framework while others get migrated.

[HarshaBhushan]

You should be able to call into .NET framework assembles unless you are using those specified by Microsoft as not available in .NET core. (refer here). Please do check it out and let us know.

We did consider alternatives like providing separate adapters, providing an ability to select a .NET version etc. However we dropped them after the cons (related to performance, feasibility & stability) of those interim approaches outweighed the pros.

We do acknowledge that there would be a transition time to migrate your assemblies to .NET core. Using TestStand 2023 till your migration is complete could be a middle path. Our lifecycle policy is to support 5 latest versions of our software.