SharePoint 2010: Increase debugging time by configuring Health Monitoring


February 6, 2011 - 17:51, by Steven Van de Craen - 3 Comments

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:

Debugger terminated by IIS

You can increase the value of Ping Maximum Response Time in the Application Pool Settings in IIS:

AppPool Ping Settings

You can also increase the value for future Application Pools via Set Application Pool Defaults (see Actions menu):

Set Application Pool Defaults


SharePoint: Sharing data over applications ?


November 12, 2008 - 14:37, by Steven Van de Craen - 2 Comments

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


    SharePoint Errors: 6482, 7888, 6398 and 7076


    February 23, 2008 - 18:56, by Steven Van de Craen - 1 Comments

    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