Printable View
Hello,
I'm developing an application that needs to ensure that another specific program isn't started while the app is executing. What would be the best way to accomplish this? I've stumbled upon semaphores but I'm not sure if this is the way to go or not.
Thanks in advance!
Do you have control over the other application or not?
What you can do is enumerate all process and check if a specific process is running if you don't have control about the other application.
If you have control over the (source of) the other application, it's wise to create a semaphore.
I won't have control over when the other application can be started. The app I'm worried about is a vb6 app that provides the end-user the ability to reboot the machine.Quote:
Originally Posted by Tischnoetentoet
The program I'm developing will be a c# console app that controls critical file synchronization for our enterprise application. It will be invoked behind the scenes and invisible to the user. I need to ensure that the user can't run the vb6 reboot app while my yet-to-be-developed file sync app is running.
I've also been looking into the mutex object. Would that be a better alternative? I'm using framework 2.0.
Thanks again!
Any of the synchronization objects like a mutex or semaphore will only be helpful if you can modify the source code of the vb6 application.
How this would work (say if you use a mutex), is you would create a named mutex in your file sync app and modify the vb6 app to look for the mutex when it starts up. If it finds the mutex, it exits; otherwise it runs normally. Again for this to work, you need to modify the vb6 application.
If you can't modify the vb6 app, then you will need to enumerate the processes periodically and detect when the vb6 app has been started.
As far as using a console app for critical system work, I would recommend that you put this functionality inside a Windows Service. Windows Services are generally more robust than console apps (and you get the benefits of being able to restart them on an error or after a system shutdown).
Arjay, thanks for your insight. I was wondering how the mutex would work with vb6, I was hoping I could just lock down the OS or at least somehow provide the name of the .exe to stop it from running. The mutex route seems the most elegant way, but I'm unsure if I'd be allowed to update the vb6 app.Quote:
Originally Posted by Arjay
If I can't use the mutex, perhaps I can spawn a thread in my new app that constantly enumerates all running processes and stops the offending app if found. I imagine it could accomplish this before the reboot would happen since there is a bit of I/O in the vb6 app. But it seems this method isn't fullproof.
Thanks for the tip on services. As it stands this new app will be called from a scheduling service we have running.
Modifying the VB6 app to add the mutex is the most sure fire way. On the other hand, what do you do if the user shuts the system down through other means (if that is even possible)? Your synchronizing app probably should detect system shutdown and save state, etc. before closing.Quote:
Originally Posted by Leedogg
You are correct about enumeration processes not being the best way - the danger here is that VB6 app could start and initiate a shutdown before being detected.
Does this app do more than a system shutdown? If not, perhaps you can write another 'shutdown' app that coordinates with the sync app?
I've gotten permission to upgrade our vb6 shutdown app. From what I've been able to find though, the way the vb6 mutex API calls work is that you try and create the mutex then you have to detect if an error has been raised during it's creation (indicating that it already exists). Is there a more straightforward way to detect a mutex's existence in vb6?Quote:
Originally Posted by Arjay
Regarding the shutdown detection, I'm configuring the c# app to place itself in the windows RunOnce so that it'll start back up following a reboot. Do you see any problems with this approach?
That's the way to do it (and it doesn't matter if you are on VB6 or C++, using the mutex is really the same.Quote:
Originally Posted by Leedogg
You need to ask what happens if the app encounters a catestrophic error - do you need it to recover on its own? If the answer is yes, then you may want to put the code into a Window Service. This way it will always start when the machine boots and can recover (i.e. service automatically restarts) when a major error occurs. Btw, writing a Windows Service in C# is pretty easy.Quote:
Originally Posted by Leedogg