Everytime we publish our .NET app on Azure, all users are bein logged off and to sign in again, what our users won't understand. The user sessions are implemented using the SimpleMembership provider.
Is there any way to keep user sessions alive, even after we update our app?
I think you have misunderstood what publishing does. When you publish the application it will create a new instance of the w3wp.exe process. This is the web process where the application memory is stored (keeping it simple). If you publish you are creating a new instance and the old is getting destroyed.
All sessions will be lost.
For example, every time you publish the website, it will make a change to web.config. This will cause the application to unload and IIS to recycle.
Causes:
Web.config Changes
bin folder content change
Manual IIS
applicaiton pool recycle
If you need to keep your sessions alive then you should look at Session-State Modes
Related
I am getting this error after publishing my application:
The directory '/App_GlobalResources/' is not allowed because the application is precompiled.
My googling has yielded many recommendations to "restart my application" only I have no idea how to do this.
To restart your application you can open web.config in an editor, add a space somewhere, and save it. Please be aware that if you are using in-process session state the application pool will recycle, causing session state to be lost. However, this method has the benefit of not affecting web applications in other application pools.
If you want only this application to be affected, you could place it in its own application pool, or use one of the other session-state modes. Session State Modes
Refresh your website and Restart your application pool from IIS.
If you're developing locally, open a command prompt and type iisreset If you do this on a production machine you're going to take ALL the sites on that machine down during the reset. It's usually quick, but some sites can't have downtime during peak hours...
On a server, stop the app and app pool, then start them again.
Is there a way to recycle and afterwards reload an application pool?
My problem has been slow performance when logging in to my web application. I found out that the "Idle Time-out(minutes)" was sat to 20 by default. This caused the application to terminate when idle so that it can start up again on the next visit. After searching the web i found out that this value could be sat to 0 so it won't terminate. However, the first visit after recycling, an app pool have to create a new w3wp.exe worker process which is slow because the app pool needs to be created, ASP.NET or another framework needs to be loaded, and then the application needs to be loaded. Source right here
This means that every time the app recycles, the first visitor have to wait longer then the other visitors when logging in, doing some stuff and log out.
The web application is using the ISS from Dynamics AX 2009.
Sorry I thought you are working on IIS 7.5
But there was a beta for this in IIS7 actually.
I think you are looking something along the lines of this
A warmup module for IIS 7.5
"IIS Application Initialization for IIS 7.5 enables website administrators to improve the responsiveness of their Web sites by loading the Web applications before the first request arrives. By proactively loading and initializing all the dependencies such as database connections, compilation of ASP.NET code, and loading of modules, IT Professionals can ensure their Web sites are responsive at all times even if their Web sites use a custom request pipeline or if the Application Pool is recycled. While an application is being initialized, IIS can also be configured to return an alternate response such as static content as a placeholder or "splash page" until an application has completed its initialization tasks."
Download Link
http://www.iis.net/downloads/microsoft/application-initialization
And also have a look at this; which basically talks about using warm up classes which comes with ASPNET 4
http://weblogs.asp.net/gunnarpeipman/archive/2010/01/31/asp-net-4-0-how-to-use-application-warm-up-class.aspx
Checkout the suspend option.
IIS now has
Idle Time-out Action : Suspend setting
Suspending is just freezes the process and it is much more efficient than the destroying the process. Because it uses the same process and does not create another one after waking up.
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?
I can understand Appdomain concept, but small doubt is
One Process -> many application domain,
ok now,
when a application domain is created ? while making request or at time of hosting in IIS.
Again created Appdomain is One to one relationship with asp.net web Application..?
Could you please clear this, I want to know when appdomain created by CLR?
Thanks
karthikeyan
I'd say an AppDomain is created per ASP.NET web application, and is launched when the first request comes in and there is no AppDomain already instantiated for the current path.
Obviously there are IIS configurable idle times for when AppDomains in an AppPool (many to one) are being shut down.
when a application domain is created ?
I suppose when starting up IIS after you have set up virtual directories and uploaded your project files. Or maybe during the first incoming request.
Another thing to remember is that an application domain can be destroyed and recreated during operation. If your application has consumed too much server resources (memory), the application domain can be recycled and then recreated again.
When IIS6 starts up, it starts the App Pools. Each App Pool is a w3wp.exe process. Each process then creates its AppDomains for each associated ASP.NET application and triggers the Application start events on each.
One AppPool is a w3wp process and in this it makes AppDomain for each application on various scenarios like the Application's resources are more consumed (restart of appdomain) or the files like web.config etc are altered or a version of DLL is added.
I need to edit the web.config file on a live Sharepoint environment, but I'm unsure what will happen if I do (I want to output custom errors).
Will this cause the IIS6 worker process to recycle?
Will active users lose their session state because of this?
Or can I safely edit the file?
The application pool will restart and session state will be lost. Imagine each ASP.NET application (as defined in IIS) is a program on the desktop. Saving web.config will do something similar to closing the program and reopening it.
Yes. It will be recycled.
Yes. They will lose their session.
Yes. You can safely edit the file. I suggest you to read this MSDN article : Working with web.config Files in Windows SharePoint Services
Also if Session state is configured as out-of-process (database or service) then recycling the app pool won't lose any session state. This is as true for Sharepoint as it is for vanilla ASP.Net.
When you edit the web.config, It will restart the AppDomain (NOT AppPool) of that web application and clears the all occupied resources and memory. So other web applications running under that App Pool will not be affected. Also it will clear the sessions (in-proc) and memory cache.
As already mentioned by some people: the application pool of the site in IIS will restart (this typically takes a couple of seconds). As a result the next page request(s) will be slower (since nothing will be cached anymore). Also the session state of the users will be lost; BUT in WSS session state is not used by default, in MOSS it is used by InfoPath Form Services. So it could be that you don't have big issues related to losing session state.
On the other side; to overcome those issues: what is typically done is to create a SharePoint Solution (WSP) that deploys and starts a Timer Job to make the changes to the web.config from code (using the SPWebConfigModification class of the Object Model). The nice thing is that you can schedule the execution of the change, so your users won't notice it.