Facing problem when we are using .NET constructor function in LabVIEW RT

[A_LI]

Hi All,

We have an cRIO 9074 RT System which Acquires Data and sends to Host System. We
have implemented HTTP POST Service using an .NET DLL, to post the data to an
server while test is in progress.

But we are facing problem when we are using .NET constructor function in RT and
the error reported as the function not supported in RT.

Can you please suggest us how to get an .NET DLL that works in RT? Or the
process of generation of .NET DLL that can be used in RT.
Any Help is appreciated.

Thanks and Regards,

Ikram

ikramali.m@infodatinc.com

#91-9985631465

[crossrulz]

If you were using one of the newer cRIOs that used the Linux RT, I would tell you to give the .NET for Linux a try (.NET Core).  But the 9074 uses VxWorks, and I do not know of any version of .NET that will work on VxWorks.

You might be able to use the HTTP VIs that are already in LabVIEW to post your data to the server.

[A_LI]

Hi Crossrulz,

Thank you for the quick response.

Yes we are trying to implement web service by using HTTP POST.vi. But the problem is how to construct headers for the post method.

Can u guide through this issue?

Best Regards,

Ikram

ikramali.m@infodatinc.com

#91-9985631465

[rolfk]

---

@crossrulz wrote:

If you were using one of the newer cRIOs that used the Linux RT, I would tell you to give the .NET for Linux a try (.NET Core).  But the 9074 uses VxWorks, and I do not know of any version of .NET that will work on VxWorks.

---

Even on a Linux cRIO this is almost certainly not going to work, since the LabVIEW runtime on non-Windows platforms does not contain any support for .Net (or ActiveX) at all. And even if it did, the chance that it would work with .Net Core is minimal. .Net Core is a nice idea in theory but in practice in my humble opinion mostly a marketing trick from Microsoft to silence the criticism of the Open Source community about .Net. It works if you control at least the .Net Core component compilation and your application, but runs sooner or later into troubles if the .Net Core component and the application that uses it are not managed synchronously. And there goes the idea of having a single standard runtime core that is compatible across platforms that can be used by any numbers of applications simultaneously. And no, it is not in Microsofts interest to solve that problem fully.

.Net is still mainly a technology to get the Windows ecosystem installed on as many devices as possible.

[Albert.lederer · Accepted solution]

This might be a dumb idea, but why don't you just use the built in http client vis?  I've used them on VxWorks and Linux RT systems and they work fine.  Just do a palette for "POST"...

I don't know if you have requirements that prevents you from using these built-in functions, but if you don't, you'd be better of using these than making your own library calls...

<EDIT>

Sorry, I missed the earlier post that suggested this.  Please ignore...