Jump to content

Should I use .net or a custom library

Recommended Posts

Edit: I'm asking primarily if there is a reason why/when I should/shouldn't use .net functions in my LabVIEW development. The example below is just to demonstrate a case of my question.



I recently found a custom library that calculates SHA256 hash algorithms However, in this post I see that the same thing can be done with .net 


My main question is: Is there any reason to build or use a custom library for something where .net functionality already exists? Are there any disadvantages to offloading work to .net ? 

Edited by ATE-ENGE
Link to comment
1 minute ago, ensegre said:

cross-platform, say?

[never used that particular library, anyway]

From what I understand, .net would be as equally cross-platform as making a library.


My question is a general "Is there any reason not to use .net for things?" as opposed to it being specific to this library. (I'll edit the question to make that more clear)

Link to comment

Think 32 bit vs 64 bit.

.net will always use the correct architecture. Custom library that has been developed externally, can create a security breach as well.... .dll .ocx....

Native .net that you code yourself would be must trustworthy. But be aware that you need to make sure that the .net version used will always be compatible with the latest .net updates... sometimes it creates issues. this is likely less possible with external code if they are not relying on interpreter (java .net C++ or python.)

Another case would be licensing. When you use someone else code, be sure the licensing allow you to use it in your situation.

Link to comment
10 hours ago, ensegre said:

.net is windows only, G runs wherever LV runs.

From the READNE.txt


.net on labview is windows only :(

If you are only working on windows, .net is a reasonable tool to use. I'm using it for example for windows login functionality. There are DLL calls for that of course, but the .net wrapper is nicer. There are also .net features that don't get exposed very nicely in labview for whatever reason. Iterators can be kind of annoying as one example, and event callbacks are another...but again, easier than a DLL. Both DLLs and .net code block the thread in which they are running, so for highly parallel long-running tasks, .net would be inappropriate.

Realistically, you should review any 3rd party code you use unless you really trust them. As such, I'd rather use a SHA function built in labview like this over some random .net assembly on the internet because I can review it more effectively, but if microsoft has a SHA function built into .net, that would probably be preferable on windows. The dll-labview interface can be such a challenge that even those with a good reputation (for example, trying to wrap openssl) would require extensive testing on each platform.

Edited by smithd
Link to comment

There is no right or wrong here. It always depends!

.Net is Windows only and even if there exists Mono for Linux platforms it is not really a feasible platform for real commercial use, even with .Net Core being made open source. And that is why CurrentGen LabVIEW never will support it and NexGen LabVIEW which is based for some parts on .Net still has a very long way to go before it may be ever available on non-Windows platforms. My personal guess is that NexGen will at some point support the NI Linux RT based RIO platforms as target but it will probably never run on Macs or Linux systems as host system.

So if you want to stay on Windows only and never intend to use that code on anything else including RIO and other embedded NI platforms, then you should be safe to use .Net.

Personally I try to avoid .Net whenever possible since it is like adding a huge elephant to a dinosaur to try to make a more elegant animal, and using my code on the embedded platforms is regularly a requirement too.

Admittingly I do know how to interface to platform APIs directly so using .Net instead, while it sometimes may seem easier, feels most times like a pretty big detour in terms of memory and performance considerations.

For things like the mentioned example from the OP, I definitely would prefer a native LabVIEW version if it exists than trying to use .Net, be it a preexisting Microsoft platform API (which exists for this functionality) or a 3rd party library. Incidentally I implemented my own Hash routines long times ago, one of them being a Sha256, but also others. Other things like a fully working cryptographic encryption library are not feasible to implement as native LabVIEW code. The expertise required to write such a library correctly is very high and even if someone is the top expert in this area, a library written by such a person without serious peer review is simply a disaster waiting to happen, where problems like HeartBleed or similar that OpenSSL faced will look like peanuts in comparison.

If other platforms than Windows is even remotely a possibillity then .Net is in my opinion out of question, leaving either external shared libraries or LabVIEW native libraries.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By bartek618
      I know how to run .Net executable by MainWindow() constructor but I have some resources defined in App.xaml and MainWindow() doesn't run without them. How to run application starting with App() constructor? Also I need to pass some parameters into MainWindow().
    • By William Hofmeister
      I need to access Aerotech A3200 data with LabView. The Digital Scope in the A3200 software has the capability to record data at 1kHz for 8 seconds in dedicated batches. We use LabView for all functions surrounding the motion control and have the Aerotech LabView package. Using the LabView vis we can only access data a single data point per call and I don't see how to set up a FIFO to Windows LabView. Someone must have looked at this problem lately. Can anyone steer me in the right direction?  Thanks!!
    • By LogMAN
      So this just happened to me and I'm quite confused by it. As it turns out, the .NET Constructor Node not only provides terminals for error in, error out and the reference, but actually two more "hidden" terminals:

      Notice: I left the error terminals untouched and none of the wires are connected (try it yourself). This never occurred to me. Only now, while hunting a null reference exception I found the constructor node looked "off", like this:

      The strange part is that the terminal doesn't actually carry the reference (which is why I receive the null exception). It only specifies the type. The upper left terminal is a void type input, so the wire is always broken.
      Does anyone know why these extra terminals exist? They don't seem to be part of the specification as far as I can tell.
      Any fancy things we can do with this?
    • By Gribo
      Hello, I am trying to copy multiple cells in LibreOffice, using the UNO API. I encountered an issue in the XCellRangeData object.
      The object's method returns an array of array of any() type. it seems LV can't compile this, even though the wire appears not to be broken. If I try to parse the array of array into a single dimension and then rebuild, the code is broken. See the attached files. Is there a solution for this issue? The alternative would be to copy cells one by one, which is a much slower solution.

    • By P.Carpentier
      Hi Everyone,
      Most of the time I am able to find solutions to my issues just by reading this forum but I wasn't that lucky this time.
      So, i got an issue when i'm trying to install my build.
      I got the following message: "This distribution is built with an older version of winMIF that is not compatible with .NET 4.6.2 upgrade to 17.0"
      When googling this error message or even "winMIF" i can't find anything that match my request
      I tried to uninstall the .NET framework and then reinstall the 4.0 (and 3.5) and I got the same issue. (Exactly the same error even if it's .NET 4.0 or 3.5 ...)

      The computer used to build is a Win7Pro with Labview 16.
      The target computer is a WES7 (but I got the same issue on my dev computer ...)

      In advance thank you, 

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.