Share via

Deploying and debugging Web Parts

  • Article

When it comes to deploying and debugging your Web Part, you're spoilt for choice.  My preference is to package the web part into a cab file, creating and including a manifest XML and DWP file.  This should be familiar ground to seasoned web part developers, but an assortment of good MSDN and community content is available on this topic.  Then deploy into the SharePoint mist with stsadm.

Debugging Tip 0 - Setting up your environment

Check your environment is configured per Debugging Web Parts, the most important changes in web.config being

<SafeMode MaxControls="50" CallStack="true"/>

and

<customErrors mode="Off">

Debugging Tip 1 - Getting meaningful exceptions

If you're using Visual Studio, add debug symbols to your cab as a project output group along with your Primary Output to enable a lovely debugging experience.  Even if you don't attach a debugger, helpful exceptions should bubble up to the page.

Debugging Tip 2 - Speeding up debugging round trips

If you're working alone developing a web part and find you need to run an iisreset repeatedly to see your code changes (maybe you've deployed to the GAC), remember that your assembly isn't loaded into memory until it's first used. I set off an iisreset as soon as I'm done with a debugging session (so iisreset gets on with it as I'm changing my code).  As long as you update/redeploy your assemblies before refreshing the page, you'll see the changes and you won't have to wait.

Comments

  • Anonymous
    February 25, 2007
    Step-by-step guide to using SPGridView and SPMenuField to build a Web Part which uses the standard SharePoint UI controls to render non-SharePoint data, in this case from a classic .NET DataSet.