I'm trying to get my ASP.NET application to automatically start whenever the application pool is running.
As per the lots and lots of references online I have already done the following:
Set the Application Pool to StartMode=AlwaysRunning
Set the site in question (that belongs to beforementioned Pool) to preloadEnabled=true
Install the Application Initialization feature to the Windows installation
Add the <applicationInitialization> node to the web.config's <system.webServer> node
The web application is based on Owin and has a simple log4net logging statement in it's Startup.Configuration() method. Now when restarting IIS I see that the w3svc.exe process is running, so I know the StartMode=AlwaysRunning is working. There are however no logging messages in the log file.
Navigating to any url (even a nonexisting one) in the application will start the app and add the log line.
Because of the actual work that's done in the startup of the application I really want the application to truly preload, but I seem to be unable to get it done.
Searching this site I have unfortunately not been able to find a solution.
Thanks in advance.
To answer my own question for future generations, it seems I was on the right track. To get the application to start in IIS10 (and I assume in IIS 8 as well) you only need the following three steps:
Set the Application Pool to StartMode=AlwaysRunning to make sure the w3svc.exe process is always running for the App Pool.
Set the site in question (that belongs to beforementioned Pool) to preloadEnabled=true
Install the Application Initialization feature to the Windows installation as per the instructions here.
One important thing to note is that if the Application Initialization task was not previously installed on the machine you must reboot the machine. This is what I missed the last time which led to quite some time wasted looking for other things :(
Anyway, setting up those three things will cause the app to actually go through it's initialization, which is especially useful if you want to setup some scheduling task (ea using the Quartz NuGet package).
Note by the way that if you setup auto initialization like above, the application will also automatically start after the shutdown timeout has expired and on application pool recycles.
Related
When one updates an ASP.NET MVC app in IIS the framework keeps the connections open. All responses to the connections are sent once IIS has caught up. Unfortunately this can take some time (eg. 15 seconds). Is there any way to update part of the app without affecting connections to another part.
An example use case: if you have a web chat app and you want to make a minor change to one section of the website, can it be done without 'pausing' the connections to the chat app.
If you can physically separate the code into its own folder, I.E. (c:/inetpub/wwwroot/myapp and then c:/inetpub/wwwroot/myapp/chatapp), you could define "chatapp" as its own application within the IIS website, and then create a new application pool just for that application. I had to do this before because the project I was running needed to have part of the IIS site on a different recycle schedule due to performance issues, also it crashed a lot so it was advantageous for it to have its own process so it didn't take everything else down with it :)
We are using IIS7 to host an asp.net web-based application.
In this environment administrators and developers can deploy code to the application on a regular basis.
The new code or app goes as a DLL to the ASP.NET bin folder. Upon deployment of the new DLL, IIS restarts the process, impacting (slowing down) all online users.
Is there a way to configure IIS to run the process in the background and once ready make the switch from old state into new without impacting the users?!
Thanks in advance for your feedback!
IIS already does this, that's what recycling is all about. IT's loading the DLL's while the old version of the application is still running. only after this is completed the recycling is complete.
However loading the DLL's is only part of getting web applications ready, there might also be initial loads like loading/caching the user db etc.
These actions are not part of the recycle process, they happen after all DLL's reloaded and the recycling is already completed.
A while back I ran into this issue with an application that had a huge startup time due to heavy db activity/caching during startup. So I was interested if there is some functionality that allows us to execute code before the recycle is marked as completed, so that the application is first considered recycled when everything is ready to run. Basically what I wanted is some kind of staging functionality.
I was in contact with the IIS team regarding this issue, sadly they told me that no such functionality exists, nor is it planned.
To solve this you could try do the following:
Use alternating deploys:
You setup 2 Websites with separate application pools. One of them is the LIVE website the other one is the STAGED website. If you want to deploy changed you simply deploy to the STAGED website. After everything is loaded/cached etc. you switch the URL settings of the web applications to reroute incoming requests from the LIVE to the STAGED one. So the LIVE one becomes the new STAGED and the other way around. The next deploy would then go to the new STAGED again and so on.
UPDATE
Apparently they have created a IIS Module that provides this functionality by now:
IIS Application Warm-Up Module for IIS 7.5
The IIS team has released the first beta test version of the
Application Warm-Up Module for IIS 7.5. This makes warming up your
applications even easier than previously described. Instead of writing
custom code, you specify the URLs of resources to execute before the
Web application accepts requests from the network. This warm-up occurs
during startup of the IIS service (if you configured the IIS
application pool as AlwaysRunning) and when an IIS worker process
recycles. During recycle, the old IIS worker process continues to
execute requests until the newly spawned worker process is fully
warmed up, so that applications experience no interruptions or other
issues due to unprimed caches. Note that this module works with any
version of ASP.NET, starting with version 2.0.
For more information, see Application Warm-Up on the IIS.net Web site.
For a walkthrough that illustrates how to use the warm-up feature, see
Getting Started with the IIS 7.5 Application Warm-Up Module on the
IIS.net Web site.
See:
http://www.asp.net/whitepapers/aspnet4
If you use ASP.NET 4 Auto Start feature:
You can still choose to auto-recycle the worker processes from time to
time. When you do that, though, the app will immediately restart and
your warm up code will execute (unlike today - where you have to wait
for the next request to-do that).
The main difference between Warm Up and Auto Start feature is that the Warm Up Module is part of the recycling process. Rather than blocking the application for requests, while running the init code.
Only thing you get by using the Auto Start feature is that you don't have to wait for a user to hit the page, which does not help your case.
See the Gu's blog post:
http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx
UPDATE 2:
Sadly the Warmup Module has been discontinued for IIS 7/7.5:
http://forums.iis.net/t/1176740.aspx
It will be part of IIS8 though (It's now called Application Initialization Module):
http://weblogs.asp.net/owscott/archive/2012/03/01/what-s-new-in-iis-8.aspx
UPDATE 3:
As pointed out in the comments the Warmup Module resurfaced for IIS 7.5 as Application Initialization Module for IIS 7.5 after IIS 8 was released:
http://www.iis.net/downloads/microsoft/application-initialization
The first part of ntziolis answer is a wee bit inaccurate. The worker process isn't being recycled or restarted, it just keeps running. If this were the case, then in shared pool environments you would have sites knocked out every time a new one was deployed.
When you deploy a new ASP.NET application it's the site's "Application Domain" within the worker process is torn down, not the pool process.
In addition pool recycling is a completely separate concept to deployment
At this point in time in the commercial life of ASP.NET, during a deployment, a site will be in an inconsistent state until all of the site is deployed. There is still no good story about this from Microsoft at this time for single site on a single server deployments.
This is why ASP.NET has the special App_Offline.htm page. It's there so you can enable that page, deploy and then turn it off.
The second part of ntziolis answer is nearly correct but you don't need two sites or two application pools. You just need two file system folders that switch between being the physical folders for the site...if you're on a single server and not behind a load balancer or ARR.
If your sites were on a web server behind a load-balancer or ARR then having two different sites would make sense, you could route requests from one site to the other and round-robin on each deploy.
Obviously if there is a large amount of user generated content (uploaded files and the like) then you'd map a virtual directory in your site to a common location for this data.
In larger scale deployments where your app is running across (for example) a load-balanced environment you can do more sophisticated deployments.
For related questions please see:
How Do I deploy an application to IIS while that web application is running
Publishing/uploading new DLL to IIS: website goes down whilst uploading
Is smooth deployment possible with componentized ASP.NET MVC apps?
Our web-application is on .net 1.1 and we have some legacy code that hangs-up IIS after every couple of days.
I was thinking about modifying machine.config settings to restart aspnet process after every couple of days, but the problem is it's going to kill existing sessions in process. Can I avoid it somehow.
Is there a better way to deal with this situation? right now client restarts IIS manually after every couple of days.
Thanks,
A
Edit:
If you have
- un-serializable objects in your session,
- cant work with sql-server
Then the good work around is to use "idleTimeout". It shuts down asp_net process if there is no activity on the server until the time specified. On the next request, it spawns asp_net process.
I suggest two things:
Configure the application to use SQL Server to store session data - this allows the session data to survive a restart of the web application
Configure the application pool to recycle worker processes periodically:
Of course, even better would be to update the web application to a recent framework version and fix at the same time the problem to prevent this from happening in the first place.
Do you actually store any type of data in Session? if you do, is it Serializable? If it is, just change the Web.config to use StateServer.
You just need to start ASP .NET State Service automatically by going to control panel--> administrative tools --> Services and setting up ASP .NET State Server to start automatically.
This will allow you to restart the aspnet_wp.exe process w/o losing session information; again, the only requirement is that the information you put in session is Serializable (which is likely the case or at least should be easy to do if your the code is not doing anything crazy)
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last month.
The community reviewed whether to reopen this question last month and left it closed:
Original close reason(s) were not resolved
Improve this question
Something strange happened on my local laptop: my web site that worked locally for a long isn't launched...
Trying to localize the problem I've created a simple web site with 'index.html' file only. It works fine under ASP.NET 2.0, but when I switched App Pool to use 4.0 - it stopped to work.
When I open web site in browser it shows the following error:
Service Unavailable
HTTP Error 503. The service is unavailable.
And causes App pool to stop work also... In the system event log in "applications" section I have:
The worker process failed to initialize correctly and therefore could not be started. The data is the error.
Please advise. Can't find anything related in Google... :(
P.S. I have VS2010, Windows Vista x64, last updates installed, VS SP1 is also installed...
I had to start the application pool that was set for my website and was automatically stopped on some error. (IIS (7.5 in my case)->Application Pools->Start stopped application pool.)
I've reinstalled .NET 64 - that helped.
P.S.
It seems like either some files in "C:/windows/Microsoft.net/Framework64/v4.0.30319/" folder or I removed them myself (VS sometimes complains on files in "ASP.NET Temporary files" and their deletion helps)... Probably I didn't pay attention that those folder not a temporary...
P.P.S.
In this case, why VS complained on files in "C:/windows/Microsoft.net/Framework64/v4.0.30319/" folder... ok, now it's hard to say.
Sounds like you forgot to enable .Net 4 extension on the IIS. Try finding and enabling it in ISAPI and CGI Restrictions
http://blogs.msdn.com/b/rakkimk/archive/2007/08/17/iis7-where-is-the-web-services-extensions-option-which-was-there-in-iis6.aspx
Based on the comment it might be that part of the framework was removed and in that case it might be wise to reinstall Framework 4 by first cleaning it up. Try this blog post which got a reference to a tool that automates cleaning up proccess http://blogs.msdn.com/b/astebner/archive/2008/08/28/8904493.aspx
There are subtle changes between ASP.NET 2.0 and 4.0 regarding application start up. For instance, you may not access the HttpContext object during the Application_Start event in ASP.NET 4.0. Do you have any code that might hide an exception being thrown because of this?
There are a few problems that may cause the AppPool to stop. One which I've run into myself is that any unhandled exception on a thread other than the request worker thread will cause the AppPool to eventually stop. This is not an immediate problem but eventually it will stop. The ASP.NET runtime keeps track on how frequently your app is failing and if it breaches that threshold the AppPool is stopped, taking down with it, any applications sharing that pool. A StackOverflowException or OutOfMemoryException will eventually have the same effect, these are critical errors and shouldn't be happening in your everyday production code.
I would review the changes between ASP.NET 2.0 and 4.0 and look for unhandled exceptions. You can also change the way Visual Studio handles exceptions (check under Debug > Exceptions) and break when they are thrown regardless if they are handled or not, this is a quick but very verbose way of finding any exceptions.
I'd recommend checking the security permissions of the folder used as the site's root. The launch of the worker process is probably failing because it can't read web.config in this folder.
If you're creating a new application in the IIS manager, by default it will create a new Application Pool with the same name. The problem is that this pool runs under a new identity named IIS APPPOOL\yourSiteName (in the Application Pools page this is listed generically as ApplicationPoolIdentity).
This identity does not exist until the pool is created, so the folder is not currently granting read access, and then the worker process fails since it has no access.
If you wish to use this identity you can use the Edit Permissions item on the site's context menu and access the Security tab, edit the folder's Security item directly via Explorer, or use tools like icacls.exe from the command line (recommended for repeatability).
You can also change the pool's identity to be Network Service or a specific user. I would strongly discourage the use of Local System as it grants too many permissions, and Local Service has other restrictions.
NOTE: If you are going to add the ApplicationPoolIdentity in the Security dialog, the IIS APPPOOL accounts don't appear if you use the Advanced/Find options. You have to manually type the whole "IIS APPPOOL\yourSiteName" string, then click the Check Names button to validate - if it is valid the dialog replaces your text with just yourAppName, underlined.
Go to IIS and change the Application Pool to DefaultAppPool for your web application.
I had to update my network credentials and havn't updated the "PhysicalPathCredential" for the application under IIS. That fixed.
my only problem was the Application Pool, which showed the stopped icon.
I pointed my Application to another AppPool and it's back working. Hope it helps.
I think in this case if you go to application pools under ur IIS. Look for the application pool on which you are running your website. I am sure it is stopped so just restart it and you will be good to go..
Backstory
Last month our development team created a new asp.net 3.5 application to place out on our production website. Once we had the work completed, we requested from the group that manages are server to copy the app out to our production site, and configure the virtual directory as a new application.
On 12/27/2010, two public 'Gineau Pigs' were selected to use the app, and it worked great.
On 12/30/2010, We received notification by internal staff, that when that staff member tried to access the application (this was the Business Process Owner) they recieved the 'Server Application Unavailable' message.
When I called the group that does our server support, I was told that it probably failed, because I didn't close the connections in my code. However, the same group went in and then created a separate app pool for this Extension Request application. It has had no issues since.
I did a little googling, since I do not like being blamed for things. I found that the 'Server Application Unavailable' message will also appear when you have multiple applications using different frameworks and you do not put them in different application pools.
Technical Details - Tree of our website structure
Main Website <-- ASP Classic
+-Virtual Directory(ExtensionRequest) <-- ASP 3.5
From our server support group:
'Reviewed server logs and website setup in IIS. Had to reset the application pool as it was not working properly. This corrected the website and it is now back online. We went ahead and created a application pool for the extension web so it is isolated from the main site pool. In the past we have seen other application do this when there is a connection being left open and the pool fills up. Would recommend reviewing site code to make sure no connections are being left open.'
The Real Question:
What really caused the failure? Isn't the connection being left open issue an ASP Classic issue? Wouldn't the ExtensionRequest application have to be used (more than twice) in the first place to have the connections left open? Is it more likely the failure is caused by them not bothering to setup the new Application in it's own App Pool in the first place?
Sorry for the long windedness
You'd really need to obtain and review the server's Application & System event and HTTPERR logs for the period the server was reporting these errors.
Without these it'd be hard speculate what was the root cause of the problem.
Update:
OP incorrectly tagged his question so this next section no longer applies. However I'll leave in place because I think the information is useful for those encountering these issues and perhaps thinking about migrating to IIS7.x.
You are correct that running two different .NET Framework's in the same application pool can cause these errors but that's something you'd tend to see on Windows 2003/IIS6, not Windows 2008/IIS7.
IIS7 uses a slightly different approach to specifying which .NET Framework version is loaded and it's determined by the Application pool's managedRunTimeVersion property. When requests are processed by IIS/ASP.NET the site's Handler Mapping's use a preCondition attribute to determine when to load the requisite handler (which is kind of like a script mapping in previous versions of IIS).
This mechanism prevents the incorrect runtime version being loaded into the application pool's worker process.
So if an application pool is configured to run .NET Framework version v4.0 only that version will load, even if your application is built against v2.0.
There's a great article on how this works here:
Achtung! IIS7 Preconditions
The section on Handlers about half way through explains why the dangers of accidentally loading the wrong .NET version into a pool are mitigated by the preCondition feature.
A Server Application Unavailable error usually means something catastrophic has happened (like loading the wrong ASP.NET version's ISAPI filter into an already running worker process).
Not closing SQL connections is unlikely to cause this type of serious error. You'd more than likely be seeing a yellow screen of death runtime errors if that were the case. Running out of SQL connections usually doesn't bend ASP.NET so out of shape that the whole service tops itself.
My prime suspect would be a permissions problem where the application pool identity was unable to correctly access the application folders. But it's just a hunch.
Again, what you need to do is get the Application & System event logs and the HTTPERR logs (they reside in %systemroot%\System32\LogFiles\HTTPERR. That will contain clues and facts about what went wrong.
Update 2:
On Windows 2003/IIS6, if you have two applications running different ASP.NET versions that reside in the same pool you will get this error. In my experience (I work for a web hoster) it is the primary cause of this infamous error page:
There's also a tell-tale event logged to the Application Event log:
Event Type: Error
Event Source: ASP.NET 2.0.50727.0
Event Category: None
Event ID: 1062
Date: 12/01/2011
Time: 12:31:43
User: N/A
Computer: KK-DEBUG
Description:
It is not possible to run two different versions of ASP.NET in the same
IIS process. Please use the IIS Administration Tool to reconfigure your
server to run the application in a separate process.
Whilst your root application may not be written in ASP.NET it's likely that something has triggered loading of a different version of the framework into your site's application pool.
there's a rogue web.config in the root...this will trigger ASP.NET to load
there's a wildcard mapping to ASP.NET 1.1 in the site script maps (less likely, but possible)
I'm inclined to think that your new application most certainly ended up in a pool where other sites or applications were running a different framework version. The only way to really find out is to obtain the Application event logs and look for the event shown above.
It's hard to tell; there could be many causes (too many resources used, calling outside of .NET caused something to crash, etc). I would look in the Event log and see if you can find something there.
If you're running different versions of .NET you definitely want separate pools. If you have the option, I would recommend separate pools for each application (even if in the same .NET version).
As far as "closing the connection" (I assume you mean the connection to the database). If you're creating "low level" connections (i.e. SqlConnection, SqlCommand) then make sure you're wrapping them in a "using" statement, otherwise your connection pool can fill up. In my experience though, you should receive regular .NET errors in this case. If you're using an ORM this shouldn't be an issue.
Edit:
If you can't find anything useful in the Event Log, you could try this: http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/