Control of VB application from LabVIEW

[battler]

Hi all,

I've just acquired an urgent issue I must address.

A colleague of mine has written a VB.NET application.  The product is due for release however it has not been appropriately protected.  What they'd like me to do is to attach a LabVIEW protection VI to the front of it.  In other words, I'd like to embed if you like his VB application into my front-end LabVIEW VI; I'd like to control when and under what conditions his VB application shall open.

The details on the website as to how I might go about doing this are sketchy to say the least.

I'm hoping someone can steer me in the right direction.

Thank you.

[Lycangeek]

Well, this is interesting...My first question is whether you can do any modification of the VB.NET app. The reason is that the first problem I see - if it's an application, how could you stop anyone from simply running it? If you could convert it into a DLL, then you could call it from LV and it isn't as easy for anyone else to run it. Of course, there is absolutely nothing stopping someone from doing the same thing and circumventing what you've done. So I guess the other question is just how secure you mean for this to be - true authorization security needs to be embedded in the application.

But please reply with what you can and we'll try to find the best solution.

[battler]

Hi Brian, thanks for your reply.

The program does not have to be overly secure.

Ok, so when I say VB application, I still do have access I suppose to the source code.  Not that it would have at all any meaning to me.

So an option for me may be to get my colleague to compile his VB program as a 'DLL', if at all that can be done in VB.  Lets say it is.

I can probably say that I've dabbled with DLLs and I've used some ready built ones in my applications, simply the way I've been instructed to use them but I'm no expert. 

A question:  You can compile any application you construct with say LabVIEW into a dll, rather than an exe, and the difference is that it can be controlled programmatically by another application? 

So he'd compile as a dll and assumably provide for me some means of controlling it.  And if it's a dll then I can forget about all the .NET refnums and conventions?

There's probably a whole lot for me to learn about dll's.

Would the VI Server be useful in this sort of situation?

Also, is there not some sort of code interface node for VB code?

Can't thank you enough for your help.

[Lycangeek]

Answer #1: The best way to think of the difference between a DLL and a EXE is as follows: A DLL is for programs (and programmers) and a EXE is for users. An EXE is designed to have one and only one method - main(). This method is called automatically for you and the behavior of the application is basically fixed (not counting config files and UI controls). The DLL on the other hand has no "default" method - just a suite of methods that you can pick and choose from.

So, in this case, a DLL sounds like a much better option. Note that just because code is built into a DLL doesn't mean it can't have a user interface. It simply means that getting the UI to show up requires another program to call it.

Answer #2: You can't completely ignore .NET refnums, etc. because that is how you're going to control the DLL, but the API you'll need will be fairly simple.

Answer #3: No, the VI server wouldn't help - it is for doing programatic control, but for code written in LV, not .NET

Answer #4: There is a difference between VB and VB.NET, and not just four characters. VB code must be compiled into either a DLL that exposes a standard C interface, or into an ActiveX/COM object, in order to be controlled by LV. In the first case you'd use Call Library Node and in the second case you'd use the ActiveX palette of nodes.

VB.NET is simply a language that, when compiled, is really a .NET application, so interfacing to it from LV is the same whether it is written in C#, VB.NET, C++.NET, Delphi.NET, etc. In all of these cases, you must use the .NET palette to call it.

And just so you know, in order of more complicated to easiest to use is: Call Library Node, ActiveX, .NET

So you're on the right path 🙂

SUMMARY

-----------------------------------------------------------------------

So, with all that, what do I suggest? Have the EXE built into a DLL with a single method - "Run". I haven't done this, but I think you can simply take the same code and rebuilt it as a DLL (aka Class Library in VS.NET speak) and then the Main routine is simply a method on one of the classes - and you can call that from LV.

Then create a VI that does the security, and if all checks pass, have it use the .NET invoke node to call the Main routine. Note that in this case the routine is static and thus you don't need a constructor node, just drop down a .NET invoke node, right click on it and say "Select Class".

Once you have that working, you can start to get more creative.

For example, if you want your VI to control the startup - say disable certain features because of who the user is, you can do that easily. The VB.NET developer needs to do the work in his code to disable the features, but then he can simply expose a method that you can call to enable or disable features. This is all optional, but I hope you see the direction I'm pointing. If you decide to go this way, feel free to post again with more questions.

Let me know if anything isn't clear. It's a lot of information to process at once.

[Jarrod_S.]

There's bound to be some confusion here, since there are unfortunately two drastically different meanings for "DLL." In terms of a .NET application, DLL is not the same thing as with VB 6, C++, etc. The .NET languages can also build DLLs, but these are actually .NET assemblies that you can call from LabVIEW using .NET Constructors rather than Call Library Function Nodes.

So it appears you won't be able to "forget about all the .NET refnums and conventions," since these will be incorporated into your LabVIEW application. If you've ever worked with ActiveX, though, it's very similar.

On a side note, I would recommend upgrading to the latest version of LabVIEW when working with .NET assemblies. We've made a lot of improvements in name parsing, and we've added the ability to host .NET controls in .NET containers.

Here are a few general link on calling .NET assemblies from LabVIEW:

Using .NET with LabVIEW - LabVIEW Help

National Instruments and .NET - Tutorial

Of course Lycangeek posts while I'm writing mine and answers all your questions ;)! Ha! Alas...

Message Edited by Jarrod S. on 01-31-2006 10:30 AM