I'm a beginner in ASP.NET 2.0.Probably this could sound too basic and stupid issue for someone expert in the ASP.NET.But this is giving me sleepless nights.
Basically i have developed a simple multilingual website with a master page and content pages which fills inside the content place holder portions of the master page. The application works great when it is configured to run on the ASP.NET Development Server 2.0. But once i publish it to run on the IIS web server it will no longer function. :( I could see from the trace that none of the session variables i use are stored and redirected to the relevant content pages.
Although the contents are displayed, the session variable values by which i take some decisions on the redirected pages are lost and i run into exceptions.
Please guide me where am i going wrong and exact procedure for Publishing an application.
Ex: my home page has URL which runs something like
http://localhost/Onlineupdate/Home.aspx?vers=1.1&lang=fr-FR
Based on the above URL, i strip and save the vers and the lang variables in a Session variable. However these are lost when hosted on IIS.
There are a dozen or so things that could cause the session data to be lost:
IIS restarting
The app pool restarting
due to a change to the web.config
due to a change to anything in the \bin directory
memory limit reached, or a bug causing the app pool to reset.
several other possible causes
Your host is actually a web farm, and you're using in-process memory, which will cause issues when one server fails over to the other, unless you're using SQL Server session state mode.
Since we don't have enough information to answer exactly what's happening in your specific situation, I'd ask you to start by reading up, starting here: http://msdn.microsoft.com/en-us/library/ms178581.aspx
Edit: I did find this blog article, which may be helpful: http://blogs.msdn.com/b/amenon/archive/2007/08/21/troubleshooting-session-loss.aspx
The following is not necessarily part of the answer, but added to try to be helpful.
If it's feasible, from my own personal experience, we've had success in eliminating our lost session issues by using the SqlServer Session State mode. Since we implemented this, our session issues have all but disappeared.
also i found the main problem that you should initialize session before use
like:
session[“id”]=””;
and after that it well work fine
In order to prevent this to happen first in the web.config set restartOnExternalChanges to false.
Now in web.config changes must be propagated manually(this means that the dev is now responsible to build a mechanism for config change propagation).
Hint: You can use file watcher for this that will listen for the web.config (or any config you use in you web. app) for changes and wrap it as a watchable configuration so you can reload the configs when they are changed.
Hope this helps
I faced the same issue in my ASP.NET MVC website .
and i have resolve it by next steps :
open IIS Manager
go to the application pools
right click on the application pool which related to your website
click on "Advanced Settings"
set "Idle Time-out (minutes)" to be "20"
set "Maximum Worker Processes" to be "1"
Click Ok to close the window
these steps has resolved my issue.
Related
I am facing a problem about web application,
I have lost session too soon
, I have already set timeout and that related things.
it is done when I have uploaded it on
LIVE SERVER
, after spend some time I not able to use session, it redirect me on Login.
Please tell me what i can do?
Thanks
Sorry i have to reply as answer not comment ,
Type “inetmgr” in run window to open IIS
from left pane “Connections” select your application.
right click on your application and refer the image to open “Advanced Settings” of application(to check which ApplicationPool is referred by application )
from “Application Settings” window you can see the Name of ApplicationPool. like Asp.net V4.0, DefaultAppPool, Asp.net V4.0 Classic.
Right click on the ApplicationPool that was assigned to your Application and click on "Advanced Settings...."
in the popup window ... check the Idle time out for ... that cause the timeout while web application is idle.
There're multiple ways why ASP.NET session state can be lost. The most common one is when the application pool recycles. This, in turn, can be due to IIS configuration (scheduled recycles), changes to the /bin folder or web.config file (can also be an anti-virus software that "touches" the files).
In case the session state is maintained using cookies, there can be situations when the browser doesn't accept them (and therefore, doesn't pass them back resulting in a new session created every time). You can verify that the cookies are sent (and that the value is not changing within the same session) by using Fiddler or F12 tools of your choice (the name of the cookie is ASP.NET_SessionId).
You may also check the sessionState configuration element in your web.config file to make sure those settings are correct (more on the subject: MSDN article).
Also, check the Event Log ("Application" log where the "Source" would be "ASP.NET X.X.X.X" where "X.X.X.X" is the framework version). In cases like this, there's usually some useful information in there.
Hope this helps.
If I make a change to the vb code in a classic asp page does the change get picked up automatically or is an iisreset needed?
Thanks
Quickest answer NO you do not need to reset IIS
Once the changed file is saved, the new code will run.
There's no need to reset IIS or build the project.
The ASP Script engine does maintain a cache of "compiled" scripts (where the results of parsing and tokenizing etc are stored. So that subsquent requests for the same ASP page can be processed more quickly. However the last modified date of the ASP file forms part of the cache identity of the cached page. Hence if the page has changed since the last request the cached item is dropped and a new one built when the next request arrives so it all works seemlessly.
So as the others very quickly said, you don't need an IISReset or even an App pool recycle.
It may be worth pointing out that as of IIS6 there are very very few circumstances where you would ever need to perform an IISReset. IISReset is massively draconian and high impact. Most of the time when such a "reset" is needed a simple re-cycle of the appropriate application pool will do which has a far more gentle touch.
Even back on IIS5 a close equivalent of a app pool recycle could be achieved with by restarting the appropriate COM+ application.
On Win 2003 Server (IIS6) most of the time, save the changes to the file and it works.
I have had caching problems when the files have been saved and then copied/moved to the final location which is a virtual folder in IIS.
For example:
Say C:\inetpub\wwwroot\myfolder\ is the physical path for the URL http:Myserver/myApp/
I save my files in C:\inetpub\wwwroot\test\ and everything works fine
Move/copy the files from 'test' to 'myfolder' overwriting existing files and when I access http:Myserver/myApp/ I see my old pages, not the updates.
Normally, I use App_Offline.htm for taking the site offline. But occasionally, when I do that, the site just hangs (like in: browsers wait forever, server gives no response at all). This seems to happen on an updateable site when I change something, like a control and afterward, when it doesn't go quick enough (site hangs), I place App_Offline.htm in the root of the website.
In most cases, this immediately takes down my site. But occasionally it doesn't. In those cases, I cannot just stop the website (when I restart, the behavior continues). Stopping the application pool doesn't let me restart the same app pool. The only two solution so far is restarting the whole IIS web service.
I'd like to prevent this from happening. Is this a bug in IIS not "breaking all actions" when App_Offline.htm is found? I use IIS 7 with Windows 2008 SP2 64 bit.
What I found was that my web.config file either had an error in it or was missing. When this is the case, app_offline.htm does not get processed.
IIS should not stop existing actions, only prevent new requests from going through: Will app_offline.htm stop current requests or just new requests?
It sounds like you are describing a scenario where you update a control, try to load a page, and IE is stuck loading. At this point you drop the app_offline.htm and expect to see that page immediately.
If you are making a completely separate/new request after putting app_offline.htm in place then you should see the page come up. However the existing request will not be affected as linked above.
If possible try deploying the app_offline.htm file prior to making the control change.
I am not sure what you mean by "Stopping the application pool doesn't let me restart the same app pool"...if you meant that you can't restart the pool immediately after stopping it, thats because it isn't stopped yet. Depending on the number of Worker Processes in that pool it may take a min for it to completely spin down so it can accept the start command.
Also, I would think you would have to restart the pool in order for the app_offline.htm to work effectively anyway.
Here's the thing.
Everytime when you open the .sln at the server, or updating the code, it will create the app_offline ticket in the root.
This is the feature from asp.net itself to prevent any access to disturb your development.
Delete the app_offline manually everytime after you open the .sln.
hope this help.
thanks.
Another possibility is a missing handler. The following handler is required:
ExtensionlessUrlHandler-Integrated-4.0
To fix the issue you need to at a minimum:
Wait the length of your website timeout to ensure all requests have finished.
Background processes kicked off from a web request will mean further extending the length of time you wait beyond the website timeout
Unload any unmanaged code by hooking into the DomainUnload or Application_End events
I'm waiting 3 minutes for App_Offline.htm to take affect and this seems has allowed App_Offline.htm to work as expected.
I am trying to get a grasp on how to handle updates to a live, functioning ASP.NET (2.0 or greater) Application while there are users on the site.
For example, suppose SO is an ASP.NET Web Application project. The project code compiles down to the single .DLL in the BIN folder. Now, there are constantly users on SO, so what would happen to users' actions/sessions if you would use the Visual Studio .NET "Publish" feature (or just FTP everything again manually) while they are using the site?
Would creating an ASP.NET Web Site, instead, alleviate any problems that may or may not exist with the scenario above? I am beginning to develop a web site as a user-driven Web Application, and I want to make sure that my inexperience with this would not potentially annoy the [potentially] many users that I [want to] have 24/7.
EDIT: Sorry, I should have put this in a more exact context. Assume that this site is being hosted by a web hosting service with monthly fees. I won't be managing the server itself, just what the web host allows as a user of their services.
I create two Web sites in IIS. One is the production Web site, and the other is a static Web site with an HttpHandler that sends all requests to a single static "We're updating" HTML page served with an HTTP 503 Service Unavailable. Typically the update Web site is turned off. When it's time to update, we stop the production Web site, start the update Web site, and now we can fiddle with the production Web site all we want without worrying about DLLs being locked or worker processes needing to be spun down.
I started doing this because
App_Offline.htm really does not work well in Web Gardens, which we use.
App_Offline.htm serves its page as 404, which is bad if you're down for a meaningful period of time.
We can start the upgraded production Web site with modified settings (only listening on localhost), where we can do a last-minute acceptance/verification that everything is working before we flip the switch, turning off the update Web site and re-enabling the production Web site.
Things this does not solve include
Any maintenance that requires a restart of the server--you still have downtime where no page is served.
Any maintenance that diddles with the .NET runtime, like upgrading to the latest service pack.
Other approaches I've seen include
Having two servers. Send all load balancing requests to one server, upgrade the other one; then rinse and repeat. Most of us don't have this luxury.
Creating multiple bin directories, like bin-1.0.0.0 and bin-1.1.0.0 and telling ASP.NET which bin directory to use in the web.config file. (One advantage of this is that reverting to a previous binary is just editing a config file. A disadvantage is that it's harder to revert resources that don't end up in your binaries, like templates and images and such.) I don't remember how this actually worked--I think the application did some late assembly loading in its Global.asax based on its own web.config section (since you touched the web.config, the app had restarted, so it was okay).
If you find a better way, let me know!
Changing to the asp.net web site model won't have any effect, as the recycle will also happen, some of changes that trigger it for sure: web.config, global.asax, app_code.
After the recycle, user will still be logged in because asp.net will just validate the syntax. That is given you use a fixed machine key, otherwise it will change on each recycle. This is something you want to do anyway as other stuff can break if the key change across requests i.e. viewstate validation, embedded resources (decryption of the url fails).
If you can put the session out of process, like in sql server, you will avoid loosing the session. If you can't, your code will have to consider that. There are plenty of scenarios where you can avoid using session, and others were you can wrap it and re-retrieve the info if the session was cleaned. This should leave you with a handful specific cases that you know can give trouble to the users, so for those you do some of the suggestions others have already made.
One solution could be to deploy your application into a load balanced environment (web farm).
When deploying a new version you would use the load balancer to redirect requests to the server you are not deploying to.
App_offline.htm is great solution for this I think.
in SO we see application currently unavailable page when a deployment begins.
I am not sure how SO handles it.. But we usually put a holding page. So what ever the user has done (adding question or answering questions) does not get updated. As soon as he updates something he will see a holding page asking him to try after sometime.
And if I am the user I usually press the back button to make sure what I entered is saved in the browser history so that I can post later.
Some site use use are in clustered environment so I take one server offline and inform the load balancer that she will not be available and once I make sure that the new version is working fine I make it live.. I do the same thing for the next server.
Do we have any other option?
It is not a technical solution, but set up a scheduled maintenance window. You can annoucement in advance giving your user base fair warning that there is a possiblity that the application will not be available during that time frame.
Following recent hardware problems, I attempted to switch a couple of our websites to use new, individual application pools. A test run on our staging server worked fine, and has had no visible negative consequences.
Unfortunately, trying the same operation on our live machine left one of our key applications struggling - my best guess is with some kind of mismatch in Session state. I could log in fine, but a few clicks later would be presented with a screen that was part login screen, but with all menus visible. This indicates to me that part of the system thinks the session had been lost (redirect to login page), but IIS itself had not lost the session (hence the menus showing on the master page).
I tried recycling all the Application Pools (new and old), and each website using IIS Manager. I also tried a single-space change to the web.config file, and a full release of the dll's. Still, I could intermittently use the system for a few clicks, do some useful stuff, then maybe find myself at a login screen again or similar. We have some logging and on some occasions I could see that the session was being timed-out after a couple of seconds, substantially less than the settings on the App-pool (default 20mins).
As soon as I switched the web site's app-pool back to the default, everything was ok again.
What have I missed? Any suggestions gratefully received!
EDIT:
Just thought... on the staging environment I did name the App-pool differently from the website name (e.g. Xxxx_Dev, Xxx_Test etc) but on live I just called it the same name as the website. Could this cause an issue?
do your various applications all use Forms Authentication? Have you specified unique path attributes in each form tag in the web.config under the Authentication tag?
OK. I think I've found the problem.
I was actually using an Application Pool that had been set up by someone else - of the expected name - but they had set it up with the Properties, Performance tab | Web Garden option to use 4 worker processes. I have now changed that to 1.
As the session state was being stored 'In Process' (the default), each time the connection hit a new thread it also essentially lost any stored session variables, as I now understand things.
Its early days, but a simple switch to the newly altered Application Pool (no restarts or web.config saves necessary thus far) and everything appears to be behaving normally.