If you’re developing for SharePoint 2010 the Application Pool has a setting called Ping Maximum Response Time with a default value of 90 seconds. In effect, this means that debugging your Web Part, Page, etc. in SharePoint 2010 will only work for 90 seconds and then you get this:
You can increase the value of Ping Maximum Response Time in the Application Pool Settings in IIS:
You can also increase the value for future Application Pools via Set Application Pool Defaults (see Actions menu):
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...
Problem
I was receiving multiple complaints from clients with the above errors in the machine's Event Log:
Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Besides the errors it was no longer possible to manage the Web Sites using IIS Manager which gave "The path specified cannot be used at this time."
Approach
Searching on the Web had led me to believe this would all be fixed when SharePoint 2007 Service Pack 1 released, so I upgraded all (problematic and non problematic) servers to
- .NET 2.0 SP1
- .NET 3.0 SP1
- WSS 3.0 SP1
- MOSS 2007 SP1
The problems remained however...
I found out that an iisreset would solve the issue but this really wasn't feasible to do every day.
Next I found that just restarting the Windows SharePoint Services Timer Service (SPTimerV3) also did the trick and was less intrusive:
C:\>net stop sptimerv3
The Windows SharePoint Services Timer service is stopping.
The Windows SharePoint Services Timer service was stopped successfully.
C:\>net start sptimerv3
The Windows SharePoint Services Timer service is starting.
The Windows SharePoint Services Timer service was started successfully.
Other suggested solutions include:
- recreating the SSP
- reset the service account credentials
- Timer Job Shocker
But none of the above solutions seem to be the definite answer.
Solution
Microsoft recently released the following KB with hotfix:
FIX: You may be unable to manage IIS 6.0 by using Server Manager if two threads access IIS 6.0 at the same time
References
http://blogs.neudesic.com/blogs/grant_earl/archive/2007/04/05/5465.aspx
http://glorix.blogspot.com/2007/09/attempted-to-read-or-write-protected.html
http://forums.asp.net/t/675515.aspx
http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/Post.aspx?ID=47