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.
Related
I want to know why we should use Webapi SelfHosted and where it is useful?
Let say we have a console application and selfhosted webapi what is the benefit?
The main benefit is that you do not have to set up IIS and websites when you deploy it. This way, you can simplify the deployment of the service and make it easier for administrators that are not experienced with IIS to install it. Typically, you would not use a Console application for self-hosting an API in a real-world-scenario, but a Windows service that runs whenever the computer is running - without requiring a user to be logged on.
In a less common scenario, you could use a self-hosted Web API for inter-process communication. If you want to exchange data between some processes either on the same or on separate machines, you could host a Web API in the application that provides the data and access it from another one.
I'm making an application in C# with VS 2012 that checks a database every 15 seconds and perform some actions when it finds data. Right now I've created a Console Application so I can debug it easely but during relese this application needs to run in a IIS server.
How can I do that? I've read this question but it looks like some sort of workaround because to run it I need to perform these steps. Right now I'm reading the docs about Windows Service Application, Is this the right way?
EDIT Sorry but I've never used Windows server before, so as people pointed out IIS is only a web server, the thing I need to do is run my application in a Windows Server environment
IIS is a web-server and accordingly it should be used for hosting web applications.
Develop a windows service which does the job of checking the database in intervals and invoke a web service (which you can host in IIS)
If your application is performing some data query and manipulation on the server then I would recommend the approach to host it in a windows service.
Some advantages to this are:
The service will start and run independently of a user logging into the server.
You can configure the service to recover should it experience an exception (ideally not!).
The service will start automatically (if configured) when the server restarts.
You can configure which user group (or user) the service should run under so you have a more granual approach to security.
As it's running as a seperate process, you can monitor its memory and processor utilisation.
Debugging is slightly more cumbersome but not difficult, one approach I've used is to install the service locally, start it and then attach to it via the debugger. This question describes another approach I've also used.
I am new to WCF and i am designing a project in which i want to run a crawler program (coded in c#) which crawlers some websites and it stores the crawled data in the tables of database (sql server db). I want that crawler runs repeatedly after 30 minutes and updated the database.
I want to then use the service on my hosted platform so that i can use the data from tables in web form (i.e. .aspx page)
Is it okay to use WCF for this purpose ?
Please suggest me how to move on ?
Thanks
Windows Communication Foundation (WCF) is responsible for communication between 2 points with different channel technology. you will use WCF if you want to send/receive some data between two point regardless channel technology (TCP/UDP/NetPipe/MSMQ , ...)
But you first need to design you crawler application which is configured to fetch data from your target web sites, then you need to design a schedular application using
http://quartznet.sourceforge.net/
to run your crawlers.
after running and storing your web pages you can use WCF if you need to do replication or synchronization with center server but it is optional
You could use a WCF service to do this but I would go for another setup:
I'd build a Windows application that is scheduled to run every 30 minutes by the Windows Task Scheduler. A simple console application might be fine.
I'd use a Web application (possibly ASP MVC) to query the database.
As you can see there is no need to use WCF at all.
An exception can/must be made when the server is not yours but you are using a hosting provider who doesn't allow you to schedule a Windows task. In that case you might want to run the crawling process by hand through the web application and have it repeat itself after 30 minutes.
Some hosting providers do allow the scheduling of tasks but in a different way so it might be worth to investigate.
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.