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 IIS8 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.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

When I see a question like this, I parse it as "Why won't my SUV run on hay and oats?"

K

Thursday, March 21, 2013 4:31:12 AM UTC

Typo 'IIE8' in third line...

Krunal Mevada

Thursday, March 21, 2013 6:14:45 AM UTC

I like to see examples of cases when one should not move from classic to pipeline mode. Everyone wants to use the faster and superior pipeline mode. Please don't say try the pipeline mode and if the app doesn't work right, go classic. That's not a scientific way of thinking.

Abdu

Thursday, March 21, 2013 9:41:33 AM UTC

okay, they are different. And now I have a clue about how they are different. But it would be useful if you mention which cases will work on the old version but not on the new one?

Good post Scott, however, I'd like to add a couple of things. Those of us on the support side tend to frown upon on sites/applications using classic mode.

Not because there is anything intrinsically wrong with it; it is exactly aimed at supporting the scenario you describe. The problem, however, is that many developers have little or no knowledge about IIS, and thus don't know the difference.

I have seen way too many new applications, being released on IIS 7.X for the first time, and using classic mode because the developers had no idea what the difference was and how to fix it.

For a significant chunk of applications, all that is required to support integrated pipeline mode is tweaking the web.config file to move ASP.NET <handlers> and <modules> sections into the new corresponding entries in the <system.webServer> section group.

Also useful to mention here would be the APPCMD MIGRATE CONFIG command, which can, in many cases, do the required Web.Config changes automatically.

I've run into two things that work in Classic mode but need workarounds in Integrated mode:

Mixed authentication in a single application: For example, having the public site secured with Forms auth, and a management folder in the same application secured with Windows auth. Mike Volodarsky posted a workaround on his blog.

Buffered health monitoring with Windows authentication: In classic mode, the WindowsIdentity for the authenticated user is never disposed, so when the buffered event is formatted, the identity is still valid, and everything works. In integrated mode, the identity is disposed when the request completes, and the event formatting code throws an ObjectDisposedException. The workaround is to disable buffering (or not use health monitoring).

Richard

Friday, March 22, 2013 2:40:24 PM UTC

I'd like to know how long 'classic' is going to be supported. We have apps that were ported from IIS5 to 6. They work, and do what the business requires. Don't really have time / interest in re-writing a successful app just because technology has progressed...

Rhonda

Wednesday, June 05, 2013 1:52:13 PM UTC

Hello, I have a site in asp, when in Integrated mode, a problem happens with downloads coming from the site, some downlods corrupt, classic mode all comes right.anyone have any idea what it is?

Marcus

Tuesday, July 23, 2013 9:52:26 PM UTC

Hey, I have seen way too many new applications, being released on IIS 7.X for the first time, and using classic mode because the developers had no idea what the difference was and how to fix it!