Mike Volodarsky posted a nice list of breaking changes when you run ASP.NET 2.0 web sites on IIS7 Integrated mode.
Here is the list (for workarounds take a look at Mike's blog post).
- ASP.NET applications require migration when specifying configuration in <httpModules> or <httpHandlers>.
- ASP.NET applications produce a warning when the application enables request impersonation by specifying <identity impersonate=”true”> in configuration.
- You receive a configuration error when your application configuration includes an encrypted <identity> section.
Authentication, Authorization, and Impersonation
- Applications cannot simultaneously use FormsAuthentication and WindowsAuthentication.
- Windows Authentication is performed in the kernel by default. This may cause HTTP clients that send credentials on the initial request to fail.
- Passport authentication is not supported.
- HttpRequest.LogonUserIdentity throws an InvalidOperationException when accessed in a module before PostAuthenticateRequest.
- Client impersonation is not applied in a module in the BeginRequest and AuthenticateRequest stages.
- Defining an DefaultAuthentication_OnAuthenticate method in global.asax throws PlatformNotSupportedException.
- Applications that implement WindowsAuthentication_OnAuthenticate in global.asax will not be notified when the request is anonymous.
Request limits and URL processing
- Request URLs containing unencoded “+” characters in the path (not querystring) is rejected by default.
- Requests with querystrings larger then 2048 bytes will be rejected by default.
Changes in response header processing
- IIS always rejects new lines in response headers (even if ASP.NET enableHeaderChecking is set to false)When the response headers are cleared with HttpResponse.ClearHeaders, default ASP.NET headers are not generated. This may result in the lack of Cache-Control: private header that prevents the caching of the response on the client.
- When the response is empty, the Content-Type header is not suppressed.
- When the response headers are cleared with HttpResponse.ClearHeaders, default ASP.NET headers are not generated. This may result in the lack of Cache-Control: private header that prevents the caching of the response on the client.
Changes in application and module event processing
- It is not possible to access the request through the HttpContext.Current property in Application_Start in global.asax.
- The order in which module event handlers execute may be different then in Classic mode.
- ASP.NET modules in early request processing stages will see requests that previously may have been rejected by IIS prior to entering ASP.NET. This includes modules running in BeginRequest seeing anonymous requests for resources that require authentication.
Other application changes
- DefaultHttpHandler is not supported. Applications relying on sub-classes of DefaultHttpHandler will not be able to serve requests.
It is possible to write to the response after an exception has occurred.
- It is not possible to use the ClearError API to prevent an exception from being written to the response if the exception has occurred in a prior pipeline stage.
- HttpResponse.AppendToLog does not automatically prepend the querystring to the URL.
- ASP.NET threading settings are not used to control the request concurrency in Integrated mode.
- ASP.NET application queues are not used in Integrated mode. Therefore, the “ASP.NET Applications\Requests in Application Queue” performance counter will always have a value of 0
- IIS 7.0 always restarts ASP.NET applications when changes are made to the application’s root web.config file. Because of this, waitChangeNotification and maxWaitChangeNotification attributes have no effect.