LabVIEW
.NET Core in LabVIEW 2025 Q1
I made a post on this in the Public Beta boards a few months ago related to LabVIEW 2024Q3 and this "preview feature", but didn't get any response:
https://forums.ni.com/t5/LabVIEW-Public-Beta-Program-in/NET-Core-Constructor-Issues/td-p/4414018
So, with the release LV 2025 Q1, I thought I'd give this another try and see how things were, and I still had quite a few issues, such that in it's current state, this appears to be unusable :(.
In my previous post, I used an example of Microsoft Garnet, which has a fairly complex dependency chain.
For this post, I'm going to work with Npgsql -- the postgresql API, which for .NET Core is pretty simple.
Previously I've leveraged the .NETStandard2.0 version of this in LabVIEW to great success.
However, as of version 8.0 (released 11/21/2023), they no longer support anything except for .NET Core.
My process here was to download the Npgsql .dll, and the corresponding dependency dlls manually from Nuget.
These are all placed in the same folder. I create a LV project in that same folder, and a VI to work with in that same folder.
Here were my issues/observations:
- The issue of not being able to create .NET Core constants (by right clicking on a .NET Core reference constant, and trying to change the class) now works -- this did not work in the Preview -- Yay!
- If I just right-click the constructor, click "Select .NET Core Constructor", and browse to the Npgsql.dll, I can see the classes/objects, but if I click on one, I get no "Contructor". This includes NO "There are no available constructors" messages. It's just blank. This is unhelpful.
- HOWEVER -- if I first create a constructor for each of the dependencies (in this case: Microsoft.Extensions.DependencyInjection.Abstractions, and Microsoft.Extensions.Logging.Abstractions) and select a random constructor, I now see things loaded as expected, and I can select the class to work with (yay!), so it appears that dependencies are not being found auto-magically if the dlls are all in the same folder (which is how .NET Framework works)
- I also ran into one other weirdness with the dependencies. If when I went to download things, I downloaded the absolute LATEST dependencies (v9.0.X) -- (Note this is still the .NET Core 8.0 runtime not the new 9.0... just the package version is 9.0) -- And I go through this same process, npgsql will no longer work. This APPEARS to be because a new dependency (System.Diagnostics.DiagnosticSource.dll) is added in this version, and the system auto-links it to the version installed to the OS, which is a version 8.0.X, and hence incompatible. I can't force it to relink to the correct later version.
- Going back to a working version... while trying to actually work with the libraries, I CONTINUALLY got pop-ups telling me that it was seeing a library version change from 0.0.0.0 --> 9.0.2. This was happening pretty much anytime I moved a node, selected a function, tried to wire something, went to run the VI... anything... once I got sufficiently many nodes dropped down, this because almost unrealistic to work with because of all of the pop-ups (a run/save/compile/LV Restart did not change this behavior).
- After I got things started up I tried to establish a connection to the postgresql data source. I ran the code and got a lovely pop-up telling me there was an arbitrary error, but no actual error information was sent out. Compare this error message, to the one from the same calls in the older .NET Standard 2.0 API from LV 2020 (second image) which is nice enough to tell me that I had an error in my connection string related to the "user" entry.
- Once I fixed this error on my side, and I ran the code again... I got a hard crash in the "Open Connection" command. By hard crash, I mean that LabVIEW just completely shutdown, with no messages what-so-ever, and when I start it back up, I also get no messages. However, the crash does show up in the Windows Event Viewer, with the following information, saying that the niDotNETCoreInterop.dll was the cause of the crash -- (note, this same calls does NOT crash LV 2020 with the .NET Standard 2.0 version of the library)
I think this is a pretty simple use case, and is a representative use case of how users would want to use this (or at least it's one of the simplest use cases that I have, beyond using a single-call to a built in function.
I've attached the project here.
While normally I'd say you probably need an instance of PostgreSQL (with a populated table to test against), in this case, the code crashes while trying to make the connection, so you don't ACTUALLY need a postgreSQL instance to see everything that I've talked about in this post.
I've attached a second .zip file which has the "latest" dependencies, and exhibits the behavior of linking to the wrong .NET dll (this is labeled "LatestDependencies").
This could absolutely be a "me" problem... but if so, I'd love to know what I'm doing wrong here :).
I could also be observing a mixture of missing features/bugs, but it would be nice to know what above is a limitation vs a bug.
I'm happy to work with someone to figure this out... enabling .NET core to access various APIs is a pretty high-priority for me for some things I'm interested in.
Thanks!
