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.
Original Source: SharePoint Debugging - Jeremy Thake
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
Tools for Debugging
Attach to Process within SharePoint site
There is a great feature available on CodePlex (called 'Debugger Feature') that allows you to force your SharePoint site to launch a debugger which will always guarantee you get the correct process written by Jonathan Dibble. More information available here at MSDN Blogs .
DebugView
Debug View is a great tool for development that when left running on the server can display any debug messages written to Debug.WriteLine.
SPTraceView
SPTraceView is a great way to monitor the trace logs in real time. You can see Exceptions popup from your taskbar.
Thanks,
Rajesh Batchu,
Share Point Developer,
+1 23456 4 234 8
No comments:
Post a Comment