Debugging with Your Hands Tied

The scenario was as follows:

As part of a SharePoint project a custom event handler was needed that looked across two libraries to assign some metadata automatically. This required a farm level solution created in Visual Studio. (Such development is covered by our course, Programming SharePoint® 2010 Applications with .NET.) I don’t have administrative access to the Server where the code will be deployed, but I do have design rights on the Libraries. After testing locally the packages were sent to the administrator who was in a different time zone. He installed the code and enabled the feature on the appropriate site.

Sadly, on the first attempt at uploading a document the fields weren’t set correctly. Since I can’t use Visual Studio on their server or look at ULS logs to determine if any errors occurred and the admin had gone home, I needed another approach. There may be others but the following approach worked–and continues to work–for me and my client:

I changed the code to look for the presence of a column named ‘Debug’.

If found I wrote diagnostic (trace style) data to the column.

Once the code was deployed I created a new column on the library and uploaded a new document. From the information written to the Debug field I could quickly see that the problem and remedy take appropriate action.

Once fixed, simply delete the Debug column knowing that the facility is there should I need it again. There is a slight overhead here in that the column is looked for whenever the code runs, but this is a small price to pay for the flexibility I gained.

Try it out and let me know your comments or suggestions. I’d love to hear from you.

David Severn