Executable not working - dll

[AM86]

Hi all

I'm currently struggling with a project. The application was running on a WIndows XP (32bit) with LabVIEW runtime engine 2009. Since we need to replace the workstation, the OS will change to Windows 10/11. However, I was wondering if it would work on Windows 10 - 64 bit. 

The software writes & reads parameters on a module and uses LIN-Bus / USB Interface. It therefore calls two dlls from a vendor. The dlls are implemented via .net constructor nodes and in the development environment everything is working properly. The parameters can bi written and read on / from the module. But as soon as I create an application (.exe) it doesn't work. It won't even show an error message indicating possible error codes. When I start the exe, it just ask for the dll location and as soon as the first dll was selected it continues. Afterwards the message, that the vi is broken appears and I need to solve this with the development system. 

Do you have any suggestions what it could be? I also already tried to move the dll dircetly into the executable with the appliaction builder. 

I am using LabVIEW 2016 32 bit for this project, since the dlls adressing structure is 32 bit. 

Thank you for any advise

[rolfk]

Are you testing the executable on the same system than where it works in the development environment? If not, you have simply a standard DLL dependency issue. It is almost never enough to just copy a DLL for one system to another and hope that it will work. DLLs almost always require secondary dependencies that need to be present too. And while you can play detective and try to track down all these secondary DLLs and copy them to the target system too, this is not only unmaintainable but potentially dangerous. Some of these secondary DLLs may be specific to a certain system installation and the only one knowing such details is the original developer of those DLLs. This knowledge is usually incorporated in the according installer for that software component.

It may seem convenient to just try to track down all the necessary DLLs and its dependencies and include them into your own installer. This offers the end user a single installer solution and even hide the fact that you rely on some specific software to achieve your app. But it may miss fundamental components that may have to be different on certain systems. Instead there should be an installer for your DLL from the original provider of that DLL and that installer should take care of all the dependencies and you should use that installer in addition to the installer for your own application.

[AM86]

Thank you for your fast response. 

Indeed I am testing the executable on the same system where the development environment is installed too. May assumption was, that testing it on the same system would potentially eliminate any dependency issues. 

However I'll try to create an installer, that includes also the dll. It should also not be normal, that the executable is asking for the dll location. Hope this will solve the problem. 

[rolfk]

It's still likely a dependency problem but not in the form of a system wide component such as a runtime library, but instead some helper library that your DLL depends on. These could be possibly in the same directory as your main DLL, but maybe also in a directory relative to that or relative to your main executable. Which exactly is impossible to say without exact knowledge of the DLL in question, as each DLL could be different.

Whoever developed that DLL could (hopefully) give you more information about this. Anyone else has to guess and try and error.

[AM86]

Indeed it is still not working. Even with installer, the application notifies with the same issue. I do have description of the dll's but it does not help me