Scott Hanselman

Moving old apps from IIS6 to IIS8 and why Classic Mode exists

March 20, 2013 Comment on this post [12] Posted in ASP.NET | IIS
Sponsored By

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):

IIS Classic Pipeline is two pipelines. One for IIS and one for ASP.NET

IIS7 and 8 were re-architected with the superior and faster Integrated Mode pipeline but retain "Classic" mode for compatibility.

IIS7 and up is one integrated pipeline

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

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.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
March 21, 2013 3:01
pipeline? that's not a word!
March 21, 2013 3:23
Yep. It is.
March 21, 2013 3:36
When I see a question like this, I parse it as "Why won't my SUV run on hay and oats?"
March 21, 2013 8:31
Typo 'IIE8' in third line...
March 21, 2013 10:14

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.
March 21, 2013 13:41
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?
March 21, 2013 18:11
Pipeline is a word over here in the UK. :-)

Oxford English Dictionary's entry:
March 21, 2013 19:49
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.

March 21, 2013 22:35
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).
March 22, 2013 18:40
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...
June 05, 2013 17:52
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?
July 24, 2013 1:52
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!

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.