NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Any plans for .NET CoreCLR/CoreFX?

Solved!
Go to solution

Any plans/timelines for .NET CoreCLR and CoreFX on LinuxRT?

0 Kudos
Message 1 of 4
(4,649 Views)
Solution
Accepted by topic author wirebirdlabs

I added it to our internal tracker for package requests. Can you elaborate more on the details of your use case? Is this a nice to have (because you'd prefer to program with .NET), or is there a .NET-based toolkit in your application or some similar hard requirement?

0 Kudos
Message 2 of 4
(3,024 Views)

I develop libraries and applications in cross-platform C89 that use exported functions in `extcode.h` to interface with LabVIEW.

Microsoft has become pretty totally rad in the past 13mo releasing lots and lots of open-source and cross-platform libraries and tools. C# is really a great language, and now it is natively supported on all the targets that we as NI customers are already using (minus FPGA, but I don't see an immediate desire or even technical path to achieve that!).

The FFI with Call Library Function Nodes and `extcode.h` is ... a tricky beast. And `autotools` is even worse than a pizza burn on the roof of your mouth. C89 is cool, but pretty unproductive when you're used to working in higher-level languages like LabVIEW.

On the bright side, the FFI with .NET (on Windows targets) is awesome in LabVIEW! It has some deficiencies, but overall it's far more powerful than the CLFN and exported functions from LVRTE.

So I guess this is really a two-stage question -- 1) just compiling CoreCLR/CoreFX for the LinuxRT RIO platforms to get it capable of running a C# application, but the next (probably bigger) request is 2) for the .NET FFI and related nodes in LabVIEW to work on RT.

The goal is not to replace any part of the LabVIEW RT execution engine with CoreCLR, but rather, to enable it to interact with the CoreCLR execution engine using .NET nodes.

The two end goals then would be 1) enabling a new host of libraries/abilities to be available to applications written in LabVIEW, and 2) ease the burden of library developers by perhaps providing C# as a replacement to C89 for cross-platform library development.

0 Kudos
Message 3 of 4
(3,024 Views)

Currently .NET is supported only on windows desktop. We are looking at supporting it on multiple targets. However, it is not one of our high priority requests at the moment. It requires support to be added within LabVIEW to execute on non-windows platform and will definitely be more than just bundling .NET on platforms other than windows. This is mainly because of the different profiles and missing features like AppDomains in the Core profile. Your suggestions will help us prioritize better. Thank you.

Message 4 of 4
(3,024 Views)