How do I know if I need Full IIS in my Azure web role?

Question

I need to migrate an ASP.NET application to Azure. The application needs database access and access to temporary files and also using out-proc COM objects. Turns out there's "Full IIS" mode that offers some rather vaguely phrased advantages (from here ):

However there are a number of useful capabilities that only exist in IIS, including support for multiple sites or virtual applications and activation of WCF services over non-HTTP transports through Windows Activation Services.

Now obviously using Full IIS forces me to deal with the ASP.NET part and role part working in different processes and that's a big deal so I need to know whether I need Full IIS mode in the first place.

How do I decide if I need Full IIS mode? Is there a full checklist?

Answer 1

I think your default answer should be use Full IIS in Windows Azure capabilities. The hosted web core offering is really there for backwards compatibility as it was the original model prior to 1.3 SDK. Full IIS is the default and you must explicitly opt to go back to HWC.

The reasons that most people wanted full IIS were around a few, but important limitations:

1. Better support for IIS extensions (eg Smooth Streaming, Web Farm, ARR, etc.). HWC did not always support the modules and combined with a missing admin permission, made it really hard if not impossible to use all the modules that folks wanted to use.
2. Support for multiple web sites, vdirs, and application pools. HWC is a single app pool (the hosting process) and no way to support multiple web sites. There was a serious concern about needing to dedicate 1 entire role to a single web site. With Full IIS, you can have multiple sites and use host headers to get more bang for buck out of web role (especially with small web sites)
3. Support for standard tooling - Web Deploy, AppCmd, etc. don't work really well (if at all) with HWC. Anything that modified the applicationHost.config usually had issues with HWC.
4. WAS support. This allows you to use WCF with IIS as a host in non-HTTP transports.

In general, with Full IIS you have parity with what you do on-premises so it makes it much easier to configure and setup.

Regarding the RoleEntryPoint/HWC process model versus the RoleEntryPoint and separate Full IIS process, I am not sure that is really an issue. There were a few quirks perhaps initially, but what concerns you the most about this?