That thud you heard was my next web part crashing...

I'm converting the Personal Web Links part from SQL Digital Dashboard v3 (DDv3) to Windows SharePoint Services (WSS). The effort was not very difficult: a few CSS class name changes, a custom property that ShouldSerialize, referencing WPSC instead of DDSC, removing obsolete JavaScript functions, updating the XSL from the “TR/WD-xsl” namespace to the “1999/XSL/Transform” namespace. Everything looks good on my development machine, but other users saw nothing.

My debugging method of choice is the ASP.Net trace feature. In web config, I set the trace options:

    <trace enabled=”true” pageOutput=”true” localOnly=”true” />

This will dump a bunch of information at the bottom of the page. (WARNING: Do not do this on a publicly accessible machine. It will compromise security.)

In my web part, I include a call to Context.Trace.Write at the beginning of each routine. In the catch blocks, I call Context.Trace.Warn(ex.ToString). This puts the entire exception into the trace output. Plus, it avoids the WSS error page (“The [Name] Web Part appears to be causing a problem.“)

My exception output indicated an error accessing C:\WINDOWS\temp\faqvgg2l.dll(??). Thanks to the stack trace, I was able to determine that this dll contains the script embedded in the XSLT in an msxml:script tag. Fortunately, that function can be moved into the web part assembly, so I'm on my way.