topic Re: With .NET Core? in Measurement Studio for .NET Languages

With .NET Core?

Floyd_Prowave — Tue, 04 Jun 2019 09:33:24 GMT

In Microsoft's Build 2019, it said .NET Core is the future. So Measurement Studio will move to .NET Core or can be used in .NET Core?

Re: With .NET Core?

testergi — Wed, 04 Mar 2020 10:54:11 GMT

I would also like to see a roadmap on support for .NET Core as it is the future of .NET along with new C#/VB language support. Any insight from NI teams would be great. Thx

Re: With .NET Core?

Chris.Dickerson — Mon, 30 Mar 2020 01:06:06 GMT

DAQ works for me in .NET Core 3.1, but when I try to use TDMS, the NationalInstruments.Common
assembly blows up.

Portability Analyzer shows a few unsupported methods:

T:System.Web.HttpRequest

M:System.Web.HttpRequest.get_IsLocal

T:System.Web.HttpContext

M:System.Web.HttpContext.get_Current

M:System.Web.HttpContext.get_Request

T:System.Web.HttpRuntime

M:System.Web.HttpRuntime.get_BinDirectory

Otherwise it's flagged as 99.45% compatible (except when you do new TdmsFile()).

Re: With .NET Core?

testergi — Mon, 30 Mar 2020 09:52:00 GMT

@Chris.Dickerson Thanks. This gives me a few ideas to try. Hopefully NI can address the few areas you mentioned.

Re: With .NET Core?

testergi — Mon, 06 Apr 2020 10:55:06 GMT

I tried the .NET Portable Analyzer against NationalInstruments.DAQmx DLL and found the following:

Target typeTarget memberHeader for assembly name entries.NET Core + Platform Extensions.NET Core.NET Standard + Platform ExtensionsRecommended changes

T:Microsoft.VisualC.MiscellaneousBitsAttribute	T:Microsoft.VisualC.MiscellaneousBitsAttribute	NationalInstruments.DAQmx	Not supported	Not supported	Not supported
T:Microsoft.VisualC.MiscellaneousBitsAttribute	M:Microsoft.VisualC.MiscellaneousBitsAttribute.#ctor(System.Int32)	NationalInstruments.DAQmx	Not supported	Not supported	Not supported
T:Microsoft.VisualC.DebugInfoInPDBAttribute	T:Microsoft.VisualC.DebugInfoInPDBAttribute	NationalInstruments.DAQmx	Not supported	Not supported	Not supported
T:Microsoft.VisualC.DebugInfoInPDBAttribute	M:Microsoft.VisualC.DebugInfoInPDBAttribute.#ctor	NationalInstruments.DAQmx	Not supported	Not supported	Not supported
T:Microsoft.VisualC.DecoratedNameAttribute	T:Microsoft.VisualC.DecoratedNameAttribute	NationalInstruments.DAQmx	Not supported	Not supported	Not supported
T:Microsoft.VisualC.DecoratedNameAttribute	M:Microsoft.VisualC.DecoratedNameAttribute.#ctor(System.String)	NationalInstruments.DAQmx	Not supported	Not supported	Not supported
T:System.Runtime.InteropServices.Marshal	M:System.Runtime.InteropServices.Marshal.GetExceptionPointers	NationalInstruments.DAQmx	Supported: 3.0+	Supported: 3.0+	Not supported

Re: With .NET Core?

David_Jackson — Tue, 07 Apr 2020 21:03:37 GMT

I made an inquiry yesterday about this via our support channels. This is the reply I got from NI:

"Measurement Studio 2019 is not expected to work with .NET Core. NI is currently investigating the best way to support .NET Core across our platform since this impacts more than just MStudio (Drivers, TestStand, etc..). We're working closely with Microsoft and the IVI foundation to ensure we take an approach that considers the long-term health of our products and also compatibility with existing systems. We do not have a detailed roadmap to share at this time."

There is much more at stake here than just Measurement Studio. We also use IVI drivers and TestStand heavily in our automation systems. I could not find anything on the IVI website regarding plans to support .NET Core. I tried calling a .NET core module from TestStand 2019 but this would not load (could not load file or assembly System.Runtime Version 4.2.0.0) so assume TestStand 2019 does not currently support .NET core either).

