Should I use .net or a custom library

[ATE-ENGE]

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 April 26, 2018 by ATE-ENGE
Clarification

[ensegre]

cross-platform, say?

[never used that particular library, anyway]

[ATE-ENGE]

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)

[ensegre]

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

From the READNE.txt

Quote

Compatible OS Versions: ALL.

 

[Tim_S]

Potentially speed. Possibly stability. Certain individuals have very strong opinions on .NET and how it's mainly suitable involves the firing range. Otherwise, if you're programming for Windows only, it's a valid use.

[Benoit]

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.

[smithd]

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 April 27, 2018 by smithd

[Rolf Kalbermatter]

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.