VB.Net Passing command line parameters to single instance app

Hi Experts
I have a system that calls my app from the command line with differing parameters each time.  I need to be able to start my app on the first call and thereafter just receive the different parameters on each subsequent call but also to remain open all the time.   The system may call my app anywhere from 1to 5 times a second passing new parameters so the process will need to be quite fast.   I have seen many different examples on the net but all seem overly complicated and most have the first instance of the app closing when the second call starts.   Any help would be appreciated.   Many Thanks.
LVL 2
PNRTAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jacques Bourgeois (James Burger)PresidentCommented:
You did not chose the right configuration for what you want to do.

Command line arguments have but one role: pass startup parameters.

If the system need to communication continuously with your application, then you need to have your application waiting to receive the calls. This means building your application as a service or as a dll, and have your system call it as such.
SStoryCommented:
Without knowing what you are trying to do it is difficult to answer. However, my guess is that you'd want two processes (one a server process--and possibly running as a service depending upon what it does). Then the app people call is just a communicator that gets the parameters from the command-line and uses some form of Inter Process Communication to send that information to the other process or service.

Some thoughts on how to do this:
1.)
app1 param1 param2 ,etc writes a file to a decided upon location (app specific folder with a name no one else would uses) with an extension that of whatever type. Then when it is ready for the info to be consumed by the second app, it creates a file with the same name but a specialize extension like ".RDY" or ".DONE".  App2(the always running app or service) uses FileSystemWatcher to watch that folder for any ".DONE" or ".RDY" files. If found, strips off the .RDY or .DONE and using that name finds the data file, reads it and acts upon it.  Erases both files.  App1 only needs to run long enough to create the input for app2.

2.) App2 always listens as a "server" on some local TCP/IP port, App1 communicates to it and closes

3.) Per MSDN, the other supported mechanisms are:

   "Clipboard
    COM
    Data Copy
    DDE
    File Mapping
    Mailslots
    Pipes
    RPC
    Windows Sockets"
source: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365574%28v=vs.85%29.aspx#base.using_pipes_for_ipc
Éric MoreauSenior .Net ConsultantCommented:
I hope that your process is fast!

maybe have a look at http://emoreau.com/Entries/Articles/2008/11/Passing-arguments-to-an-
application-startup.aspx
Rowby Goren Makes an Impact on Screen and Online

Learn about longtime user Rowby Goren and his great contributions to the site. We explore his method for posing questions that are likely to yield a solution, and take a look at how his career transformed from a Hollywood writer to a website entrepreneur.

PNRTAuthor Commented:
Thank you both for the explanations.  I obviously haven't explained the scenario in enough detail.     I had thought of the alternatives but to explain further -

The system that calls my app is third party and I have no control over it.  It issues the command with the parameters and expects that the application will respond.

The app is not "called" continuously it may only be called once every few days or once a week.   But when it is it starts the process, it issues the commands at the rate of about 1 to 5 a second depending on the size of the file is has produced.  It may issue as many as two to five thousand commands/files  

The system calls my app with the name and path of a file as a parameter and expects this to be dealt with.

Hope this is more informative
Éric MoreauSenior .Net ConsultantCommented:
if you have also created the application calling your second one (to which you pass arguments), instead of using arguments, you can surely use http://emoreau.com/Entries/Articles/2011/09/Using-SystemIOMemoryMappedFiles.aspx
PNRTAuthor Commented:
Thanks for the response Eric, the first link gives a page not found error and as per my update, the first app is not mine but a third party system.  Thanks again.
Éric MoreauSenior .Net ConsultantCommented:
it_saigeDeveloperCommented:
Hi PNRT,

This is a solution that was presented for the questions you had about using the Taskbar elements in Windows, but some of the elements of the code can be used for what you are attempting to accomplish.

http://www.experts-exchange.com/questions/28600426/vb-net-programming-the-Windows7-taskbar-icons.html#a40565503

Recall that the solution presented above starts a new process that calls itself (this is what a JumpListLink essentially is) with command line parameters.

-saige-
Jacques Bourgeois (James Burger)PresidentCommented:
If the files created by your third party are always in the same directory or in a system of subdirectories but with a filename pattern that can be identifiable, you might be able to cope with the problem with a FileSystemWatcher object. Instead of reacting to the calls from the third party, you would then react to the appearance of the files in the file system.
SStoryCommented:
Well still, the app1 that receives the commands needs to in some way communicate them to the processing app. I'm assuming that third party app doesn't wait for replies and just assumes you'll handle it. So in that sense you have an app that is queuing up information for another application/service to consume or to process. So your app is an intermediary application.  My first suggestion of consuming the information and writing files would work.  Your folder watcher could look for .RDY or .DONE files that contain the information given by the other application which could call then process them at its leisure like a queue.  You haven't said if they must be processed in the order received or just processed. If the latter, this would work with no problem. The third party app could call 50 instances of your AppA which "answers the call" and writes to a file, "i.e. takes a note" The AppB, looks for "notes", aka Files of work to be done and consumes them one at a time, deleting the two files when consumed.  It is always watching the folder for anything new.

I've seen this used before and have used it myself. It does work. There are other more sophisticated ways of doing it, like sockets and such. App A somehow gets info, sends to AppB (the service or server process) which Queues up the work to be done for a worker thread or threads to process.
You just have to choose the interprocess communications method for this to work.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
SStoryCommented:
@James Burger..I already mentioned that above.
Mike TomlinsonHigh School Computer Science, Computer Applications, Digital Design, and Mathematics TeacherCommented:
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
.NET Programming

From novice to tech pro — start learning today.