So for now we will be stuck at .NET 4.8 whilst the rest of the world move on with ,NET 5.0 (in effect .NET core) from November 2020. I would like to see some sort of road map from NI sooner, rather then later so that we can plan the migration of our test systems.

Re: With .NET Core?

testergi — Tue, 30 Jun 2020 01:46:05 GMT

Wanted to chime in again on this hoping the NI support channels are listening. Understanding this is a complicated topic as it touches various software/products, it would be very helpful if a roadmap would be provided (even if a ways out).

NI recently rebranded and said they going to be transformative, innovative, and focus on customers. Any updates on future .NET support will be appreciated.

Re: With .NET Core?

Yltsä — Wed, 26 Aug 2020 08:45:35 GMT

HI, Measurement Studio is missing from NI's software products in the new web site.. Hopefully NI does not stop developing Measurement Studio.. But it is little silent here.

Re: With .NET Core?

Konan__ — Wed, 02 Sep 2020 07:23:05 GMT

So for now we will be stuck at .NET 4.8 whilst the rest of the world move on with ,NET 5.0 (in effect .NET core) from November 2020. I would like to see some sort of road map from NI sooner, rather then later so that we can plan the migration of our test systems..

.NET CORE is NOT an evolution of .NET Framework.

In fact it was called originally ".NET 5.0" which was a failure in marketing, because people thought that 4.8 --> 5.0 , which was STRAIGHT UP FALSE.

.NET CORE is a DIFFERENT framework, born for different reasons.

For 99% of users here, .NET CORE is basically irrelevant, and its advantages has nothing to deal with testing and production.

Re: With .NET Core?

David_Jackson — Wed, 02 Sep 2020 21:57:00 GMT

I understand that .NET core is a different beast built primarily to support cross-platform deployment. It was first introduced a few years ago and has been developed side-by side with .NET framework, as the functionality available within the current .NET framework was added to .NET core. Microsoft have indicated that .NET 5.0 will essentially be .NET core technologies and that what we know as the .NET framework will be stalled at release .NET 4.8. In that sense it is an "evolution" to a new programming paradigm (not in the technical sense).

Yes, for 99% of current test and measurement users .NET core is irrelevant now. We also have concluded that we can continue using .NET 4.8 for the foreseeable future (it will remain supported, just not further developed). However, I know the time will come when that will end and we will need to migrate to the new technology. Therefore this question was seeking direction from NI on a roadmap for supporting .NET core technologies into the future.

Re: With .NET Core?

Thacai — Fri, 23 Oct 2020 10:40:24 GMT

Would just like to chip in and say just because .NET Core can do cross platform, doesn't mean all driver and tooling needs to support all platforms... a .NET Core project can example easily be build against Windows runtime only.

That said it would be nice to example be able to use Measurement Studio, and DAQmx drivers from more lightweight devices for Industrial IoT scenarious.

We're also example using Teststand(for now...) on production line, at the moment, using custom result recording to Azure Cloud for data analysis etc, and there we're using Microsofts .NET dll's, and that works fine since they support .NET 4.5+ but at some point newer versions of those dll's will only be for .NET Core.

Re: With .NET Core?

Chris.Dickerson — Sun, 25 Apr 2021 14:38:06 GMT

.NET Core leaves the runtime to be updated via Windows Update, and the version your application uses ships with your application. That's alot better for maintenance and easier for the customer when they don't have to install a new version of the framework when you compile against a newer version.

It also has alot better support for databases, command line interface generation of entity framework models (scaffolding) -- the dialog they had for years to do this was extremely buggy and sometimes would error out and you couldn't generate anything but errors.

Project files -- the new SDK version of the project file is SO much cleaner and clearer than it's been. Doing a diff you can clearly tell what changes have been made.

Sqlite and JSON support...

Re: With .NET Core?

testergi — Mon, 26 Apr 2021 11:07:08 GMT

I've recently had success using the NI APIs with .NET 5 (Core) libraries/apps. However, I have not been able to reference/call them within TestStand. For example, you can see the classes/methods when trying to use within the Sequence Analyzer config.

