Add support to call modules built with .NET Core

[David_Jackson]

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?

[WireWeaver]

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.

Thanks,

Trent

[David_Jackson]

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.

Regards,

David

[HarshaBhushan]

TestStand 2024 Q4 allows calling into .NET 8 code modules. Refer here for more details

[David_Jackson]

Yes  HarshaBhusan.  Something that I have been waiting a long time for, but when it arrived it came as a surprise.  I had hoped that the .NET 8 modules would be callable by a new separate adapter to the .NET Framework one, per my preference made in my earlier post in 2020 (see above).  We use TestStand primarily with .NET framework modules but those cannot be called In TestStand 2024 Q4 until they are all updated to support .NET 8.0 (a long and not altogether straight forward task, even with the use of Microsoft's Upgrade assistant). So, we are stuck on TestStand 2023 until we are able to do this.

[HarshaBhushan]

Are you using any .NET framework resources that are not supported in .NET 8? If so which ones?

If you are not, you can still call into .NET framework assemblies.

Having multiple adapters for different .NET versions has a drawback that only one of the CLR can be hosted in-process. Which means there will be difference in performance significantly. Considering that most of the industry is shifting towards .NET core, & the ability to call .NET framework assemblies too (with certain exceptions) we decided not to have multiple adapters.

[David_Jackson]

Yes, I noted that .NET framework resources are supported in the release notes provided that they are not using resources not supported in the .NET 8.  None of our .NET framework modules load and I think our problem is to do with a logging app that is built into all of our .NET instrument drivers and support modules that is build on WCF.  I note that Microsoft have release NuGet packages for WCF core support so will look to migrate that first in the new year and see if re-referencing that in the existing modules will allow the modules to load.  I did update one of these to .NET 8 using the Microsoft.NET upgrade wizard and was able to load that, albeit with other issues related to a 3rd party dependency.

I have not had an opportunity to try out any of the instrument drivers that use NI Visa and IVI components yet.  I hope they are supported on .NET8.