We have a problem. We are using IISExpress 8.0 for Asp.net WebForm application(.net 4.0).
Comupter is running under Windows 7 x64.
Sometimes without any reason ApplicationPool restarts. I know that it will restart after 15 aspx\ascx file changes. But in that case it restarts without any changes.
On ApplicationEnd we found a reason of this restart. It's ApplicationShutdownReason.BuildManagerChange.
Search in the Internet won't give anything usefull details. Mostly all recomends to use IIS instead of IISExpress.
Do you know what could be a reason for it?
UPDATE:
Digging deeper into .Net 4 source code give two reasons of this shutdown.
One of them is triggered when someone changed hash.web file from Temporary Asp.net folder. For example - "c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\app\a83dcad1\be4aa699\hash\hash.web"
Second reason is when BuildManager built some object and cached BuildResult in HttpCache. And then if it's expired it checks that this BuildResult require ShutdownAppDomainOnChange on cache expiration. And if it's require it, then it triggers BuildManagerChange shutdown.
UPDATE2
In our case restart was caused by hash.web change. Seems IISExpress updates it without any source code change, but why?
UPDATE3
Microsoft has an issue about it - https://connect.microsoft.com/VisualStudio/feedback/details/783440/microsoft-visualstudio-web-host-exe-touches-hash-web-and-should-not-be-running
They say that they fixed it in Visual Studio 2012 Update 2.
This is not a full answer, so take whatever benefit from it you may take.
It seems like two things are happening: the hash.web change is probably because IIS uses the temporary location to store the application DLL that you build. When this file changes, IIS understands that you built a new version of the application, and need to restart it; that may explain the application pool reset.
For the cache expiration, it seems like IIS is trying to unload and reload something in a different app domain. There's no way (in .NET) to unload an assembly without unloading an app domain (I think) once it's been loaded, so this is "the usual" way to achieve this.
Maybe.
Related
For an ASP.NET Website where i am making updates. What would cause user sessions to reset?
From my understanding if i make any changes to files in the app_code folder or the global.asax file it will reset everyone's session but if i made a change to .cs file (in the top directory) it wont reset everyone's session?
Would it reset the session of anyone that was on that page that i updated?
Can someone help me with my understanding, thank you.
Assuming memory-based session (as opposed to sql server based).
Well, the app pool restart will blow out session.
(so, in some cases even un-handled errors will blow out session).
Modify web config?
that will case app pool to restart (and blow out session).
Update any folder outside of app_data. Again, app pool re-start (and blows out session).
change content of bin folder - again app pool re-starts, (and blows out session).
Update code behind (.cs, or vb pages (code behind)). - again, app pool re-starts, (and blows out session). (so anything that will cause a re-compile of code).
There are probably a good many more - the above is a basic list.
You can thus consider adopting sql session based, and that will thus be far more robust, and I even re-started IIS services, and users if not doing anything just looking at their web page while logged on? They were able to continue working even after a full re-start of IIS services.
On the other hand, I now always use a asp.net web site "applcation". Thus no souce code is placed on the web server, and my compile is done with visual studio before deploying. The only big issue is that if you change to a application deployment model, the even just changing one line of code behind will force/require a full re-publish of the web site.
It looks like you are using a web site, and thus source code (code behind) is placed on the web server. Thus, IIS has the job of re-compiling such code, and thus any code change will as a general rule cause a app_pool re-start, and thus loss of session.
As noted, if you change from in-memory session to SQL server based (turn that feature on), then most if not all of your session issues will go away. Even if you not using "application deployment" and have/use code behind on the site for IIS to re-compile? Then using sql server-based session management should fix all of your session() woes.
I have a problem deploying a .net core application via FTP which is hosted on IIS.
The main DLLs (core application) that I want to update just wont upload, FTP just gives me a generic permission error message. I think the reason is because they are in use because then I stop the application pool, upload and restart it works just fine.
But this isn't really a solution, are there any other methods of publishing that will alleviate this problem?
Edit:
"open for write: failure"
Is the only error I'm getting. I can't find anything online and the only solution I have is restart the app pool.
I found an answer and I figured it should be here for future Googling.
The issue is as I first expected IIS proxies the request to kestrel and that means the process is in use as far as Windows is concerned. There are three solutions.
The Good Solution
Have two (or more) VMs on azure behind a load balancer. Have a script which turns off the sites one at a time, does what it needs to do and turns them back on. Do this right and no downtime!
Intermission
Before I talk about the other solutions a little explanation. I have not been working with .NET for a long time but apparently there was this thing you could do where you add a app_offline.htm and it will temporarily take down the site for you.
In the context of IIS and .Net Core it also releases the process, which is really useful as it solves my problem! Although I had to visit the web page first for it to take effect, unless I'm mistaken.
The Bad Solution
Use an automated script to rename _app_offline.htm to app_offline.htm. Do the upgrade and then revert that change. Takes your site down, kind of ugly but scripting is always better than...
The Ugly Solution
You only have access to FTP, no remote admin or proper deployment process because... reasons.
Upload an app_offline.htm, upload as little as possible and hope it doesn't break anything before deleting or renaming app_offline.htm.
Also you would have to perform any DB migrations by using EnableAutomaticMigrations = true because you have no server access or scripting methods.
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..
I have an ASP.NET web application which contains a DLL in the /bin folder 'Example.dll'. If I do not have any mention of 'Example.dll' in the Web.config, is it safe to simply replace it with a newer version of 'Example.dll', and the application will use it?
If not, what steps are needed?
Yes, that's safe (assuming you've been careful and not made any breaking changes), but here's a tip I learned from bitter experience: don't backup the old version within the same folder. Even if you rename it something like Example.dll0, it may still confuse the framework.
Also, doing so will restart the app.
Replacing the DLL will trigger the App Domain (the entire web application) to restart, any code using this DLL will use the new version upon restart. Current requests to the old one will complete, then shutdown.
So no additional steps are needed, just be aware the application will restart.
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