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
Related
WCF service can be hosted both in IIS and in Windows service. What are differences? Is there any benefit hosting in Windows service than IIS?
Check out the documentation: https://msdn.microsoft.com/en-us/library/ms730158%28v=vs.110%29.aspx
It is awesome!
And the answer to your questions depends on what kind of application you are building and other requirements on the application/environment...!
Here are some differences (Features of IIS.. Copied from the link provided by #Jocke).
You lose all of the features of IIS (logging, application pool scaling, throttling/config of your site, etc.)...
You have to build every single feature that you want yourself HttpContext?
You lose that since ASP.NET provides that for you. So, I could see that making things like authentication much harder WebDeploy?
IIS has some nice specific features in 8 about handling requests and warming up the service (self-hosted does not)
IIS has the ability to run multiple concurrent sites with applications and virtual directories to advanced topics like load balancing and remote deployments.
If your WCF serivce is self-contained, like a data service, just host it in IIS. Drawback: you'll have to install and configure IIS.
If your WCF service is more of an API or IPC mechanism, used to let other applications talk to your application, it makes more sense to let your application self-host the WCF service, and for that a Windows Service usually is the more sensible approach. Drawbacks: you'll have to install your application as Windows Service, and configure that your application may listen on its configured port.
Please note that self-hosting is not constrained to Windows Services.
We have lot of applications running on our server that uses Enterprise Library to log. We want to develop a logging service that can serve as a common logging service all these applications can call and that way they will all be logging to a single log file and a central logger will control all the configuration. I was looking for some design solutions for what this service should look like. Should it be a windows service with a .net remoting or WCF interface exposed?
I would recommend using .NET Remoting with an IPC channel.
Here is a tutorial/example: http://www.codeguru.com/csharp/csharp/cs_syntax/remoting/article.php/c9251/NET-Remoting-Using-a-New-IPC-Channel.htm
I've used this method for interprocess communication between several apps/services many times.
Also, have you looked into using something like log4net? It's very powerful.
http://logging.apache.org/log4net/
I'm not too familiar with EntLib's logging code, but log4net is great.
Another option would be to just build a single shared assembly/project that all your apps utilize - that way you don't need a service running in the background, but the code is the same across all apps.
Enterprise Library has a Remote Logging Service that you could use: http://nuget.org/packages/EnterpriseLibrary.Logging.Service/.
It was originally released with the Silverlight Integration Pack but is just a WCF service.
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 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.