I'm currently hosting a WCF service on an IIS 7.5.
Problem is I need to save data for the duration of the session (using static members) but the AppPool recycle keeps deleting all the cached data.
For my understanding my only solution is to self host the service.
I have no clue on how to do that and what are the pros and cons.
is this really my only option?
UPDATE
Looks like there was a different problem.
I changed hosting from IIS to self-hosting on a console application and I found a bug that was crashing the app. I'm guessing this was the reason for the loss of data and not the app pool recycling...
That does not seem like a good reason to migrate from IIS to Windows service . why not to disable app Pool recycling by
Idle Time-out(minutes) = 0
"Regular time Interval(minutes)" = 0
so it will never recycle
Also
Disable Recycling for configuration Changes = true
these settings live in advanced settings of AppPool
Update: how about
"Disable Overlapped Recycle" = true
AppPool Recycle settings
If this is the problem, I think you are storing the cache in memory. We can store the store the cache in disk,database or any your customized location. so there is no need move your application from IIS to self-host.
http://weblogs.asp.net/scottgu/archive/2010/01/27/extensible-output-caching-with-asp-net-4-vs-2010-and-net-4-0-series.aspx
Related
I have a .NET core web app (console) hosted in IIS on a Windows machine. In the ConfigureServices method in Startup.cs I have a line of code which sends me an email so that I know when the service is restarted. When a new release is being deployed, I get that email, understandably. But I also receive that email at random times when there was no apparent restart of the machine, the app, or of any IIS component. Would there be any other thing which would cause it to restart? I'm not sure why this is happening.
Thanks,
IIS has a lot of settings for AppPool reset, like e.g. at given time, etc. You can check the advanced settings of your application pool that is set up to run your program and see if there is anything suspicious. It might be some inactivity timeout e.g.
Its a newbie question, and I have just been learning WCF.
Can we change the service.config file of a WCF service on the fly without restarting the App Pool or doing the deployment?
Regards,
Bhavik
No, IIS will automatically detect the change to the config file and recycle the app pool automatically for you. So in a sense, the app pool does have to be recycled, but it handles it for you.
If you're hosting your services in IIS and you change the web.config file, the app pool will automatically recycle.
Assuming that the service is running and in use, and you didn't change the contract or anything - just some underlying logic. After publishing the service to IIS, do you have to restart IIS?
(If it matters, the InstanceContextMode is Single)
Are there any instances where you would/would not need to?
No. You don't need to restart IIS. What will happen is that ASP.NET will notice that the files have been modified and the AppDomain will be reloaded. If you have other web sites hosted on IIS - they won't be affected at all.
It is still recommended that you use a separate app pool for each web site.
Is there some mechanism in WCF that can be used to "pre-start / warm-up" WCF services that are hosted in IIS ?
- something like the warm-up scripts for SharePoint sites
I have the situation where servers are re-booted over night and next day there is a long delay while the WCF services spin-up. I can't change the time-out in various applications that use the services, so the first users are reporting errors in the morning when they go to use their applications
This is on Windows 2003 Server and IIS 6.0, so the IIS Application Pool Warm-Up Module, http://www.iis.net/download/applicationwarmup, as that's for IIS 7.5
NOTE: the module seems to have been temporarily withdrawn, see details on ... IIS Forum
I know you will don't like the answer and I think I repeat myself because it is not the first time I'm posting it. The way to warm-up anything in IIS prior to version 7.5 is using scheduled console application to ping your web site / services and warm them up. It is ugly solution but it works, it is easy and I saw it on every project which had to deal with this requirement.
WCF services should be instantly ready when they start. Just make sure the services are set to automatically start when the server boots.
You can use Windows Server AppFabric, it has Auto Stat feature to keep the service always on. But you need to be on IIS 7.5 to install App Fabric.
I have a web site and build a wcf service in it. I can run the code by calling it from a test page in the web site. The web site is ran by the vs2010 development server.
I do have IIS 7 but never use it.
Now I want to use the NetTcpBinding instead of BasicHttpBinding, everyone says it should be enabled in IIS, but how can this be done without using IIS and keeping everything in 1 project?
Thanks for any help
edit: A Windows service would be a solution, but that would mean adding a project to the solution, I really want to keep everything in 1 website, took me quite some time to get the service in the website in the first place.
This is about my own test version of the website, the production server is out of my reach. The service must be expanded by other developers later on it's bad if they have to run IIS just to test the service.
One way is to host the WCF service in a Windows Service - see How to: Host WCF in a Windows Service Using TCP for sample code.
Are you talking about how to develop without using IIS7 or how to put the service into a production environment without IIS7?
If it's the latter, then Stuart's answer is correct, but otherwise I would suggest that you start to develop using the web server that you will eventually be hosting the web site/service on.
Hosting in IIS7 has several advantages over hosting in a Windows Service such as fault tolerance and process isolation already built in.
Thanks for the replies guys, it looks like I have 3 options:
1. Host the service in a seperate project.
2. Host the website in IIS.
3. Use HTTPS, also secure.
PS: My development environment is very different from production :(
In development I have unit testing and in production there are old ASP pages, that I can't even acces, but sometimes must refer to...