Error trying to select a .NET dll for an invoke node

[TomDzSTFC]

---

@JimB. wrote:

---

---

These machines are running the same version of Windows, correct? Have you compared versions of .NET Framework (not .NET sdk that you previously mentioned) installed on these machines?

Open PowerShell and enter the following command:

Get-ItemPropertyValue -LiteralPath 'HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' -Name Release

If you have the runtime installed then this should return a numeric value. If it is not the same on both computers then they have different versions installed.

If that value is less than 528040 on either computer then I'd recommend installing the 4.8 (or 4.8.1) runtime, which you can get from the link I provided previously.

---

Hi Jim,

I checked the versions of .net (thanks for supplying the command!) they are both identical, 533325.

Both machines are running windows 10 enterprise, 64 bit OS, x64 based processor. Both are version 22H2, both OS build 19045.3930, and both have the "Windows Feature Experience Pack 1000.19053.1000.0 .

Are there any optional labview packages that I could have missed on the second machine that can affect the functionality of labview in this respect? Or is the use of dlls unaffected by the optional packages?

A slight change has occurred. One of my problems was that in a new project on machine 1 I was unable to load the dll in a fresh project. However I tried making a new VI in one of the projects that was loading the dll happily, just to check that my method of placing a lone property node and linking it to the dll was actually a valid test and didn't result in some error, and after doing that I was able to place the property node in the fresh project without issue (not sure if this was a direct result, or just coincidence). So now I am at least back to everything working on machine 1, but not working on the supposedly identical machine 2.

Thanks again for your help!

Tom.

[Kyle97330]

Sometimes .NET DLLs have dependencies on other DLLs that LabVIEW will produce errors like this one if the dependant DLL is missing.

Can you get a 3rd party DLL checker to see what its dependencies are?  I've used one called ILSpy before, but I'm sure there are others.  

[JimB. · Accepted solution]

---

@TomDzSTFC wrote:

---

---

Hi Jim,

I checked the versions of .net (thanks for supplying the command!) they are both identical, 533325.

Both machines are running windows 10 enterprise, 64 bit OS, x64 based processor. Both are version 22H2, both OS build 19045.3930, and both have the "Windows Feature Experience Pack 1000.19053.1000.0 .

Are there any optional labview packages that I could have missed on the second machine that can affect the functionality of labview in this respect? Or is the use of dlls unaffected by the optional packages?

A slight change has occurred. One of my problems was that in a new project on machine 1 I was unable to load the dll in a fresh project. However I tried making a new VI in one of the projects that was loading the dll happily, just to check that my method of placing a lone property node and linking it to the dll was actually a valid test and didn't result in some error, and after doing that I was able to place the property node in the fresh project without issue (not sure if this was a direct result, or just coincidence). So now I am at least back to everything working on machine 1, but not working on the supposedly identical machine 2.

Thanks again for your help!

Tom.

---

Hmm... So it seems both have the latest .NET Framework runtime installed then. As far as I know, no additional packages are required for LabVIEW to interface with .NET. That should be part of the base install.

Are you just copying over this DLL? Does the camera come with some driver or software that perhaps isn't installed on the second machine? The assembly may be dependent on something else, such as some other assembly in the GAC or a native DLL it is trying to load.

Try the attached VI on the second computer. It just converts a string to a .NET object and calls String.ToUpper() to convert all characters to upper case. If it works then you know that you are able to do .NET interop, in which case the problem is something specific about this DLL you are trying to use.

[TomDzSTFC]

---

@JimB. wrote:

---

---

Hmm... So it seems both have the latest .NET Framework runtime installed then. As far as I know, no additional packages are required for LabVIEW to interface with .NET. That should be part of the base install.

Are you just copying over this DLL? Does the camera come with some driver or software that perhaps isn't installed on the second machine? The assembly may be dependent on something else, such as some other assembly in the GAC or a native DLL it is trying to load.

Try the attached VI on the second computer. It just converts a string to a .NET object and calls String.ToUpper() to convert all characters to upper case. If it works then you know that you are able to do .NET interop, in which case the problem is something specific about this DLL you are trying to use.

---

Hi Jim,

Thanks for the example VI, it ran on both machines, which prompted me to follow your suggestion to check the installation of driver software. Embarrassingly, that was the problem, It had been a while since I installed it on the first machine and I had forgotten that I had to run a couple of set-up executables before using the dll. After running those, and a little bit more fiddling to figure out where to point labview, it is now working as expected.

Thank you for all your help, and sorry it turned out to be simple user error in the end!

All the best,

Tom.

[TomDzSTFC]

---

@Kyle97330 wrote:

Sometimes .NET DLLs have dependencies on other DLLs that LabVIEW will produce errors like this one if the dependant DLL is missing.

Can you get a 3rd party DLL checker to see what its dependencies are?  I've used one called ILSpy before, but I'm sure there are others.  

---

Hi Kyle,

Thanks for taking the time to help me out with this. In the end it turned out that I had just stupidly forgotten that I had to run a couple of set-up executables before using the dll, and after having done that it is now all working as expected!

Thanks for your help, and apologies that it turned out to be something so trivial that I should have figured out long before posting in the forum.

Best Regards,

Tom.

[JimB.]

Great to hear! Glad you got it sorted.