NI TestStand Idea Exchange

About NI TestStand Idea Exchange

Do you have a feature idea for how to improve NI TestStand? Submit and vote on ideas now!

  1. Browse by label or search in the TestStand Idea Exchange to see if your idea has previously been submitted. If your idea exists sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea. Be sure to submit a separate post for each idea. Note: the TestStand Idea Exchange is not the appropriate forum to submit technical support questions.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see implemented!

The TestStand R&D team is committed to reviewing every idea submitted via the TestStand Idea Exchange. However, we cannot guarantee the implementation of any TestStand Idea Exchange submission until further documented.

Showing results for 
Search instead for 
Did you mean: 

Add support to call modules built with .NET Core

Status: New

Microsoft have stated that all future development in .NET will be based on .NET Core, a cross platform development framework.  Therefore the current version of the .NET framework (version 4.8) is the last built on existing .NET technologies, with the next version .NET 5.0 to be built on .NET Core technologies. 


Could an adapter that supports calling .NET Core modules be added into TestStand so that users of TestStand calling .NET modules can migrate to .NET Core?

Active Participant

So this is certainly something we're aware of and are considering the different paths we could take. Quick question: What do you value more - compatibility with existing assemblies, or support for .NET Core?


If you could get support for .NET Core in TestStand sooner but you lose the ability to load existing assemblies that are not Core compatible, is that a trade-off that you're comfortable with? Any systems that use functionality not yet available in Core would need to be modified, or stay on an older version of TestStand.




If it were a one, or the other scenario then we would have to update all .NET modules that we call from TestStand before we could use the new version.  We have very many modules, that in turn rely on other 3rd party drivers (mostly IVI drivers) for which I have not yet seen a migration plan, so that concerns me.  So until I hear what IVI are doing then I think I would opt for the "play it safe" option and delay until both adapters could be supported, particularly as I do have some .NET modules without reliance on third party assembles that I could update to .NET core right away.


If IVI come up with a plan that allows me to migrate my .NET instrument drivers to .NET core then I would change my mind and opt for the faster .NET core only option.