Second Life of a Hungarian SharePoint Geek

May 18, 2010

Interesting registry settings to help debugging SharePoint Tools Extensions in Visual Studio 2010

Filed under: SP 2010, VSX — Tags: , — Peter Holpar @ 03:10

Today I found a page on MSDN about Debugging Extensions for the SharePoint Tools in Visual Studio. At the end of the page there is a table of some registry settings that can be used to change the behavior of Visual Studio and may help troubleshooting.

If you would like to use these settings, you have to create the DWORD values under the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\SharePointTools key.

For me probably the most exciting one is the AttachDebuggerToHostProcess that can be used to attach to the vssphost4.exe immediately after it starts.

I’ve check it and – as expected – it can be used not only for the custom extensions but the built in tools either. So, for example, it can be used to attach the debugger to the feature receiver process when deploying the feature from the Visual Studio deployment steps.

The following dialog box is raised on the deployment:

image

The details show that the reason for the prompt is really the injected Debugger.Break statement as documented.

image

You should choose the Debug the program option, and select the Visual Studio instance for debugging.

image

After selecting the Visual Studio instance that is just deploying the solution, it is attached to the host process as shown below:

image

Setting the value of EnableDiagnostics to 0 will disable displaying diagnostic messages in the Output window.

The ChannelOperationTimeout and the HostProcessStartupTimeout settings can be used to specify the timeout values Visual Studio waits for a command to execute or the host process (vssphost4.exe) to launch. Default values are 120 seconds and 60 seconds.

The last two documented settings, MaxReceivedMessageSize and MaxStringContentLength specify the maximum size of the  WCF messages and the strings (both in bytes with default of 1,048,576 bytes  = 1 MB) that allowed in the communication between Visual Studio and vssphost4.exe.

An important tip from the page for using the AttachDebuggerToHostProcess property:

“If you set this value to 1, you may also want to increase the HostProcessStartupTimeout value to give yourself enough time to attach the debugger before Visual Studio expects vssphost4.exe to signal that it started successfully.”

In my experience, if we wait to much the host process fails to start with the following error message:

Error occurred in deployment step ‘Add Solution’: The vssphost4.exe process was unable to start due to an unknown error or problem.

If you retry the deployment, you get no prompt for debugging, but an error message that states:

Error occurred in deployment step ‘Recycle IIS Application Pool’: The vssphost4.exe process was unable to start due to an unknown error or problem.

In this case the simplest solution is to restart Visual Studio.

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: