LabVIEW
Loading .NET 4.0 Assemblies in LabVIEW 2021 to communicate with Oracle Server
Dear All,
We have custom developed .DLL which has stored in C drive.
Now we want to call them using constructor node in LabVIEW.
In Constructor Node Configuration I am giving the Path of C drive, but ".NET Assemblies in Memory" window shows in D Drive where project saved.
I have tested Oracle server and its properly working.
Now when I am running code as shown bellow its running fine without any error, but I didn't getting response from the server.
Shall I missing some required configuration or need to do any correction in the code?
I also tried with keeping developed exe in C drive. but wont help.
Most likely your description is not quite complete. The path you show in that window obviously is from within the LabVIEW development environment and your project is most likely on the D volume. LabVIEW loads shared libraries normally from the default .Net locaties, which there only exists the GAC and the executable directory path. Adding assemblies to the directory where LabVIEW exe is located is obviously a very bad idea so LabVIEW adds the directory where your project files resides into the .Net AppDomain, in order for .Net to also search there.
When building an application, the LabVIEW application builder will copy all DLLs files that are referenced from somewhere else than the system search paths, into the build directory (usually the data folder by default but you can change that in the build specification) and updates every caller in the build executable to reference the DLL from that location. What it doesn't know and can't do is to find any dependencies that this DLL might have.
Your second view shows a folder with the build LabVIEW Application.exe I assume, and a whole bunch of DLLs alongside. As far as that is concerned the DLLs definitely should be loaded from that location in the build executable (it is the very first location searched by the .Net CLR when asked to load an assembly. The important thing to take from this is that the path that you may see in the LabVIEW IDE that is used when you run your program from there has (and normally is) absolutely NOT the same as the path that a build executable will use. Technically the LabVIEW executable couldn't even cause the .Net CLR to load that assembly from the D volume, if it itself resides on the C volume. A LabVIEW executable only uses the default .Net AppDomain and will only allow referencing assemblies that reside either in the executable directory or in the GAC. Classical Win apps can modify the AppDomain to allow additional search locations, UWP apps officially can't. They are supposed to be self contained and with very little access to anything outside of their own container and officially sanctioned locations.
What might be the problem here is that some of these DLLs have other dependencies that you haven't found yet and not copied into this directory. Depending on how the calling DLLs are programmed they can ignore missing dependencies and simply do nothing, or return and error, or crash fatally. Which of these if any, is entirely out of the hands of LabVIEW to decide or to force.
Dear Rolf Kalbermatter,
Thank you for the answering.
We have a "Test exe" which is developed in another third party application, that kept in same location where LabVIEW exe has been saved. That's working perfectly fine.
I also conform that, now .dll path is from C drive only. But still it won't work.
