F5: Possibly the most important key for the Visual Studio developer, the F5 is the shortcut to debug the current project. Visual Studio 2010 supports SharePoint debugging but in order to achieve maximum functionality, the developer will have to complete a few steps.
1. The first time the F5 key is pressed to debug a SharePoint solution, Visual Studio will ask the user whether he/she wants to allow it to configure the web.config on the SharePoint server, to support the degugging session (screenshot). The user should answer yes, otherwise he/she would have to complete the steps manually, risking unecessary errors.
2. If the current project is a workflow, the developer should know that although F5 will kick start the debugging session, the actual workflow will not be initiated by the debugger. The developer needs to manually initiate the workflow. Also, take note that, specifically for workflows, any additional assemblies that are being used by the workflow, will need to be placed in the Global Assembly Cache (GAC).
3. If the current project is a feature event receiver, the developer should not choose to have Visual Studio activate the feature. Instead, the developer should disable activation in the project settings and activate the feature event receiver manually so that it is in the same process as the debugger.
4. The developer should opt to enable advanced debugging in the Visual Studio environment, in order to receive all the information that Visual Studio is receiving from SharePoint via the stack trace (because SharePoint builds on top of so many technologies). To achieve that, some manual work has to be done: i. start up the registry editor (type regedit in the RUN field of the start menu) and locate the key: [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\SharePointTools]. There, change EnableDiagnostics from 0 to 1. If the specific DWORD is not present, create it.
5. A new item for the developer’s toolbox is the Developer’s Dashboard. This allows the developer to examine what calls are being made and whether it is his/her own code slowing down the system or if it is SharePoint itself. The Developer’s Dashboard is default to off so the developer will need to enable it. However, the Developer Dashboard does not come in binary on/off. It also supports the “on demand” option which puts a icon in the upper right hand corner of the site that once pressed, enables the Developer Dashboard in the bottom section of the screen. There is a number of ways the developer can use to activate the Developer Dashboard and they can all be checked by making the jump here. For more information about debugging custom code with the Developer Dashboard, make the jump here.
6. Debugging with the SharePoint 2007 platform meant casual and time wasting visits to the log files. With the introduction of the Developer Dashboard, these visits are now -almost- obsolete. However, for the few times that you will need to peak into the logs, it is good to know that the Developer Dashboard includes the Correlation IDs for the events that show up in the dashboard. This makes it a lot easier to find the events inside the logs. Furthermore, although any text editor can be used to read the Unified Logging System (ULS) files, the ULSViewer is a great tool to use that makes reading the files easier. This is an unsupported tool and can be downloaded off MSDN here. Note that this tool is not SharePoint 2010 specific as it will work just as well against SharePoint 2007 log files.
7. Silverlight debugging with Visual Studio is not enabled by default. In order to enable it, you will need to change the SharePoint properties of your project and tick the “Enable Silverlight debugging” checkbox.
Powered by Zoundry Raven
