LabVIEW
Problems when using C# dll or C dll
Solved!
I have got a problem when using C# assemble DLL ,as well as C DLL.
I made a complex funtion(it is no matter about my problem) by C# and build it into a DLL(assemble)，so as to be called by LabVIEW.
Then I use the CLR node in diagram pannel to call the C# DLL,see as below:
but it seems that once I called the DLL, I can not the read it it by binary file. The phenamenon is that if I run the vi twice, error appear from the binary file READ block ,indicating that "the file is already open". I suspect that I need to add a CLOSE method, see as below:
Then I suspect that maybe C# dll is deeply inserted into the software , not really DYNAMIC,so I tried hard to develop a C version "real" DLL file, and eventually finished.(now it seems there is no need to do as so , I can use any C DLL to test it).see as below:
BUT , the same error still exits, showing "the file is already open".
CRY! CRY! CRY!
what shall I do ?
well, if I build the VI into exe and run the exe , such error didnot appear , I can see it from the front pannel's error indicator, no error.
I suspect something had been optimized when building the exe.
Please explain to us what the purpose of the File Open and Read for the DLL is! That DLL is in a binary format be it a C# assembly DLL or a Standard C DLL. So there is really not much you can do with this file contents in this way.
DLLs are meant to call its functionality, not to access their contents as data file like this! Once a DLL is loaded into memory it generally stays in memory and Windows locks it, so that some malicious virus or user can't change its content under its feet and cause a crash.
Assemblies are loaded in LabVIEW when accessing one of its functions for the first time and stay then in memory until you unload any VI that contains a reference to them. Standard C DLLs are also loaded when first accessed and unloading them is only possibly when using the dynamic path of the Call Library Node AND making sure to call every Call Library Node that has a reference to that DLL afterwards with an empty path (e.g. to much hassle in general to do like that). Loading and unloading DLLs, be it .Net assemblies or Standard C DLLs is a VERY time costly operation so LabVIEW does not do this every time a DLL is accessed.
If you still think that this is a superintelligent thing to do, you should look at the open mode of the File Open node. It's default value is NOT compatible with accessing a file that is already open by someone else.
If you build an exe and start it it loads everything including the DLLS and then stops executing and unloading everything each time. Process creation and tear down in Windows is even more costly than loading DLLs so the additional overhead is not such a concern. In the LabVIEW IDE your program is just a script executed inside the LabVIEW IDE and the process remains fully alive all the time until you shutdown LabVIEW itself.
I just have the Read From Text File function , without the Open File and Close File (as they are redundant).
But I open the assembly, and then do the read. I can do this repeatedly, so there doesn't seem to be any problem.
And for the reason... The dll is a licensing dll. The code validates the file's hash against a hardcoded hash, to make (reasonably) sure it's not modified.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
And for the reason... The dll is a licensing dll. The code validates the file's hash against a hardcoded hash, to make (reasonably) sure it's not modified.
Sounds like a maintenace hassle to me! Signing of the DLLs would seem more secure and part of the build process. For signed DLLs the OS will only load them if the signature is valid.
Also the Read from Text File node didn't always open the file implicitedly as read only. Which caused problems when the file was already open (and locked) by someone else.
@rolfk wrote:
wiebe@CARYA wrote:
And for the reason... The dll is a licensing dll. The code validates the file's hash against a hardcoded hash, to make (reasonably) sure it's not modified.
Sounds like a maintenace hassle to me! Signing of the DLLs would seem more secure and part of the build process. For signed DLLs the OS will only load them if the signature is valid.
Didn't say it was a good reason 
.
The maintenance is OK for now, the dll only changes once or twice over the few years. Maybe easier then managing certificates, the application is distributed to a lot of systems (>50?).
@rolfk wrote:
Also the Read from Text File node didn't always open the file implicitedly as read only. Which caused problems when the file was already open (and locked) by someone else.
I'm not sure if it does or doesn't open as read only in LV13. I didn't have to do anything special to make this work.
There might be other forces involved causing OP's problem.
All true of course
But signing doesn't require you to distribute certificates if done right. It does however require the creator of the module (EXE file, DLL or whatever) to obtain a certificate from a well established certification authority, and that does cost money (usually a reoccuring fee too). You then use that certificate to sign the file with the tools provided by the OS manufacturer. So it is a different hassle for sure, but the Right(TM) way to do things
And if you ever want to distribute kernel space files, the only viable way nowadays, as installing unsigned drivers in any modern commercial OS will require the user to bend backwards and jump through several hoops, all while standing on one leg. :
I might bring it up next time there is a revision. The customer delivered the licensing .NET dll. It didn't occur to them at all that anyone could simply replace the dll with a similar one that just returned 'true'. So the hashing was a quick way to avoid that.
Wouldn't it be possible to replace a signed dll with an unsigned one? I'm not sure how it would protect my code from malicious customers trying to replace the dll with something else.
Still wandering what OP's reasons are... Mine are 'reasonably valid', AFAIC.
If you build an exe and start it it loads everything including the DLLS and then stops executing and unloading everything each time. Process creation and tear down in Windows is even more costly than loading DLLs so the additional overhead is not such a concern. In the LabVIEW IDE your program is just a script executed inside the LabVIEW IDE and the process remains fully alive all the time until you shutdown LabVIEW itself.
I made an exam of this ,see as below:
there is no doubt that errors appear when run in LabVIEW IDE, but after I bulid it into an exe file,errors disappear . From your saying , the dll is only unloaded after the exe stoped.
a while loop means the exe do not stop,and the prior loop had already occupied the DLL and do not release it ,but the next loop have no error(I must close the LabVIEW IDE if I want it "no error") , why ?
