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