I have an existing GUI application that should have been implemented as a service. Basically, I need to be able to remotely log onto and off of the Windows 2003 server and still keep this program running.
Is this even possible?
EDIT: Further refinement here... I do not have the source, it's not my application.
You can wrap it up into srvany, though you may need to assign it an actual user account (as opposed to LocalService or some such)
Do you have the source? In many cases the difference between a stand alone application and a service are minimal.
Most of the changes are related to hooking the code into the service manager properly. Once done, you'll know that any problems that occur are a result of your programming and not any other program.
Windows services cannot have GUIs, so you will need to either get rid of the GUI or separate your application into two pieces - a service with no UI, and a "controller" application. If you have the source code, converting the non-GUI code into a service is easy - Visual Studio has a 'Windows Service' project type that takes care of the wrapping for you, and there is a simple walkthrough that shows you how to create a deployment project that will take care of installation.
If you opt for the second route and need to put some of the original GUI code into a controller, the controller and service can communicate via WCF, .NET Remoting or plain socket connections with a protocol you define yourself. If you use Remoting, be sure to use a "chunky" interface that transfers data with as few method invocations as possible - each call has a fair amount of overhead.
If the UI is fairly simple, you may be able to get away with using configuration files for input and log files or the Windows Event Log for output.
First I would have to ask why your service needs a user interface. Most likely it does not but you probably need a client that gets data from this service. The reason services don't usually have GUI's is they may not have a window environment to run in. Services can start and run without a user logged in to the machine. In this case there would be no desktop for the service GUI to run in.
Having said that you can set properties on the service to run as a user as suggested by Mark. You can also specify in the properties of the service to "Allow service to interact with desktop". Only do this if you know a user will be logged in.
A service shouldn't have a GUI, since it should run without any needing any intervention from a user, and there are all sorts of problems associated with finding and communicating with the correct users desktop.
Since, presumably the reason for asking this is to be able to remotely monitor the application, the way to do it would be to have two applications. The service side (written basically as a console application) and the client/monitoring GUI side. The service would use some remote connectivity (when I did this I used Named Pipes) to communicate with the client/monitoring application. Either should be able to run without the other, and certainly the service should be able to run with out the client.
Has anyone used a third party product like: Always Up?
Seems to do what I need. It's the capability to keep running through login / logout cycles I need. And the capability to ignore that it's a GUI app and run it anyway.
They must be linking into the exe manually and calling WinMain or something.
What happens if you create a service. That service is configure to interact with the desktop. Configure it to run a some user and to start automatic. From the service CreateProcess on this other application. I'd guess this is quick to try using C# (C/C++ was alot of code to even be a service if I recall). Would that work??
BUT!
My first thought would be to create a virtual computer in a server-class virtual host (like Virtual Server, HyperV, VMWare). Those virtual machines will run as service (or whatever Hyper V does). The virtual machine would always be running - regardless of logging in and out.
Make this virtual computer auto login to windows (TweakUI can set this up) and then just launch the GUI app using a shortcut to the Startup folder. You can even remote desktop into it use the program's GUI (I bet Always Up can't do that).