I have a C# Windows application which runs a service. I would like to leverage PowerShell in order to offer a command line management interface for administering my running service.
From my point of view, I am trying to offer the same administrative interface a la Exchange 2007.
Do you have any suggestion or sample code on how to start/design the management cmdlets in order "connect" to the running service to query or send administrative commands?
How can I access service's internal runtime state from powershell command line? For example I would like to implement a cmdlet called Get-ConnectionsInfo to find out how many outbound connections my Windows service is using when the cmdlet is executed.
A practical example or web link to an example would be more than welcomed.
Thanks,
Robert
A solution would be for your Windows Service to expose an administrative interface through WCF. Your PowerShell commands would use this WCF service to pull out information and make the Windows Service perform actions.
The key here is to start by writting an API that you can access from .Net, then you can easily wrap the calls to this API into a DLL that exposes classes that are PowerShell cmdlets. If you want someone to be able to administer your service remotely then I think probably the best thing is to create either a webservice or WCF Service that does this and then you can wrap that in PowerShell. If you have a look on codeplex you will find some examples of administer remote web based services like GoGrid and SQL Data Services that will give you some sample code to get you started.
Another way of exposing the internal state of the Windows Service came to mind. You could expose information through WMI which can be consumed from PowerShell or your PowerShell commands.
I'm not sure if you are able to tell your service to perform actions through WMI but you would at least be able to pull out state.
A third alternative might be to make the Windows Service be a PowerShell content provider. However I have never made one myself so I'm not sure if they're suitable for hosting in a Windows Service, since the service might not be running all the time.
Related
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 service that runs in a privileged mode but occasionally the user who is unprivileged will need to configure it (selecting relevant hardware etc). I need to provide a simple visual interface for this.
As services can't interact with the visual environment by creating windows etc, I'm wandering what the best way to provide this interface is. Are there any good methods or patterns that people have used in the past?
Cheers,
Richard
I have used WCF to provide a very similar interface in the past. It has several advantages but all normal IPC are also available to you. If it is going to be on the same machine you can allow a service to interact with the desktop.
add a wcf self hosted service to your windows service.
publish in this service the method required, and create a client app to call this methods.
I am going to be coding up a windows service to add users to a computer (users with no rights, ie just for authentication). (As a side note, I plan to use this method.)
I want to be able to call this windows service from another computer.
How is this done? Is this a tall order? Would I be better off just creating a Web Service and hosting it in IIS?
I have some WCF services hosted in IIS on the calling computer (they will do the calling to the proposed windows service). I have found that Hosting in IIS is somewhat problematic, so I would rather not have a second IIS instance to manage unless I need to.
(I will be using Visual Studio 2008 SP1, C# and Windows Server 2003 (for both caller and service host).
Thanks for the help
If you are thinking of hosting a web service in IIS just to communicate with an NT-service on that same machine, that is definitely more trouble than it is worth in this case.
As other answers have indicated you can make a WCF service with the operations you need and host that within the same NT-service that you want to interact with. You can easily secure this with certificates, or user accounts to make sure it is only controlled by the right people/machines.
If you need to control the NT-service itself, there are existing programs such as sc.exe to start, stop, configure, or query the status of your NT-service remotely.
However, you may want to consider seeking a solution without the overhead of creating an custom NT-service and a custom WCF service to interact with it. If you do, the Net User commands (sorry no link - new user limitation) or the AddUsers (see kb 199878/en-us) utility may be sufficient. If your remote "controller" can invoke these commands directly against the target machine you may not have to create any custom software address this need. Additionally you would have less software to maintain and administer on the target machine. You would just be using the built-in OS capabilities and admin utilities.
Finally, you will need to think about the security aspect, NT-services and IIS are usually run under very restricted accounts, many auditors would flip-out over any service running with sufficient permission to create or modify users locally, and especially on other machines. You'll want to make sure that the service could never be used to create users that do have more than the "authenticate" permission you indicated.
Edit: The net user command may not work against another machine's local users, but check out. pspasswd that along with PsExec to create users, should do what you need remotely.
Simply host a WCF service in the Windows Service. You'll then be able to call it remotely.
You can host a WCF service inside a Windows service. Take a look at the TCP binding (NetTcpBinding class). Both client and server will have to use WCF, but that doesn't sound like it will be an issue with your implementation.
Also, the section entitled "Hosting in Windows Services" in this MSDN article provides a walk-through of the process
If the windows service publishes a remoting interface then it can be accessed via that remoting interface.
Otherwise it's the same as accessing any other process running on a remote machine except that there may be some tools (e.g., sc) with built in support for executing against a remote machine (barring firewall complications).
Any IPC mechanisms applies; sockets, web services, remoting, etc...
You could expose a WCF service directly from your windows service. When you start up your windows service, in addition to spinning up any other background processes, you could create an instance of ServiceHost<T> for your service implementation. This would allow you to not only provide WCF access, but also avoid the extra instance of IIS like you requested, and provide TCP, Named Pipes, and WsHttp endpoints. This should give you some nice flexibility in the performance tuning arena, since it sounds like this service will be consumed internally on your network, rather than externally.
You could create a WCF service which will talk to your Windows service on the remote box. Host the WCF component in IIS (or however you'd like so that you can communicate with it) and then call the WCF component from your remote machine.
I have written a windows service in C# that gathers performance, disk and memory information and writes it to the EventLog. It is enabled as a network service. What I would like to do is be able to gather this information from a remote location. This service will run at various client machines and I would like to retrieve this information periodically (once a day) and store them in a database table. I am confused as to how one can query a windows service over a network. In other words, what exactly makes the service a "Network Service"?
I do not want the service to directly connect to my database and write this information. But I would like to initiate it from a remote machine, retreive the information and then write that information to my database table.
I was unable to find any tutorial that illustrates a networked windows service. Most of them covered writing to event logs and I am pretty much stuck there.
Is this doable, are there any suggestions about how this sort of stuff is done?
If the other suggestions to move over to WCF Web services are not an option, you can do allot with Custom commands in a windows service without having to resort to remoting.
Effectively you can send an integer between 128 & 256 and then have your service execute whatever code you need it to when it receives that command, like sending all the information to your database or web service.
You will be able to initiate it from your side as and when you need to while the service happily trundles along on the client machines.
Take a look at this code project article for an example: Creating a Basic Windows Service in C#
Take a look at the OnCustomCammand method.
Here's another example article from Microsoft: Communicate With Windows Services
Use WCF to enable some form of a RESTful Web Service.
See wcf-getting-started on MSDN, and specially A Guide to Designing and Building RESTful Web Services with WCF.
AFAIK 'Network Service' just means that it is running under the "Network Service" account which has a different set of permission than the 'Local Service' or 'System' accounts.
To expose a service to another machine on the network however (apart from the standard STOP, START, RESTART functionality that you get through the services snap-in - services.msc) you will need to create your service using something like Remoting, Webservices or most ideally as gimel mentioned WCF.
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