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.
Related
I'm new to windows services. I want to make a windows service which work as an execution engine for my software. Currently I am passing a XAML file path to my execution engine to start execution. Now i wanted to create a windows service to act as an execution engine. Is there any way to invoke my Run method with File path (as an argument) in a running service?
As others have mentioned, the best way to do this is probably by using a framework that supports some form of communication mechanism. Again as others have already mentioned WCF is great for this.
As an initial pass what I would do would is to use a self-hosted WCF service (this Code Project entry provides an example on how to do this: https://www.codeproject.com/Articles/650869/Creating-a-Self-Hosted-WCF-Service). The overhead is that you will have to learn WCF basics to get this going, although WCF is very easy to get started with.
In this context what self-hosted WCF Service means is that you are creating the hosting code yourself, instead of hosting in another service/location. For example, you can also host a WCF Service in IIS.
In the example the author is creating a SvcHost object and running it in a console application. The console application is user interactive, however, this should be easily translated to a Windows Service.
Hope this helps.
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 have a window desktop application, developed in C#.NET (.NET framework 4.0), but now I want to convert it into window services. There is one Window Form in desktop application. How is it possible? Any code or helping link is welcomed.
Thanks
It entirely depends upon what the application does. The main thing you have to remember is that when an app is running as a service it cannot have any user interaction, as it runs unattended.
Take a look at this for more background:
Introduction to Windows Service Applications
Or look at using SrvStart (a freeware utility) to run an existing app as a service:
Using SrvStart to Run Any Application as a Windows Service
There are also commercial tools that can convert Windows apps to run as services such as:
FireDaemon
AlwaysUp
Once an app is running as a service all comunication between a seprate UI presentation app is cross process - so you need to manage that. Depending on your skill set probably the easiest way to do that today is WCF. Your first step is to define the interface between the GUI client application and the service (what calls does GUI need to make on the serivice, are they oneway or duplex (return data), does the service need to trigger events client side (which requires a callback interface)? etc).
Once that is decided you can go ahead and start building your WCF service. That is a dll that needs to be hosted - in your case by a service host - this is quite straight forward and there is plenty on infomation available about that (basically just a few lines of boiler plate code and then run a utility to register the service). It is useful to test your server using a Command line host in place of the service host (easier to debug etc) - so worth while setting up 2 host projects (one service, one cmd line).
I've personally never tried a form client with a WCF service - if your form is simple you might find it easier to dev your client in WPF. The client uses the interface you defined to make calls on the server and the WCF generated proxy code impliments that interface to manage the tranport accross process (or machine). WCF is very flexible via configuration files about the transport to be used (namedpipes, tcp, http etc). Bon courage!
Ricibob's answer is correct. I started the way he suggested. I needed WCF Data Services because I had to edit some data in the db. And I got stuck when I found out that WCF Data Services doesn't support Enums. My business objects widely used enums and now I don't know what to do.
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.
I am building an app that allows users to execute some commands on a computer by sending them through email. The server will monitor (pull) one or more email accounts and start a communication session. Some authentication is also involved. I am using the latest and greatest .net technologies.
I am thinking to expose the server as a service but then I cannot have a GUI to allow the user to configure things like passwords and email accounts. How can I separate these?
And second, the commands will be pluginable and should provide their own GUI. How can I incorporate this? The server process should be able to use the command functionality and the GUI process should allow for customization.
I have used WCF, which is Microsoft's current technology for implementing web services and/or SOA. You would create a desktop client or webpage that makes calls to the WCF service. The WCF service(s) would be your server component, and the desktop client or webpage would be your user frontend.
It's mainly not a question of how to make service itself. And communication protocol is not the main issue -- with WCF you can expose your application methods via spectre of protocols. It's merely a question of application configuration.
Main question here is how do you like to implement GUI. If your application is normal windows service, then it can't have built-in GUI. Just because service should not have it. So you'll need separate GUI application. Options:
GUI is standalone .NET application that somehow communicates with your service. Let's say via WCF. In this case plugins should also be implemented in two parts: plugin for service and plugin for GUI. I think, it would be too complex to support.
Modification of 1st variant. Both service and GUI are packed in one executable. It looks in what mode it's started (service or standalone) and either monitors mail or shows GUI. Since this is one application, the configuration is also the same. So you will have single registry for plugins. I assume, that in GUI mode application will search for started service and configure it. Drawback - GUI could be run only locally.
You make a sort of "transferrable" GUI - service sends GUI to simple client, which shows it. In this case you have one place for all app code (service and GUI), but it's executed in part in service, in part in client software. But you also need such universal client software.
Thinking a little more about variant 3 we see that solution already exists - it is web technologies. It would be simplest to implement your service as part a web site. And GUI would be another part. If you are unfamiliar with HTML and Javascript you can implement GUI using Silverlight.
In fact, you can host ASP.NET right in your service. Here is the good explanation. But I afraid it adds unnecessary complexity