Call a DLL written in .NET Core

[NiklasS]

Hi.
I'm trying in windows 10, LV2019 to call a DLL written in .NET Core. When I select the dll file in "Constructor Node", only the text "an error occurred trying to load the assembly" is displayed

I have no problem calling a DLL written in .NET framvwork.

Does anyone have an idea why?

[Kyle97330]

In my somewhat limited experience with NET Core, usually it's due to missing dependencies.

Try putting your DLL's path into this code as the input:

It will get a list of all dependencies, then filter it for ones it can't load.  You can then find the DLLs missing and either put them in the same directory as the not-working DLL, or if you can find an installer, install them into the GAC on the PC in question.

[NiklasS]

thanks for your reply.

But the dll that I want to call is a simple "hello world" dll library with one simple class that only has one method that returns a "hello world" string.

It is my colleague who is a .net developer who wants to start using .Net Core instead of the .net framework in future projects. He usually writes backend in .net in our projects.

So, it is he who has made the .dll and there is no dependency on other dll:s.

If anyone has Microsoft Visual Studio. Try to build a simple DLL in C# with .NET Core that you then call in LabVIEW and share your experience. I have searched but found no example

All thoughts are gratefully received.

[Kyle97330]

Did you actually try the check for dependencies or did you just assume there would be none because that's what the developer claimed?

The DLL I had to use that was made with Core included a bunch of Microsoft.Extensions.* dependencies even though the dev didn't actively use them.

Even if it doesn't have any dependencies, seeing if the "LoadFrom" and "GetReferencedAssemblies" nodes produce any errors in LabVIEW might reveal helpful information.

Also, are you on the most recent rev of Windows 10 (1909) that includes .NET framework 4.8?

[NiklasS]

thank you for your thoughts.
I'm sitting on a Windows 10 Pro 1903
.NET Framework 4.0.30319

"List NET DLL dependencies.vi" shows the attached image.

I think I have an old .NET Framework. since it looks like it was built in 4.2.2.0.

I will update my .NET and try again.

[NiklasS]

Now I have downloaded and installed Visual Studio 2019.
Made my own test library (LLB) in both .NET Framework and .NET Core
It works well to load the .NET Framework dll into LabVIEW
But not .NET Core dll.
Why it's like this.
I have zipped all the source code and attached it. (for now LabVIEW 2016 so that more can open )

Gladly take your thoughts.

[DaSh · Accepted solution]

Hello Niklas, 

Unfortunately, LabVIEW does not support .NET Core assemblies due to the reason that LabVIEW uses the .NET Framework/CLR 4.0. 

Based on this link Requirements for Using .NET Assemblies in LabVIEW, LabVIEW has access to the class library assemblies associated with the .NET CLR 4.0, which installs with LabVIEW.

Since LabVIEW uses the .NET Framework, It can load assemblies built for .NET Standard or .NET Framework; here's a nice visual from this MSDN post. 

Let me know if you have any questions.

Regards

Dalia R.

[NiklasS]

Ok, thanks for the information and your help.

[samsi]

Is there any roadmap when does Labview support .Net Core Framework?

[rolfk]

---

@samsi wrote:

Is there any roadmap when does Labview support .Net Core Framework?

---

Yes! It's not LabVIEW only but for the new Test WorkFlow suite which also contains LabVIEW. https://www.ni.com/nl-nl/shop/electronic-test-instrumentation/what-is-test-workflow.html

Check halfway down for the Test WorkFlow Roadmap link. Download the Roadmap!

In there it says that .Net Core support is on the roadmap but not for the next 1 or 2 releases, where NI considers the yearly platform release and the intermediate Service Pack release as independent releases. So with 2022 out, 2022 SP1 coming out around begin of next year and 2023 later that year, it is a little ambitious to expect it to appear in 2023 but likely to come in 2024. NI knows it is an important item, but it is quite a little more than just throwing a compile switch somewhere, especially if they want to do the work so it won't just add .Net Core capability to the Windows version (without disallowing .Net Framework support which would be a backwards compatibility nightmare) but also allow .Net Core use on Mac and Linux.