EXE with new DLL is unable to run on runtime machine

[BlackSupra]

So, I have a PC in production that runs cDAQ and is using a custom DLL to communicate with a device under test. The program among other things uses the mentioned  DLL and I've been using DLL version 1.0.9 for a while now with no issues.

Recently there has been an update for the DLL (few functions have been fixed and minor bugs removed). With some struggle on my development PC I replaced DLL 1.0.9 with new version DLL 1.0.11. For some reason LV doesn't want to accept the new version (I had to delete the old version and replace it with new one) but I managed to get it working. I've found issues of this exact problem that are 20years old (maybe NI should finally investigate and fix this).

Upon testing the functionality on the testing rig with my PC (fixed few minor issues but no major DLL missing errors), I've build exe and tested it on the actual production PC. To my surprise it asked for a DLL location which then I assigned. However the exe for some reason is not executable and I don't have any more info on why not. The exe and other files within the destination directory for exe were build using "Application (EXE)" builder. The DLL location is assigned via the "Select .NET Constructor". I've been using the exact same sub VI for older DLL and I've never had any issues with this. I've tried everything I could think of and nothing worked.

I have also tried running it on another PC and it also can't find the DLL and the exe is not executable which points to a problem with DLL location. I've had similar problems before (txt, ini, files ..) and assigning correct location was the solution but on this one I have no idea since you select it via .NET constructor and that is it. 

I know it is a long post but there is also a lot on info on this specific problem. I've tried everything and this is my last resort.

Any help is much appreciated.

[ZYOng]

How LabVIEW Locates .NET Assemblies

Specify the Path for the .NET Assemblies Called From LabVIEW

[christoph84]

Could you resolve your problem?

I have the same problem with a DLL of one of our customers since LabVIEW 2025.

[BlackSupra]

The DLL I'm using was made by outside company. I'm currently investigating the "MyLabVIEWApp.exe.config" option. But I have a problem that  the dll is not strongly named and I'm currently waiting for them to update it. I'll report back when I get the file and test the functionality.

[rolfk]

When the DLL is present but LabVIEW can't load it (actually Windows .Net tries to do that for LabVIEW), the reason is usually missing dependencies.

Is this a pure .Net DLL or a mixed mode one?

Which .Net version does it expect to be able to use?

If it is mixed mode, which Visual C compiler version was used to compile the mixed mode part? What other binary dependencies does this DLL have, both for .Net code as well as in the case of mixed mode assemblies for the native part?

The main reason NI hasn't "fixed" this 20 year old issue, is that there are many possible reason that this error can occur and most are completely out of control of LabVIEW!

[RTSLVU]

Some dynamic link libraries need to be "installed" not just copied onto the target machine. During the installation process the DLL is "registered", it's version and location is put in the Windows Registry.

[rolfk]

---

@RTSLVU wrote:

Some dynamic link libraries need to be "installed" not just copied onto the target machine. During the installation process the DLL is "registered", it's version and location is put in the Windows Registry.

---

And any dependencies of the component are installed too onto the machine, if they aren’t already present. This could be utility libraries from the manufacturer, 3rd party libraries they used in their software and the according runtime libraries for the used compilers.

There is no way for LabVIEW to know about such dependencies, only the creator of that component really knows and they have hopefully put that knowledge into the installer for that component.

[christoph84]

Our customer who provides the DLL has assured me that they have not changed anything in their build process and yet LabVIEW 2025 is unable to load the current version of the DLL. Something serious must have changed in LV2025 (or 2024?). It's just frustrating...

[rolfk]

Is that on exactly the same machine as your earlier attempts? The serious change could otherwise be rather in the Windows installation itself.

But yes, since it is a .Net component, the "serious" change might be related to NI's effort to try to support .Net Core, aka .Net 8. Something many people have declared LabVIEW to be dead on arrival since many years, if it doesn't support it.

And there are many ways someone can make .Net a hell to live in, both in LabVIEW and an assembly that users want to use in an application. My guess is that it is not just LabVIEW's fault but potentially also the assemblies fault for doing something that has been declared depreciated by Microsoft many many .Net versions ago.

Also they may believe they changed nothing about the way they build their assembly but it is quite likely that they are not using the same build machine with the same OS, compiler version and other things than a few years ago. They may not be aware that something changed, but that doesn't mean that it didn't. Even a Windows security update on the build machine could have made a difference at some point.

Without knowing in detail what .Net assembly this is about, it is at this point mostly fingerpointing at each other, who might be the real culprit here. It may give you a feeling of relieve to do that, but it won't help you to solve the real issue here.

[christoph84]

Yes, that may be, but I don't have time to spend weeks chasing this problem.

In this state I can never upgrade this project because LV2023 might be the last working version. I simply expect the necessary compatibility here. What works in 2023 should also work in 2025 as long as NI doesn't explicitly announce it as obsolete (and I haven't found anything like that in the release notes).

With LabVIEW there is so often something that doesn't work. This is one reason why we now start most new projects with C# or Python and want to get rid of LabVIEW in the long term.