.NET Core Constructor Issues

[jyoung8711]

I've played around with the .NET core preview feature in 2024 Q3, and have come across a couple of issues (From another post, I was directed to post this type of feedback here):

1. In addition to "constructors" sometimes I just want a reference to a .NET class.  For the older .NET version, you could right click a reference constant, say "Select .NET class" and then "Browse" for the class you want.  It seems there's no way to browse for classes in .NET Core assemblies.   The constructor gives you the option to explicity select which type of .NET constructor you want... the constant options do not.  Even if you start from a .NET Core reference, the browse ONLY seems to let you work with .NET Framework objects.

2. I am occasionally running into an issue where when you try to create a constructor, the "options" for constructors is just blank... It doesn't show the "This class contains no public constructors" text, and does show anything actually available to work with, nor does it show the "error" message.

Sometimes if I exit the menu, and then re-enter, it WILL show valid constructors... but in at least one case it didn't.  That "one case" happens to be the Microsoft.Garnet project.  This is a .NET Core Native Key-Value store (like Redis).  They have a lovely "portable.7z" asset as part of their releases here : https://github.com/microsoft/garnet/releases which contains all of the dependencies.

When I unzip this, and browse to the "Garnet.client" .dll, I can see a list of the classes in the dll, but the constructor options are empty.

I believe the build is "valid"... I can open the "Garnet.resources" dll and see a constructor there:

My "guess" is that there's some sort of error being encountered when trying to load the other dlls, but that it's not percolating up correctly.

I've had some issues with previous versions of LabVIEW with .NET Standard, particularly with open source tools with large dependency chains (for instance npgsql or parquet.net) where I needed to add a *.lvproj.config file where I needed to redirect to the correct version of the dll. (such as described here: https://www.ni.com/docs/en-US/bundle/labview/page/specifying-which-version-of-a-net-assembly-to-use....)

Something similar might be happening here, but I'm missing any kind of tooling to debug this issue... The ".NET Assemblies in Memory" does not appear to show .NET Core dlls, so that's not even a valid tool.

This could absolutely be a "user error" (a lot of my experience with .NET in LabVIEW has been trial and error), but I think some sort of information is missing from the .NET Core experience here... either to pass on an error or something else.

3. On at least one occasion I seem to have crashed the .NET Core extension, and when I tried to open a dll I got a message about a .net 8.0 interface not being installed:

This could only be resolved by completely restarting LabVIEW -- closing the project and re-opening did NOT resolve this message.

Finally it's probably worth noting... my primary use case for calling .NET libraries is in leveraging the huge open source community to communicate with other projects (redis, postgresql, azure, aws, kafka, etc).  Many of these projects are (more and more) stopping support for the older .NET Framework / .NET Standard interfaces (the latest version npgsql is an example of that), so I'm very excited to see .NET Core support come to LabVIEW -- and doubly excited that this may also result in cross-platform support for .NET libraries (hopefully).

Thanks!

[jyoung8711]

Playing around with things a little bit more (and playing around with the "simpler" library of StackExchange.Redis) has made me suspect that at least one of the issues *may* be a mismatch in versioning of some of the underlying dlls.  As I mentioned in the parent post, this could be handled previously by a app.lvproj.config (or app.exe.config) file.

From reading some documentation though, it looks like this mechanism has been removed for .NET Core and (I think) replaced by a deps.json (and potentially a runtimeconfig.json file?) Would this be the correct mechanism to specify a specific dll version to use? or is there something else going on here? (please forgive any ignorance here, my main experience with .NET today has been through LabVIEW directly)