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.
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.
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.
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)
I've had good experience with winsw. I was able to convert quite easily my batch files to services using it.
I've used it for nginx as well, per this answer.
Do you actually need it to run as a service or do you just need it to stay running when you aren't connected? If the latter, you can disconnect instead of logging off and the application will continue running. The option should be in the drop down list after choosing Shut Down or you can call tsdiscon.exe.
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.
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).
You can use ServiceMill to achieve this operation.
Basically you install ServiceMill Server on your server.
Then click on right button over your executable file and "Install as a ServiceMill Service".
Next you configure some things (user/password, if you want to interact with desktop or if you prefer to hide the ui... and set the start mode to automatic).
Another tool from Active+ Software can be a solution, ServiceMill Exe Builder which allows you to create services from Command Line and this is great if you are using a Continuous Integration Server or if you plan to distribute your component as a service without having to think about service integration (plus it is royalty free).
FireDaemonPro turns most GUI apps into services; it's not free, but it might be worth getting it.
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.
Related
I am looking for a simple way to send messages between a Winforms Application and a Windows Service. The service will be run under LocalSystem so will be able to install updates to my Winforms App. The app is run in very locked down environments where port will be blocked and the file system is not reliable enough to use it for logging. I have tried using Named Pipes but i could not get this to work. I want to keep it simple so was thinking of trying Memory Mapped Files?
I only want to pass simple strings back and forth between the app and service, e.g.
APP-> Service [Please download this file http... and place it here C:\Program Files...]
Service->APP [0% downloaded]
Service->APP [1% downloaded]
etc..
Service->APP [Update Complete/Failed]
I cant seem to find a good example of how this can be achieved? Is memory mapped files the best way to go? If so, where do i start?! I have been reading through this Post but i cannot seem to make sense of it, its been a long day! I want everything to be in memory, unlike in this example. Can anyone help?
I need to deploy an application onto some Windows machines for purposes of data collection from a group of people (i.e. the application will be used to gather responses to a series of survey questions). The process is interactive, alternating between displays of text and images with specific timing requirements. I have put together a prototype application using HTML and JavaScript that implements the survey. However, there are some unique constraints on the deployment environment that have me stuck:
While the machine is Internet-connected, the client requires that the survey application must run fully local to the PC that it runs on. Therefore, sending the survey results to a remote server is not permissible. Obviously, saving to a local file from a Web browser is typically not permitted for security reasons.
Installation of applications onto the machines that will run the survey is not permitted.
The configuration of the machines is not known specifically a priori, but I can assume some recent version of Windows with IE8+.
The "no remote access" requirement was a late comer, and has thrown a wrench into the plan of just writing a simple Web application that could post results to an HTTP server. I'm now looking for the easiest way forward. Two main approaches come to mind:
Use a GUI framework that provides a control that can display HTML/JavaScript; running a full-blown application on the PC would allow me to save the results to the filesystem. I've never done this, but it seems like in this day and age it shouldn't be too difficult. This would allow me to reuse much of my existing prototype implementation, but I would need some way of transferring the results (which would be stored in a JavaScript data structure) outside of the Web control to where the rest of the application could access it.
Reimplement the entire application using some GUI framework (I've used PyQt successfully before, although not on Windows). This approach is obviously less desirable than #1 due to the lack of reuse. However, it may be necessary if #1 isn't feasible.
Any recommendations for the best way to go? Ideally, I'm looking for a solution that can be run in a "portable" manner from a USB thumbdrive or similar.
Have you looked at HTML Applications (HTA)? They work in IE5+ and can use Windows Scripting Host to write to local drives and UNC shares...
Maybe you can use a portable web server with a scripting language on the server side. http://code.google.com/p/mongoose/ Mongoose, for example, you can run PHP, CGI, etc. .. scripts. Then, simply create a script to save a file to your hard drive. And let the rest of the application in the same manner.
Use a script to start the web server, and perhaps a portable web browser like K-Meleon to start the application http://kmeleon.sourceforge.net/ This is highly configurable. Or start the system explorer to your localhost URL.
The only problem may be that the user has to modify the firewall for the first time you run the server?
The simplest way to transform an in-proc COM server into an out-proc COM server is creating a COM+ application. What are the possible drawbacks of doing it this way?
I really can't think of any reason to create your own container or use a 3rd party one (if any exist) in favour of MTS/COM+. I mean it does all the things you'd want:
Lets you chose the distribution of
COM objects to container processes.
Lets you configure the account they
run under.
Monitors the container
processes and restarts if necessary
and can recycle them.
Even allows you
to host STA components in scenarios
where you need multiple threads
serviced by starting up multlple
worker processes. etc.
It's hard to imagine doing better than that without spending 6 months or more on it.
Turning the question inside out, I guess your anti-self might ask, "Why are there options besides the COM+ Server for an out-of-proc COM server? What advantages do these other hosting options provide?"
I don't have anything prepared, but I am imagining a table - with hosting options across the top as headers in various columns, and the particular attributes as headers in the rows. you might evaluate each hosting option on each different area or attribute.
The main difference I see is in the administrative model and capability, and in the flexibility. For example, hosting a COM server in a Windows Service gives you the windows service capabilities - auto start with OS boot; the admin UI associated to services.msc (both administrative/operational things), and the flexibility to add other interfaces into that service (flexibility).
I'm using boost::interprocess to communicates between two applications. When the two applications are launch by the same user, it works great.
When one of the application is a service, it fails.
I found that the shared media is in fact a file that is created in the "TMP" directory. So it fails because each application is creating his own file in his own "TMP" directory.
Maybe I'm not using it the good way for my particular purpose.
Does anybody having a clue of how to solve my problem?
Thanks a lot,
Nic
EDIT:
I tried using "managed_mapped_file". My problem is that the win32 implementation is calling "CreateFileMapping" without specifying a name for the object. In my special case, I think I need to specify something like "Global\MyMappedFile" so that both the application and the service can view the mapped file.
Here is something that works :
I'm using "boost::interprocess::managed_windows_shared_memory"
The name of my section is "Global\MySharedMemory"
I have to handle the case where the application is started and the service not. This is because even if my application can have read/write access to the shared memory, it can't create it. Only the service can. (In fact, the application can if and only if the user running it has a special privilege SeCreateGlobalPrivilege)
Maybe somebody can find a better way ;-)
Nic
it's something about the Window Stations and ACL. you need to modify the source to make it work between windows service and user application.
in vista and win7, services run at winsta0, but applications at winsta1. so you need to give a LPSECURITY_ATTRIBUTES with the right DACL.
In prior versions of Windows before Vista you could have a Windows Service interact with the current logged in desktop user to easy display information on the screen from the service. In Windows Vista Session 0 was added for security to isolate the services from the desktop. What is an easy way to communicate between a service and an application running outside of Session 0? So far I have gotten around this by using TCP/IP to communicate between the two but it seems to be kind of a sloppy way to do it.
You can use shared memory or named pipe to facilitate IPC as well. Conceptually this is similar to TCP/IP, but you don't have to worry about finding an unused port.
You have to make sure that the named objects you create are prefixed with "Global\" to allow them to be accessed by all sessions as described here.
AFAIK there is no way for a service to directly interact with the desktop any more.
Indeed, for security reasons it is no longer possible to communicate directly with the "desktop". What exactly is the "desktop" anyway, when you live in a machine with multiple active users + remote sessions?
The general way to solve the problem is to use service apps which communicate via some RPC mechanism (TCP/IP, IPC, .Net Remoting Channels over one of those, etc). Its kind of a pain, but I think the benefits are worth the change.
For the service to talk to the desktop, you're pretty much stuck with one of the RPC mechanisms. The .NET remoting mechanism (IpcServerChannel) isn't to hard to implement for this purpose.
Also with .NET a desktop application can send messages directly to the service with the ServiceController.ExecuteCommand. These commands are received by the service via ServiceBase.OnCustomCommand. This is even easier to do, and would be all you need if controlling the service is your only requirement.