08-14-2013 01:03 PM
Hello,
I'm trying to link to a DLL made in .NET 4.0. When calling the DLL I pass a relative path which tells the DLL where to find its config file. The config file currently just contains another relative path specifying where to write log files (there are various functions which create csv files with results)
I'm having trouble making the DLL and LabVIEW actually generate the log files reliably. The log files are only generated if I re-select the DLL the Constructor Node uses every time I start LabVIEW. If I quit LabVIEW and open it again, I'm able to run all of the VIs without error (all of the functions are outputting proper results) except the log files aren't generated!
To get the log files to work, I need to re-browse for the DLL and select it again. I'm not selecting a different DLL, just re-selecting the same one.
I tried disabling shadow copying, as specified here, but the log files still aren't being generated unless I re-connect the DLL every time I start LabVIEW. I find this really weird because all of the functions are working properly, no errors are appearing, but the log files aren't being generated. I used the '.NET Assemblies in Memory' window to see where the DLLs were being called from. The paths were the same with shadow copying enabled and disabled, and before/after reselecting the DLL.
Does anyone know what might be causing this? It would make more sense if the DLLs simply didn't work, but I find it really strange that when I first start LabVIEW all of the DLL functions work properly except for the Log file generation. To get the log files to work I need to re-select the DLL, but the location of the DLL never changes according to the .NET Assemblies in Memory window, so why isn't the DLL working when I first start LabVIEW?
Any advice would be greatly appreciated!
Thank you,
-Nick
08-14-2013 02:10 PM
Have you tried registering your assembly? Also, can you create a function in the DLL to return the log path? I suspect that your DLL is using the "Current Working Directory" as the base which gets set correctly everytime you manually browse to the DLL. If you can return the log file path, then you can verify where the log is being stored. If it is indeed a current working directory issue then I can post a snippet of code that allows you to get and set the current working directory.