How can I identify different instances of an executable?

[tst]

You could probably also use various workarounds, but I can't say I would consider them elegant:

1. Use a non-reentrant VI with a First Call and a feedback node to return a GUID or UUID per instance. Has a non-zero chance of duplicating based on the GUID algorithm.
2. Pass an ID as a command line parameter. That means you need a caller to launch these which would be "non-reentrant" and can use something like the current time to a high resolution or a running counter stored in a file to assign the IDs.

[mikeporter]

You can also check here.

Mike...

[X.]

---

@mikeporter wrote:

You can also check here.

---

Good to know (apart from the fact that I have no idea which class to look into to get access to these functions).

What is the advantage (if any) of using .NET versus a direct call to kernel32.dll?

[mikeporter]

Well you could download the code. Plus that code wasn't intended to run in the executable being managed. It's for another process to see how the executable is doing.

The important part would be to pass the identifying information to the executable as it is launched.

Having a unique identifier is only helpful if its unique AND useful. Randomly generated numbers and PIDs for the most part are not.

Mike...

[rolfk]

The advantage of .Net is that it is generally easier to develop (if you know where to look for what class and methods to use) than fiddling with Call Library Nodes which will generally do bad things to LabVIEW and your app if they aren't perfectly correctly configured and setup. And it may sometimes appear to work without crash but still corrupt something and you may only run into that problem when you deployed the application in a remote application where you have to take an airplaine to get there! 🙂

But if you know Call Library Nodes well and how to correctly use them, then it's definitely an advantage to go the direct kernel32.dll path as this will not invoke an extra 100MB .Net runtiime system for a simple OS call.