Single-instance applications and batch files
-
If an application which is configured for single-instance operation is run from a batch file, is there any nice way to control how long the batch file waits and what error code will be returned to it? The best approach I can figure would be to have a pair of programs: a windowed application that runs single-instance, and a console application that runs multi-instance. When run, the console application would invoke the single-instance application with a parameter containing something like a TCP socket. The single-instance application could then pass back the desired error code as well as any messages it would like the console application to display. My intended use would be that the batch files do operations which may only be done one at a time, and to have the single-instance application sequence the operations, and then remain up after the operations are complete to show their status. My target platform is .net 2.0. Any ideas?
-
If an application which is configured for single-instance operation is run from a batch file, is there any nice way to control how long the batch file waits and what error code will be returned to it? The best approach I can figure would be to have a pair of programs: a windowed application that runs single-instance, and a console application that runs multi-instance. When run, the console application would invoke the single-instance application with a parameter containing something like a TCP socket. The single-instance application could then pass back the desired error code as well as any messages it would like the console application to display. My intended use would be that the batch files do operations which may only be done one at a time, and to have the single-instance application sequence the operations, and then remain up after the operations are complete to show their status. My target platform is .net 2.0. Any ideas?
Hi, a single-instance app never really is single-instance. At best the second, third or whatever instance gets launched, detects it isn't number one, and exits again, hopefully after passing its work to the first instance, maybe by sending its command line through a pipe. how about you make the "single-instance" such that it: - detects it isn't the first; - sends the job to the number one instance; - instead of exiting right away, waits for completion. Doing it that way your batch files don't have to be aware, they would always seem to be talking to the single-instance app. BTW: obviously you can use the Main() method's return value as the batch/DOS exit code. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
Hi, a single-instance app never really is single-instance. At best the second, third or whatever instance gets launched, detects it isn't number one, and exits again, hopefully after passing its work to the first instance, maybe by sending its command line through a pipe. how about you make the "single-instance" such that it: - detects it isn't the first; - sends the job to the number one instance; - instead of exiting right away, waits for completion. Doing it that way your batch files don't have to be aware, they would always seem to be talking to the single-instance app. BTW: obviously you can use the Main() method's return value as the batch/DOS exit code. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
What's the best way of achieving such a result in vb.net (I'm using 2005 at the moment)? Are there any nice template examples to borrow from?
Hi, What part are you having trouble with? What have you done so far? Anyway I use C# most of the time, so I don't have VB.NET code handy for you. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
Hi, What part are you having trouble with? What have you done so far? Anyway I use C# most of the time, so I don't have VB.NET code handy for you. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
I've never actually done an application with a Main() under vb.net, and the only way I've confined applications to single-instance operation is via check-box in the project options. I know that Microsoft added support for named pipes in .net 3.5, but for the moment I'm working with VS2005 and .net 2.0 which does not include the built-in support. FYI, if the "single-instance operation" box is checked in vb, the first-run instance of the application will receive a special event when an attempt is made to launch additional instances; it will receive the command line from the new instance. Very convenient, but I don't know how to have the second instance delay completion and return a particular error code. It will probably be necessary to write a custom Main() to accomplish that, or else go with a two-application approach. The only advantage to the latter would be the ability to have the command-line-launched part show text in the command-prompt window. By my understanding, windowed applications can't do that (unless I'm mistaken?) In response to something like "progger /?" it is often nicer to show a program's options in the command-prompt window than to pop up another window listing them (the exception being if there are over 24 lines of options). It's also nice to see a 'list' in the command-prompt window of what worked and what didn't.
-
I've never actually done an application with a Main() under vb.net, and the only way I've confined applications to single-instance operation is via check-box in the project options. I know that Microsoft added support for named pipes in .net 3.5, but for the moment I'm working with VS2005 and .net 2.0 which does not include the built-in support. FYI, if the "single-instance operation" box is checked in vb, the first-run instance of the application will receive a special event when an attempt is made to launch additional instances; it will receive the command line from the new instance. Very convenient, but I don't know how to have the second instance delay completion and return a particular error code. It will probably be necessary to write a custom Main() to accomplish that, or else go with a two-application approach. The only advantage to the latter would be the ability to have the command-line-launched part show text in the command-prompt window. By my understanding, windowed applications can't do that (unless I'm mistaken?) In response to something like "progger /?" it is often nicer to show a program's options in the command-prompt window than to pop up another window listing them (the exception being if there are over 24 lines of options). It's also nice to see a 'list' in the command-prompt window of what worked and what didn't.
Hi, OK, once more too much C# was popping up in my thinking and reply. What I called Main() would be whatever piece of your VB.NET code gets in charge first. I keep forgetting Visual for VB has special single-instance support. I don't know any details, I never used it; if I were interested, I would launch Reflector and have a peek inside. Most of my C# toolbox was created in either 1.1 or 2.0; when building for 3.x it is bound to contain P/Invoke for a couple of things that now can be handled natively. I do use P/Invoke for named pipes, as I still often build for 2.0 In order to achieve the scheme I proposed in VB.NET you most likely would have to forgo the built-in "single-instance" support, and create your own.
supercat9 wrote:
windowed applications can't do that
Yes, it is unfortunately true. The PE file format has a single bit that chooses between: - a console app, which needs a console to run; when launched in a command prompt/DOS window, it will use that; otherwise it will create its own console window. Your app can create forms and look very much like a WinForm app, however it is a console app. It can hide its own console, but only after it has been shown briefly resulting in an ugly flash. - a non-console app. Now it again can crate forms and be a real WinForm app, or it can choose not to, and maybe show up in the systray. What it can't do is perform input/output to a command prompt/DOS window that maybe launched it. I have been struggling with this for some time, as I wanted to create apps that: - when a command line is present, behave as console apps (so you can use them silently in a batch file); - when a command line isn't present, behave as WinForm apps (so you can use them interactively). And I didn't want to create, maintain and distribute two EXEs, one for each purpose. I had to give up, IMO this historical dichotomy has proven to be a major Windows blunder. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
Hi, OK, once more too much C# was popping up in my thinking and reply. What I called Main() would be whatever piece of your VB.NET code gets in charge first. I keep forgetting Visual for VB has special single-instance support. I don't know any details, I never used it; if I were interested, I would launch Reflector and have a peek inside. Most of my C# toolbox was created in either 1.1 or 2.0; when building for 3.x it is bound to contain P/Invoke for a couple of things that now can be handled natively. I do use P/Invoke for named pipes, as I still often build for 2.0 In order to achieve the scheme I proposed in VB.NET you most likely would have to forgo the built-in "single-instance" support, and create your own.
supercat9 wrote:
windowed applications can't do that
Yes, it is unfortunately true. The PE file format has a single bit that chooses between: - a console app, which needs a console to run; when launched in a command prompt/DOS window, it will use that; otherwise it will create its own console window. Your app can create forms and look very much like a WinForm app, however it is a console app. It can hide its own console, but only after it has been shown briefly resulting in an ugly flash. - a non-console app. Now it again can crate forms and be a real WinForm app, or it can choose not to, and maybe show up in the systray. What it can't do is perform input/output to a command prompt/DOS window that maybe launched it. I have been struggling with this for some time, as I wanted to create apps that: - when a command line is present, behave as console apps (so you can use them silently in a batch file); - when a command line isn't present, behave as WinForm apps (so you can use them interactively). And I didn't want to create, maintain and distribute two EXEs, one for each purpose. I had to give up, IMO this historical dichotomy has proven to be a major Windows blunder. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
And I didn't want to create, maintain and distribute two EXEs, one for each purpose. I wonder whether it would be practical to have a "universal console application" which creates a TCP socket and then launches the other real application, prepending to the command line arguments the identity of the newly-created socket? The other application would exchange its I/O with the socket, and the console ap would send it to the console. If the two applications had a consistent naming convention, one would have to distribute both exe's but the console side application wouldn't have to be maintained.
-
And I didn't want to create, maintain and distribute two EXEs, one for each purpose. I wonder whether it would be practical to have a "universal console application" which creates a TCP socket and then launches the other real application, prepending to the command line arguments the identity of the newly-created socket? The other application would exchange its I/O with the socket, and the console ap would send it to the console. If the two applications had a consistent naming convention, one would have to distribute both exe's but the console side application wouldn't have to be maintained.
Hi, interesting idea. I'm not inclined to use TCP/IP for local purposes as it may pose problems selecting channels, avoiding conflicts, configuring firewalls, etc; risks which aren't necessary as you can use named pipes equally well. And you need only one per singleton. So the singleton-enforcer could be a console app with the following syntax:
enforce1 filename.exe command_line_argumentsThis enforce1 would: 1. algorithmically derive a pipe name form the filename.exe 2. look for a process P currently executing filename.exe, and if none found, launch filename.exe as a process P without arguments; 3. send its process ID and the command_line_arguments to P 4. wait for a return status, which I would transmit using a Windows message (based on PID). all of the above is independent of the exe's functionality. enforce1 is general-purpose. the target exe should ignore its command line; it must open and listen to the named pipe (again derived from the EXE name), expect to receive a PID+command line, and when done send a Windows message to process P with given PID to return the 32-bit result status; and loop waiting for another piped command. It may or may not use multithreading to perform several jobs concurrently. The piped message is a command line, that should be short enough to be atomic. So all enforcers can send to the same pipe without fearing collisions/confusion. One might consider a non-console version of the enforcer too. BTW: all of this does not solve my earlier quest for a single exe offering an app that acts as both console and non-console, since 1) it is two or three EXE (one universal), and 2) the console part is universal, hence ignorant of the actual application (it can't provide help for instance). :)Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
Hi, interesting idea. I'm not inclined to use TCP/IP for local purposes as it may pose problems selecting channels, avoiding conflicts, configuring firewalls, etc; risks which aren't necessary as you can use named pipes equally well. And you need only one per singleton. So the singleton-enforcer could be a console app with the following syntax:
enforce1 filename.exe command_line_argumentsThis enforce1 would: 1. algorithmically derive a pipe name form the filename.exe 2. look for a process P currently executing filename.exe, and if none found, launch filename.exe as a process P without arguments; 3. send its process ID and the command_line_arguments to P 4. wait for a return status, which I would transmit using a Windows message (based on PID). all of the above is independent of the exe's functionality. enforce1 is general-purpose. the target exe should ignore its command line; it must open and listen to the named pipe (again derived from the EXE name), expect to receive a PID+command line, and when done send a Windows message to process P with given PID to return the 32-bit result status; and loop waiting for another piped command. It may or may not use multithreading to perform several jobs concurrently. The piped message is a command line, that should be short enough to be atomic. So all enforcers can send to the same pipe without fearing collisions/confusion. One might consider a non-console version of the enforcer too. BTW: all of this does not solve my earlier quest for a single exe offering an app that acts as both console and non-console, since 1) it is two or three EXE (one universal), and 2) the console part is universal, hence ignorant of the actual application (it can't provide help for instance). :)Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
enforce1 filename.exe command_line_arguments If the main application file name were derived from the command-line-app name, one could use absolutely identical command-line apps for any number of programs. The only time the console app would have to provide any "help" would be if the system couldn't find the main application, in which case a message to that effect should probably be sufficient. BTW, I vaguely recall an article which discussed having one application named xxx.com and the other xxx.exe but I don't remember exactly what the author was doing.