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: But nothing helps. 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.

@alii001 wrote: eh, what does "that" mean ? I indeed make that DLL by C language, I considerd that C is safer than C#. Ever heard of something called Disassembler? A DLL can be simply loaded in one and an educated person knowing about the machine code of the CPU in question can then exactly deduce the algorithme in there. No it's not as trivial than reading the actual source code, since assembly code is quite a bit more low level than C but it's no rocket science either. But there exist tools that can turn the created assembly code into pseudo C code that needs only some cleaning and tweaking in order to be compilable. You also have similar Disassemblers for .Net IL code, and while the more simple free ones can be dwarted with obfuscation when creating the assembly, there are some tools out there that can reconstruct the original code very accurately albeit not verbatim. It doesn't require state sponsored hacker groups at all, everybody with a computer and some dedication can do it in his home office, although some of those tools do cost considereable money. It's illegal to do that in order to steal information but it's also illegal to kill people and there are still people murdered every day. There are also legal uses of Disassemblers such as research, debugging your own software when it doesn't work, and even learning how something else works as long as you don't steal it. But if you live in the US you need to be very careful with doing that. First , as I metioned , It should be the DLL who decide allow others open it or not , not the new thread or software,are you willing to explain more about ? Sigh. It's irrelevant what you believe in this case. That is simply not how an OS works. The file has very little to say about who can open it and when. That is decided by attributes of the file as set through the user or installer and then by the OS. Whoever opens a file can decide if he wants to open it for just read or write access or both. The OS does that also when accessing a file, be it a data file or a dynamic loadable module. For dynamically loadable modules it also leaves the file locked after it has been loaded, in order to prevent some rogue process or malicious user to modify the file and pull the rug under its feet. It at leasts marks the file as not writeable by anyone else but might just as well decide to lock the file completely and with that disallow any access to that file by anyone else. Second , I glanced the OPEN block ,belows are the total input of them ,which input should I modify ? I spelled it out already almost to the letter! For some reason what is called "access" in my copy of LabVIEW seems to be called "authority" in yours. No idea why. This parameter tells the OS if the file should be opened for read, write or both. If the file is loaded by someone else and marked as not accessible for write access, trying to open it with read-write or write-only access will cause the OS to deny opening the file. For your case this should be set to read-only.

LabVIEW

Problems when using C# dll or C dll

Solved!

@alii001 wrote:

I live in a country that you may know,not like in the US. and I myself have to pay much more attention on protecting my codes and idea……

As said there might be reasons to do something like that. But from what I have seen so far, in most cases people simply either overestimate the danger of that or just as likely overestimate their ability to dwart such attempts. I'm not so concerned about the occasional script kiddie who may want to see if he can hack it just for the sake of hacking, but once real money is involved the odds for having even your super secret state of the art protection hacked is simply directly proportional to the amount of money that is involved. And in many cases the effort to protect something is eating up any possible profit you could make so it's a catch 22.

Basically: Don't protect it and it gets stolen if it is worth the effort, protect it and it is stolen too if it is valuable in any way. That's a race you can never win. You can at best postbone the moment a little when you loose. Another approach is to keep inventing new stuff. By the time your adversory has stolen your idea you already have a better one on the market. Might sound exhausting but its chance for success is at least as high.

Rolf Kalbermatter
My Blog