Re: With .NET Core?

Thacai — Mon, 26 Apr 2021 11:32:34 GMT

That's kind of the whole issue.

Dotnet core (soon to be dotnet 5) can easily run most "legacy dll's" such as the teststand api ones, aslong as the compile target is set to windows, it's the other way that's the major issue: that none of NI's tools currently support dotnet core, and no clear plan other than a very vague answer in another topic that they are working with microsoft on it (Re: .NET Core Support - NI Community), which i see you commented on aswell 🙂

Hell even if they opened up their software a bit more, i'm sure the community(or NI partners) would be able to make an "adapter" for any language, took years for python support in teststand as an example.

Re: With .NET Core?

testergi — Mon, 26 Apr 2021 11:39:32 GMT

"That's kind of the whole issue." Yup, completely agree. There have been many times we started down the .NET Core path, but had to move back to "full framework" due to these limitation. Maybe one day 😀.

Re: With .NET Core?

Christ0phe — Fri, 08 Apr 2022 13:20:17 GMT

… one year after… is there something new in this arena ? What are the plans at N.I. to support .Net Core modules?

Thanks to anyone having more news on this.
Christophe

Re: With .NET Core?

Chris.Dickerson — Tue, 05 Jul 2022 10:58:20 GMT

DLL: c:\windows\system32\nicaiu.dll

Link: https://www.ni.com/en-us/support/documentation/supplemental/21/using-ni-daqmx-in-text-based-programming-environments.html

header file: C:\Program Files (x86)\National Instruments\NI-DAQ\DAQmx ANSI C Dev\include\NIDAQmx.h
documentation: C:\Program Files (x86)\National Instruments\NI-DAQ\Docs\cdaqmx.chm

Measurement Studio assemblies aren't compatible with .NET core and beyond, so I started making my own wrappers around NI DLL's.

So far the only problem I've found, is that the DLL reads as 64 bit, but will only work for C# if you compile as x86 (even though the driver is listed as 32 and 64 bit - https://www.ni.com/en-us/support/downloads/drivers/download.ni-daqmx.html#445931). Which is also the same experience you get with Measurement Studio .NET assemblies.

Dump of file c:\windows\system32\nicaiu.dll

8664 machine (x64)

Dump of file c:\windows\SysWOW64\nicaiu.dll

14C machine (x86)

Re: With .NET Core?

dotNet_to_LabW — Tue, 25 Jun 2024 10:10:31 GMT

Measurement Studio isn't compatible with Visual Studio 2022 - Is difficult to keep using VS2019 especially when .NET 5.0 is outdated

Measurement Studio isn't compatible with .NET 5.0 but uses old Framework 4.8

Anyways, according to NI, it isn't required to install MS in order to speak with Daqmx cards, so I install all libs and tried to refer those in my project - as expected, it wasn't possible.

I then copied files manually and tried to refer as assembly, again incompatibility issue

I am unable to integrate DaqMx to Core or .NET 6.0. Not only this, I am unable to interface Daqmx.dll in my 6.0 project.

What is the solution you can suggest? We have heavy dependence on NI USB Cards and can not stick to old and outdated Visual Studio / Framework

Re: With .NET Core?

rolfk — Tue, 02 Jul 2024 08:05:44 GMT

There have been several attempts to create a .Net Interop layer for DAQmx and other NI drivers that calls the NI DLL directly. Some have even published their (partial) work on git and other platforms. It's not rocket science to do an Interop interface, just a damn lot of work, since the DAQmx API is huge!

Re: With .NET Core?

dotNet_to_LabW — Thu, 04 Jul 2024 08:37:12 GMT

Yes, I have seen such projects.

- I was also thinking of integrating my old application dll (which I wrote in 4.8 and refers to DaQmx dlls) into my core project by making DllImport calls.

- but that kills my flexibility, as I have to keep on maintaining my old 4.8 project for every small change which is needed in new project.

- Or another approach is to use DllImport directly with DaQmx, but that's a lot of work because all classes and structs have to be reflected in my new core project too.