I currently have a WCF Service Library which will be started through a Console Application acting as ServiceHost. The ServiceHost starts the service and then waits with Console.ReadLine() for the "quit" command. If i do "Console.WriteLine();" in the service this will be printed to the ServiceHosts Console of course. The Service prints some information when the clients connect for example.
Is it possible to have the ServiceHost converted to a real Windows Service (to start up when the machine boots without console window) and attach or detach a command prompt (cmd.exe) or another Console Application to it when needed? For example if I want so see which clients connect from now on?
Thanks in advance!
EDIT: I really woudln't like to write and read a LogFile.
Only if you run on an old operating system, XP is the last one that allows a service to interact with the desktop. You'll need to write a separate app that can run on the user's desktop. Talk to the service through, well, WCF. Or a named pipe or socket.
You would be far better off exposing the properties and methods you wish to access on the WCF Service and then creating a console or desktop application that allowed you to access the properties via the WCF service. As you are not limited to a single End Point or interface you could easily implement some form of authentication and use netTcp binding between applications.
Related
I have a small tray app which should inform the user about start and stop of an execution of an other process running under local system account. The process running with local system account is called by another service (not owned by me). "My service process" is always running just for a short time. So I can not implement a wcf callback handling. Everything works fine on my machine. But it is not running at the customer side.
The problem (exception) which occurs at the customer side is something like "there is no endpoint listening on net.pipe..."
But the tray is running.
I created a test app (console) to communicate with the tray. This works fine.
If I start this test app with psexec -I ... to run it with a local system account it is also running.
I have no idea about possible reasons and so I have two questions:
is it "allowed" to host a wcf service in a tray app (running in user context) and call it by a process running in local system account?
if yes, is there a possible policy/security setting which can prevent this functionality?
The only workaround I could think off is to create a helper service which I can use as some kind of a broker (connect from tray with a callback interface which could be used by the other process). But this seems to be a big overhead...
The answer is, it is not possible.
The reason is explained here: Connecting via named pipe from windows service (session#0) to desktop app (session #1)
It looks like my test was successful, because psexec was still running in session #1.
My implementation is now using the already above described workaround
I have a WCF service hosted in a Windows service.
This service the WCF have one metohd and in this method I have one important line :
Process Browser = Process.Start("iexplore.exe", hostUrl);
I install Windows service as local system, but when I'm trying to invoke that method, everything seems to execute, except that one important line... and IE didn't open.
I would like to add that the method itself is not in the service itself but in one of the service dll reference
Any idea why?
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/63a7d1ec-7077-489a-a250-f7422f04317b
" in order to get the service to actually show the UI, you'd have to set the service in Computer Management to allow it to interact with the desktop. In the services window in computer management, go to the properties of your service, and on the Log On tab, check "Allow service to interact with desktop" "
Since Windows Vista MS has been adding lots of security-related changed esp. in the area what Windows Services can/can't do. Anything "desktop-like" (printing, accessing network shares, using Office Interop etc.) is harder and harder to get working.
You should rethink your design since IMHO any "server-like process" (for example a WCF service) can be accessed in parallel by multiple requests and thus should NOT use processes which are NOT designed for this type of interaction... what happens if your webservice starts multiple IE instances that way ? Will IE behave as you need/expect it ?
IF you really really MUST do it this way you should have
a normal desktop process hosting the WCF service
OR
two processes, one your Windows Service and one running as a normal desktop process dealing with IE... these two process communicate via IPC
Under what user is the service running? Try running it under the currently logged in user, with privileges to interact with the desktop and see if that helps.
In general, its not a great idea to have services launching GUI processes. For example, what if no one is logged on. What if many people are logged on? Should it open in all sessions... etc. Have you considered exposing a simple (e.g. Net.NamedPipes) endpoint on your service, and writing a small client UI to interact with it?
I've made a console application that I will turn into Windows Service.
I want to have a WinForm GUI (exe file) for that Service, so I will be able to see all the information inside the Windows Service and control it in my WinForm GUI.
For example, if the windows service counts and saves the time passed (or any other information) I want to have access to it in my GUI (I want to see it live).
As well as activating methods inside my Windows Service.
I hope I've made myself clear.
My recommendation would be to use WCF for this. Your service could be a WCF host, and your client could connect to it.
This provides a fairly straightforward, clean way to "control" and inspect the service as much as required.
The ServiceController will only give you access to methods like Start, Stop.
To access any method, you will need to use some form of Inter-process Communication.
As suggested by Reed, WCF is one way...or you can try IPC through Named Pipes, remoting, etc.
I just wanted some input on a project that I'm working on. Basically, I'm creating a service that monitors and processes new files in a directory specified by a configuration file and other parameters through the command line. It should also output text via the command line, i.e. when a user types in '-help' it will display it's usage. A goal is to also make it so that the user can change the configuration file on the fly, so the service will constantly monitor the config file for changes and adjust accordingly.
The challenge I'm seeing is trying to consolidate the ability to enter commands through the command line, display output, as if it were a console app, and have the service be able process these commands while it is running in the Service Control Manager. So far in my research, the solutions I've stumbled upon seem to show how to create a Windows Service App that can also run as a console app, but it either operates as one or the other, not both. Any suggestions or input is appreciated.
UPDATE:
Thank you all for your suggestions, I did some reading on various Windows supported IPC mechanisms. I boiled my options down to File Mapping, Named Pipes and RPC. I'm assuming for now that the Windows Service app and Helper Console app will be on the same computer and will not need to communicate over a network. I'll be looking at Named Pipes first.
The service needs to offer a possibility to communicate with it, but this can't be done directly, it has to be done by some sort of IPC (inter process communication), this could be .net Remoting, WCF, tcp/ip. You will have to write a helper program that parses the command line and uses this IPC to send the commands to the service, which can act appropiately on receiving it.
I would write a console app that sends requests to the service and displays its responses. If you wanted to be clever, you could include both parts in the same executable. I can't think of any way to make the service write to and read from the console while it's running as a service.
I have a program starting up through the registry, but I want it to start up more efficiently. So I asked some questions and I have found out that a windows service is the way forward. I have looked at how to make a windows service but I have not found any answers for what I need.
I am trying to create a checkbox on my application so that when it is checked it adds a service to start up my application when the person logs in, and when it is not checked it deletes the service.
Any help would be appreciated,
Thanks.
This is not the correct way. Services cannot find out when a user logs in since Vista. In your prior thread you got the advice to create two programs, although that wasn't explicitly stated. A service that runs after the machine boots and a user interface that allows the user to communicate with the service after she logs in.
You'll need an inter-process communication mechanism to get them to talk to each other. Named pipes, a socket, Remoting or WCF will work.
Read the MSDN Library docs on the ServiceBase class, that's what you'll need to create a service.