I'm currently in the middle of a large ASP.NET application with many WCF services. Currently in IIS, all these services are listed under one application called Services.
I'm concerned that with more being added to our servers all the time and the uptake of our application increases, this is probably not the best way to manage things. Currently the VS project has a "web service host web application", which contains all the .svc files to be hosted. The advantage of having it all in one is the obvious use of the web.config for all services. The disadvantage is that if we need to do an update or deal with a critical issue, all our services are brought down at once, rather than those few that we know the problem is located.
I'm wondering if it is possible to keep this "host web application", but split the application into different "sub-applications" using separate Application Pools and allow VS to publish to individual services. I don't know if splitting it into folders under the "host web application" and hosting these as individual applications will work.
Or is the only way to have lots of host applications to run in separate application pools?
TL;DR; Should I split our application with all services into 5-6 applications with a few services?
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 have created 2 WCF service libraries in a solution. I have also created two windows services which will host the two wcf services.
these wcf services communicate with eachother. one gets requests and is reusable service for other systems, the other service sends requests to this service and takes requests from the UI.
I have created installers for the window services too.
I want to understand the build script tasks which I need to include which I will call during each time I want to deploy this solution to the server?
Should I delete all of the windows services and install again with new DLLs?
What is the best way
There is no need to delete the windows services. You can stop the service, replace the service executable and all the assemblies used by your service and restart the service. This is what I've always done, and I've never run into problems.
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.
Well i want to know how many architecture approaches we can use in asp.net web application. i was asked about it. i told him that i use a appcode for dal and bal and the presentation layer. but he was not convince. basically i want to ask what web application architecture an asp.net web application guru would use keeping in mind the different metrics ( i am talking minus web services or any SOA thing)
Classic 2 tiers app
Is the one you described: You have the client (the browser) connecting to the server (can be configured as several servers) running an ASP app with your AppCode classes acceding the database in the local network (or same machine)
n-tiers app
You can use WCF to delived n-tiers app where the client connect to the server and the server connect to WCF services running on the same server or in several other servers
Note: This is the short story and the naming is subject to debate.
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.