The situation is weird. We've developed a deployment system for our internal use. The system downloads precompiled binaries and copy to application directory using robocopy, excluding unchanged files.
The problem is, after this operation, the application doesn't hit application_start. Even we restart application domain. (I even restarted the IIS itself but no luck) I even change web.config manually after auto-deployment, again no luck. I run iisreset, the same, did not hit application_start. But the application is running! we use a state server, and we continue to use application like nothing happend (except application variables, they all disappear)
In application_start, we initialize some Application variables by adding like following:
logger.info("bla bla");
Application.Add("KEY",somevaluefromdb);
We do not see any log messages too.
But when i deploy same binaries manually (by copying and pasting.), the application_start hits, we see log message, and the variables are initialized.
Did anyone encounter such situation?
If PrecompiledApp.config file does not exist at publishing app root folder, the events would not execute.
I spend hours for this meaningless error :(
Related answer: Global.asax not firing for Release build
Related
I have a deployment workflow for an ASP.NET web app which begins with puttin an app_offline.htm file to the directory of my web app. Despite that, I usually get this error:
The process cannot access the file ... because it is being used by
another process.
Indicating that the IIS process is still running despite the fact that the app_offline.htm file is in place. If I remote desktop to the server and do a manual iisreset or shut down IIS with its GUI (or just wait a few minutes after manually putting the app_offline.htm file there, then the workflow works correctly.
So, how long does it take for IIS to shut down after app_offline.htm is in place?
I don't know but I would like to know. So I ran some tests...
The effect is pretty much immediate, but it may take some time for the IIS app to actually shut down due to extra clean up code. Expect files to be locked for some time even after app_offline.htm is in effect.
The actual file system event information takes just a few milliseconds to propagate.
The default is (up to) 90 seconds. This is defined in the application pool settings that your web application is running under in IIS as "Shutdown Time Limit".
Process Model documentation at Microsoft
We are encountering a strange phenomena in our production environment, every few hours the application kicks all users out by ending their sessions with Session_End event and fires Application_End event.
In our log, all the user's sessions are closed on the same mill-second.
We encountered this problem in our Test environment but only on rare occasions, and we could not duplicate this.
Everything else seems fine, other application running on this server works fine, there is no memory leak or CPU overuse. The application is based on ExtJS version 3.3, NHibnernate 3.2 and ASP.NET 4.0.
It doesn't seems like a Timeout error, some of the users worked for only several minutes before the session end.
Has anyone encountered similar problems?
There are a couple of reasons why an application pool recycles (and thus ends all open sessions and ends the application). See http://blogs.msdn.com/b/johan/archive/2007/05/16/common-reasons-why-your-application-pool-may-unexpectedly-recycle.aspx for a complete overview.
We had a similar problem in a production environment once. The reason for the recycle was the virus scanner that touched the web.config on each scan which made the application pool recycle. Try to disable the virus scanner on the server or exclude the application directory in the virus scanner.
Altering the following files will also trigger an immediate restart of the application pool:
web.config
machine.config
global.asax
Anything in the bin directory or it's sub-directories
This post: http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx gives you a way to catch the application end event with more detailed logging. This might help you to find the cause of the recycle.
Having a bit of a problem with my hosted ASP.NET applications. I noticed slowness when opening pages, the kind of slowness that you see the first time you start up an ASP.NET app. After researching, I'm finding that the Application_End event is firing shortly after the application starts, apparently killing the sessions, static values, etc.
I have the standard default web.config set up, and I am writing to the session when a page is requested. But for whatever reason, the application isn't waiting 20 minutes (or whatever the default is) before dying - sometimes it's just a minute or two, sometimes even less.
Of course, this doesn't happen locally in my dev environment - everything works as expected, with identical code and web.config values.
There is only one server, so no farm or anything like that.
I know that there are many things that cause an ASP.NET app to end - IIS restarting, app pool recycling, DLL or config file modified, reboot, etc. But I'm hoping to have a better guess when I report this to my hosting company, to help research and fix the problem. The server isn't being rebooted, and I'm not modifying any files, so that seems to leave IIS or the app pool restarting, unless I'm missing something else.
IIS restarting is in the Windows Event Viewer, so that's easy enough to find. Assuming that's not it, is there any way to determine exactly why the app keeps resetting?
Any thoughts you may have on this would be appreciated.
This is some of the reason that you may think and check for.
a command that shut-down the app.
a bug/closed loop that crash the app.
a memory limit on the application pool that shut-down the app. (this is the most possible)
a very bad iis and pool configuration on a shared server or on a virtual server. Maybe too many sites on the same iis, and at the same time a bad pool setup ?
You can check for bugs on the global.asax
void Application_Error(object sender, EventArgs e)
{
}
by log all of them and check them out.
You can check the pool setup if you have access on the iis, or ask from the administrator to check it for you and remove the memory restart limits.
I've been developing an ASP .NET 3.5 web application against Cassini, the built-in web development server, rather than against IIS.
In my Global.asax file, in the Application_Start event handler, I have some code which logs the fact that the website has started up. This all works fine with Cassini.
Since deploying the site to a virtual directory on a test server using IIS6, I am finding there are no log entries being written, and so I'm concluding that the Application_Start handler is not firing.
I then tried removing the virtual directory and running the site directly out of the root of the website on the test server, but it didn't make any difference - still no log entry for application start.
I know these events should fire irrespective of my deployment environment, has anyone got any ideas what is going wrong here?
I had a similar problem and I was wrestling with it for several days.
The initial problem was something else - cookies not being set in Application's EndRequest handler.
Finally I somehow managed to realize, that the problem actually was that the event is not being fired at all.
It took some time to find that out, because all was working fine on my machine.
But on the production server - quiet as a tomb.
I am only writing this, because I really hope to save from troubles at least one person.
The real reason for the problem was a missing global.asax file on the production server.
The global.asax file was present on my computer, because the development environment is located there.
I had prepared a deployment bat file, which coppies files from the development folder, removes the unnecessary ones and makes a package.
Well - the global.asax file was marked for deletion in that script.
After starting to deploy it all the problems went away.
I hope I helped.
If you make a request to your app does the "Application_Start" fire then? I don't believe it will be started until the first request is made.
How are you logging? Is it possible that your logging component is not correctly set up? For a quick test try throwing an exception inside Application_Start and that will tell you quickly whether or not the event is being raised.
In your deployed enviroment, what is the thing you're calling? The reason I ask is because if you're calling a WCF based web service (ending in .svc), then Applicaiton_Start will not fire as the call to WCF isn't going through the ASP.NET pipeline. This wouldn't necessarily rear it's head w/ Cassini.
You may be getting a runtime exception that is occurring before your .NET code even gets a chance to run. If you look under the Event Viewer's Application logs, you may see some warnings or errors that will clue you in to what is happening.
When you develop in Cassini you are running the application under the user's account- probably administrator. Once you've deployed to IIS, you are (hopefully) running under a lower privilidge account.
This lack of appropriate permissions is probably the reason why your application is not working correctly- I would check the security settings to write to the log (presumably you are writing to a log file?).
1) iisreset /stop
2) push the published code to iis virtual directory's physical folder.
3) iisreset /start
4) make web request
Still not sure after this. the do a Thread.Sleep(60000); and attach with remote debugger to the process w3wp.exe imagename.
There may be more than one process of that name but this one is managed code also doesn't hurt to attach to multiple. Set the break point after the sleep. After the one minute sleep step through.
I thought I had a similar problem, working on some old projects, I was under the impression that the global.asax was not running because the code would first go into building my authentication controller which would fail because of class not registered (that part happens in the global.asax).
Turned out it was due to a config item. When I moved the AuthenticationModule declaration into handler section in web config, it worked fine with IIS express.
Basically, because of a config item, another piece of code was being executed before global.asax, making me believe that it would not be called.
We tried a lot of things.
global.asax works on local computer but not after i publish to server
Global.asax is not publishing and event are not firing in Global.asax
Global.asax not firing for Release build
Mystery of Global.asax in ASP.NET MVC application
We also tried putting the below files in root and bin directories.
App_global.asax.dll and App_global.asax.compiled files
PrecompiledApp.config
None of it worked!
We had to put raw Global.asax instead of pre-compiled dll, in order to fire the global events, for our asp .net 2.0 website.
Hope this helps someone! Cheers! Happy coding! :D
My fix was an odd one. On my development machine I am using localhost and I changed the port number it used - and then it worked.
also in IIS Manager turn on Dot Net debugging. It's under "Compilation"
If a required dll is missing from the bin directory (for example there could be a 3rd party dll which has been used in your latest build, but accidently excluded from deployment), then the Application_Start will not fire.
My issue was resolved by adding the below compiled files in the bin folder.
App_global.asax.compiled
App_global.asax.dll
I have a question about asp.net compiling. I know the different ways you can compile but my question is with the default method.
Microsoft says that pages and code are compiled on their first use and then cached. My question is, when does that cache clear...
when the app pool recycles? Or, does it cache it until it's changed even through server reboots. Basically, if it compiles once and then caches it until it's changed I'm ok with it... if it recompiles with every reboot or app pool recycle I'm going to go the route of pre-compiling.
The cache is cleared upon app pool shutdown, at each app pool startup it is re-compiled and cached.
Whenever you change something to the source files it will recompile.
On startup (after shutdown) it will recompile too.
Changing something to the web.config reboots your web
So the files are created in a temp folder but do not get cleared on shutdown. They will only be recompiled if something changes. So if you restart IIS or reboot the machine, they will not recompile. Just reload them from the temp folder.
Changes to any of the files of the project, or any files the project is dependant on will cause a recompile.