Running a LabVIEW-built DLL is not considered as "Run-time engine"?

[Gregory]

I use some conditional disable structures with the RUN_TIME_ENGINE property to get different functionality in the development environment vs. built executables. I assumed that if I built a DLL, the value of RUN_TIME_ENGINE would be True, but that's not the case. 

So, instead I take the VI path and check if it has ".dll" in the path. If the VI is running in the development environment it might have the path:

"...\MyProject\SubVIs\Example.vi"

When running in the DLL it has a path like:

"...\MyDLL.dll\SubVIs\Example.vi"

I don't love this workaround, because someone not in the know could put the LabVIEW project in a folder called "MyDLL.dll Project" for example, and then the logic breaks down. But my main question is: why is code running in a DLL not considered to be running in the RUN_TIME_ENGINE?

I'm using LabVIEW 2016, 32/64-bit

[rolfk · Accepted solution]

If you invoke a LabVIEW DLL in a compatible LabVIEW development system, the DLL will NOT be invoked in its own separate runtime engine but simply loaded into the current LabVIEW process.

Compatible LabVIEW version means that the DLL was created in the same version than what you are currently running or that the DLL was compiled with the "Allow to run in future LabVIEW version" and your current LabVIEW version is newer than what was used to create the LabVIEW DLL.

Main reason to do it like this is that invoking a DLL in a separate Runtime process requires marshalling of all data inputs and outputs for the DLL function parameters across process boundaries, which is more costly in terms of memory and CPU load.

However, the Conditional Compile structure is a compile time feature so it is a bit strange that it will change behavior AFTER the DLL was built!

[Gregory]

Hi Rolf, thank you for the insight! Indeed, I had been calling the DLL from LabVIEW to run some tests, and that must be when I saw that it was running in the development system. I just called the DLL from Python and the Application:Kind is "Run Time Engine" which makes sense. 

I often use the "Application Directory" as a relative path to find other files like config files. This is nice because it returns the folder containing the .lvproj in development environment and containing the .exe for an executable. However, when I call the DLL from e.g. Python, it returns the folder of the python.exe. So I guess I'll have to continue doing my string searching to find the DLL containing folder.

rolfk wrote:

However, the Conditional Compile structure is a compile time feature so it is a bit strange that it will change behavior AFTER the DLL was built!

Sorry, that was my fault for conflating the Application:Kind property and the Conditional Disable property. Since the "Application Directory" was not behaving as I had hoped, some of my file paths were invalid. Since I generate these file paths inside a Conditional Disable structure, I assumed that the problem was with that.

[rolfk]

The Application Directory is simply the current process directory in a runtime environment. Since you execute the DLL from Python, the directory reported will be the directory from which your Python process was started. That could potentially be a different one than what you expect when using virtual envs.

A more robust way would be to use the Current VI Path constant, then backtrack the path one level per iteration until the File/Directory Info returns no error and indicates not a directory. Once more backtracking in the path should then always give you the directory of your EXE, DLL or PPL that your VI is located in.