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.
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'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 have a C# application that needs to always be running. I originally planned on making this a windows service but I now have a requirement to make the application host a web admin console.
I haven't played with IIS in quite a few years so my question is this:
What would you recommend I use?
I've thought about making a windows service and embedding a web server such as Cassini but so far I'm not very happy with the open source web servers I've looked at.
Can IIS handle this? Do people use it for this type of scenario, and if so how?
This sounds like a job for two separate projects.
One is the original Windows Service. Windows Services are well suited for what you're doing.
The second is the Web Project that will be used to administer the Windows Service. This is the part that runs in IIS.
It depends on what you mean by always running. An ASP.NET web application deployed in IIS could very well be unloaded by the web server if there aren't any requests for certain amount of time killing all background threads. So if you want an ever running background thread it would be better suited to use a Windows Service. As far as the web admin is concerned, well, here you don't have much choice: ASP.NET in IIS. In order to do something useful those two applications should be able to find a common language to talk. So you could use a database to store the results into which could be used by both applications.
IIS will run your app on first request, not on server boot. So you will still need to run a service to ensure your app is always running.
You can use IIS as a webserver for your web admin part, and link your ASP.net app with your service by means of a configuration database (easy) or webservices (a little more tricky).
Windows and Web services are two very different creatures. A web service will expose external methods that you can implement against an application, while a windows service is an entity within itself. If you're planning on using this service on a timed interval to perform an operation, a Windows service would be the right way to go. If you use a web service, you will need to invoke the method you wish to run from a secondary application.
If you need to queue commands against your windows service, you could always create a database that was accessible by both your website and your windows service. This way you could send commands and query data between the two. Placing a web service in to serve as an intermidary between the two may be overkill.
Is it possible to create a C# EXE or Windows Service that can process Web Service requests? Obviously, some sort of embedded, probably limited, web server would have to be part of the EXE/service. The EXE/service would not have to rely on IIS being installed. Preferably, the embedded web service could handle HTTPS/SSL type connections.
The scenario is this: customer wants to install a small agent (a windows service) on their corporate machines. The agent would have two primary tasks: 1) monitor the system over time and gather certain pieces of data and 2) respond to web service requests (SOAP -v- REST is still be haggled about) for data gathering or system change purposes. The customer likes the idea of web service APIs so that any number of clients (in any language) can be written to tap into the various agents running on the corporate machines. They want the installation to be relatively painless (install .NET, some assemblies, a service, modify the Windows firewall, start the service) without requiring IIS to be installed and configured.
I know that I can do this with Delphi. But the customer would prefer to have this done in C# if possible.
Any suggestions?
Yes, it's possible, you may want to have a look at WCF and Self Hosting.
Yes, it is possible (and fairly easy).
Here is a CodeProject article showing how to make a basic HTTP server in C#. This could easily be put in a standalone EXE or service, and used as a web service.
One technology you might want to check out is WCF. WCF can be a bit of a pain to get into but there's a great screencast over at DNRTV by Keith Elder that shows how to get started with WCF in a very simple fashion.
http://www.dnrtv.com/default.aspx?showNum=135
You could take a look at HttpListener in the .Net framework.
I would highly recommend WCF. It would fit very well into a product like you are describing. There are a good number of books available.
Sure, you can do that. Be sure to change the Output Type of the project to Console Application. Then, in your Main function, add a string[] parameter. Off of some switch that you receive on the command line, you can branch to ServiceBase.Run to run as a Windows Service or branch to some other code to run a console application.
This question is somewhat older but since I needed something similar some time ago it felt like this question is still relevant.
I wrote a small Rest-API with NancyFx and OWIN. OWIN is a standard interface between .Net applications and web servers. With OWIN it is possible to create a self-hosted WEB-API. Nancy on the other hand is
a lightweight, low-ceremony, framework for building HTTP based
services on .NET ยน
The combination of those two makes it possible to create a self-hosted C# Web service.
I am quite sure that there are many more possibilities to create something like this by now but since I used it like this I thought the Information might be useful to someone.
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