Steven Van de Craen's Blog [MVP]

Introduction

If you want to integrate you ASP.NET Application or Web Service in SharePoint 2007 there are some ways to do it. If there's no requirement in making it contextual (*) then you can just drop it in the root folder of the SharePoint IIS site.

(CustomerApp is a virtual directory, CustomerApp2 is a virtual application)

*: if you want your ASP.NET application, page or web service you can drop it in the LAYOUTS or ISAPI virtual path and it will be available for any SharePoint web via http://weburl/_layouts/yourapp or http://weburl/_vti_bin/yourapp. Your code could then get a reference via SPContext.Current.Web or SPContext.Current.Site.

What to choose

So do you create a virtual directory or a virtual application ? What are some key differences besides the icon in IIS Manager ?

virtual directory

• can access all application specific data (Application variables, Cache, Session, ...) from the parent application
• not all settings in web.config are allowed on virtual directories and must be done in parent application's web.config
• assemblies must be put in parent's BIN or in the GAC

virtual application

• can use the same or different application pool as the parent application
• does not share application-specific data (Application variables, Cache, Session, ...)
• assemblies must be put in local BIN folder or in the GAC
• can have specific settings regarding authentication/authorization in IIS or web.config

Additional info

• Understanding Sites, Applications, and Virtual Directories in IIS
• Wenlong Dong's Blog - Virtual Application vs Virtual Directory
• IIS 6.0 -Applications,Sites,Virtual Dir… « Sankarsan’s Journal

• What about Extended Web Applications (EWA)

  With SharePoint it is possible to create an extended Web Application that points to the same content but allows you to configure it with different URL, authentication, authorization, etc. However this creates a second IIS site in the same application pool but as a different application and thus plays by the same rules as above:

  • The extended Web Application does NOT share application-specific data with the 'source' Web Application
  • Warm-up scripts are application-specific; if your pages are hit via http://intranet then they must still be separately hit via any other URL if that URL is defined via a different Web Application

  Just something I needed to write down for personal reference. If it is any benefit to others then even better...