Thursday 20 February 2014

SharePoint Development Debugging

I've been reading a lot of posts on how to get debugging going when attaching to the w3wp.exe process.

Disable 'Enable Just My Code' in Visual Studio

This blog post started me off in the correct direction by setting the Tools | Options | Debugging setting correctly.

Modify the web.config

Furthermore, it prompted me to change the web.config value from debug="false" to debug="true". The web.config file can be found in the Inetpub\wwwroot\wss\VirtualDirectories\ folder, each folder in there maps to an IIS Web Application which you can find by going to IIS Manager and looking at the Home Directory.
To get full blown ASP.NET errors rather than SharePoint branded "useless" ones follow these steps:

Setting CallStack=true

By default, WSS will redirect a user to the error page whenever an unhandled exception is encountered during the render cycle.  To disable this behavior, open your web.config and set CallStack="true" in the <SafeMode> node.  This allows you to see a typical Asp.net error page.

Setting customErrors mode...

The next step would be set mode="Off" in the <customErrors> node.  This instructs Asp.net to show you a complete error report rather than a generic "Server Error" page.

Creating pdbs

For each project you wish to debug, you need to ensure that you are creating pdbs. I am using the really cool stsdev app to create my projects and had to modify it to create pdbs by going to Project Properties and on the Build tab in the Output Section click the Advanced button. 
Then ensure that Debug Info is set to pdb-only. 


Attach to Process

The author of the previous referenced post also pointed me to running iisapp on the command line to output a list of all the running instance to know which process to attach to:
Then when you select Debug | Attach to Process the ID matches to the PID in the output of iisapp. Note you need to check 'Show processes from all users' as w3wp.exe will be typically running as another account.

You can check that you have the correct id by pressing CTRL-ALT-U and this will list all the Modules that are loaded with statuses on the symbols that are available (e.g. that when you create a breakpoint it'll work rather than giving you a 'No symbols loaded' errror).

Sometimes there are just too many instances of w3wp.exe to pick from. An easy way to just let the system sort things out for you, rather than inserting a breakpoint, is to insert the following line in your code:
System.Diagnostics.Debugger.Break();

Notes for Visual Studio Debugging Newbies


Once you are actually debugging and can step through code after it breaks on a breakpoint...you can also use the Immediate window to inspect objects by pressing CTRL-ALT-I. From here you can get up intellisense on any object in context which is a great way to inspect things like whether a SharePoint list has an Event Receiver on it or not. 
 

The web server process that was being debugged has been terminated by Internet Information Services (IIS)

If you are debugging in IIS7.0 you will find that you will receive this error if you leave it on a break point for too long.



 
Unknown macro: {NewCode}
---------------------------
Microsoft Visual Studio
---------------------------
The web server process that was being debugged has been terminated by Internet Information Services (IIS). This can be avoided by configuring Application Pool ping settings in IIS. See help for further details.
---------------------------
OK Help
---------------------------

The Resolution is to follow these steps on MSDN - Error: Web site worker process has been terminated by IIS
 


Optimizing SharePoint sites



source: https://www.nothingbutsharepoint.com/sites/devwiki/SP2007Dev/Pages/SharePoint%20Development%20Debugging.aspx

No comments:

Post a Comment