I had an interesting emailed question today. Here's a paraphrased one sentence version of the question:
Why does an ASP.NET Runtime issue surface in IIS 8.0 Integrated Pool for an application we have run successfully on previous versions of IIS and classic mode in IIS 8.0 ?
It's less interesting that they've moved from IIS6 to IIE8 and more significant that they've moved from Classic Mode to the Integrated Mode pipeline.
So, the short answer. These pipelines are different and if you write an app expecting the behavior of one pipeline and the move it, your observed behavior will likely be different when you move it to the new pipeline.
IIS6 was released in Windows Server 2003 over 10 years ago. Apps used the ISAPI pipeline. By its nature everything in IIS6 is what we think of today as "classic mode," rather than the newer Integrated Pipeline in IIS7.
IIS6 with ASP.NET had two pipelines - the IIS unmanaged one and the managed ASP.NET one. Here's a simplistic but mostly accurate diagram (as is the case with diagrams):
IIS7 and 8 were re-architected with the superior and faster Integrated Mode pipeline but retain "Classic" mode for compatibility.
"Doctor, it hurts when I do that."
"Don't do that."
If you're moving an older app from IIS6 (which by definition was only "classic" mode) to IIS 8, the best near-term decision is to run in Classic Mode on IIS8. Classic Mode is fully supported so you aren’t doing anything wrong by running in classic mode. It's a mode that is there for a reason.
Think about your reasons and make an educated decision.
Remember that there can be incompatibilities and edge-case behavioral issues when ASP.NET apps attempt to move from the older ISAPI hosting model circa IIS 6 to the newer integrated mode that came in IIS7 without thinking about the ramifications.
I hope this helps.
© 2013 Scott Hanselman. All rights reserved.
