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.
Related
Looking to create a web application that will modify a value in a database. When this occurs, I need a C# standalone application to recoginize this occurred and pull the value that was modified.
When the web app updates the DB, can I fire an event to the standalone app so that it can call a stored proc and pull in the new value? What is the most efficient approach to accomplish this task?
You could convert your standalone app to a WCF service then call the service (server-side) when the form that does your database update is posted.
If you don't want to convert your standalone app (or can't), a quick hack that would still use WCF would be a simple one-line WCF app that uses System.Diagnostics.Process.Start() to invoke your standalone app. Again, just invoke the service from your server-side logic after you've processed your database update.
I mention WCF as a solution because you're obviously already hosting your solution on IIS, that's exactly where you'd host your WCF app, and it's so darned simple to make WCF service calls from server-side code in .Net web apps.
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 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.
All,
I have been writting Windows Services for a while in C# deriving from ServiceBase.
So far my services are hosted in servers where they usually listen to message queues and process messages.
Is there a new way of creating such services in WCF ?
Thanks,
MK
Yes. Check out Windows Process Activation Services.
From what I understand, it's very much like how you used to host remoting objects under IIS, but with WAS, you don't need to involve the whole huge IIS stack like you used to.
Microsoft Message Queuing would seem to be what you'd want though there are some offshoots like BizTalk Server that may use similar stuff. Just to toss out an idea or two.
I've started using an open source project called TopShelf to easily create applications that run as either a Windows Service or a console app for debugging.
I've also been hearing a lot about Windows Server App Fabric. Here is a quick blurb from the App Fabric white paper.
AppFabric Hosting Services (originally code-named “Dublin”) doesn’t create some entirely new hosting infrastructure. Instead, it builds on what’s already provided by Internet Information Services (IIS) and Windows Process Activation Service (WAS). On this foundation, AppFabric Hosting Services adds extra capabilities for running and managing WCF services, including workflow services. Figure 7 illustrates this idea.
Windows App Fabric Home
I now have a scenario where I have 6 console apps on my server which each host a WCF service.
It's getting messy and I am now thinking about having a windows app (probably WPF) which hosts each service in a separate thread. This would mean there's a central place to manage the services as well.
I'm just wondering if anyone has implemented such an app or any advice before going forward?
I work on a system that has ~8 windows services, all hosting 1 WCF service each. To easily coordinate the execution of the services, we created a service coordinator application that when started, will start the other 8 services. This makes starting, stopping, and restarting the services really easily... and because they're windows services and not console applications, there's no desktop space lost.
The projects themselves are actually compiled as console applications, so that we can work on them easily during development (and also run them with a /debug argument to test them after they've been deployed). Maybe something like that will work for you.
...which hosts each service in a separate thread...
why? By default the WCF runtime is doing the threading for you. MSDN has a god starting point on this or have a look at Programming WCF Services by Juval.
To host multiple services in one thread you could check out this multi-service-host (using AppDomains for separation). I've done a very similar host before reading this and it is now hosting >100 services (started with 30 something) for thousands of users in a single operating system service.