Debugging SharePoint Code for On-Premises Development

So, over the years of working with SharePoint, I am sure like me you have had to debug code for SharePoint. If not, you are really missing out ☺

SharePoint even though using .NET is not the easiest sometimes to debug and track though little bugs that of course you never wrote in your code at all. Depending on what you are developing will determine what you use for debugging. In reality there are different tools for the types of code you write. The table below outlines some of the tools you could use:

Development Type	Optional Tools
Client Side using JavaScript or jQuery	Developer Tools in Browser, Fiddler, Postman, VSCode
Client Side using REST API	Developer Tools in Browser, Fiddler, Postman, VSCode
Server Side code using C#	Visual Studio

As you can see from the table, client side code can really be debugged using any tool that can inspect the client page load or intercept the request. Server side code however needs to be done the full debugging way, using the development IDE to step through code.

When building solutions for SharePoint, knowing which process to attach to, in order to debug is just as important as the code you write. For example, building a web part that sits within SharePoint will mean that you need to connect to the “w3wp.exe” process or “IIS” as you probably know it better, whereas a SharePoint Timer Job is not available in “w3wp.exe” as it runs in the context of the “owstimer.exe” process for SharePoint.

If we were debugging a SharePoint Timer Job for example, we need to perform the following items.

Generate the code and deploy
Copy the debug symbols to the server we are going to debug into the “Microsoft .NET” folder:

C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Sample

3. Restart the SharePoint Timer Service

Once done we can then from within Visual Studio connect to the “owstimer.exe” service and begin debugging as we would use the “w3wp.exe” option.

Once connected the SharePoint Timer Job can be ran and your Visual Studio code should then, based on your debug points step through line by line as needed.

If you are using multiple environments for your development and testing, then debugging can become a problem as you would in reality need to install Visual Studio within those SharePoint Farms. Now for Development this is fine but for your Staging or Production environment you would not want to install applications like that. Luckily Microsoft realized this many years ago and created the “Remote Debugging Tools and Agents”. To utilize remote debugging you need to download the version that matches your version of Visual Studio.

Visual Studio 2013: https://msdn.microsoft.com/en-us/library/y7f5zaaa(v=vs.120).aspx

Visual Studio 2015: https://msdn.microsoft.com/en-us/library/y7f5zaaa(v=vs.140).aspx

Once you have downloaded the debugger you need to copy it to the SharePoint Servers as needed and run the installer. As an example, if you were installing the Visual Studio 2015 version you would choose the following:

Once downloaded, copied to the servers, you can run the installer and follow the steps.

Now that the debugger is installed you can run the configuration option from the start menu.

This launches the configuration wizard for the machine that you are on so that you can make it available from that server. The wizard when launched will walk you through the setup of the service, specifically allowing you to set the account that you want to run it under. As noted the account needs to have “Log on as a Service” right.

For the debugger, I have specified the SharePoint Farm Services account, but it could be another account specifically chosen for it. Next we designate the firewall rules for the debugging service.

Once this is completed we can connect to a server remotely from the Visual Studio Debugging selector and specify the server name to connect to that we installed the debugger service onto.

Once selected we can debug our code the same way we did when testing it on a single server. This is a great way to debug code on other servers easily. This debugger will allow access to any of the services that reside on the other servers too.

SharePoint code debugging is not just isolated to Visual Studio and its tools. Debugging can be done using other tools such as WinDbg which allows you to break into the core code using a different tool. This does not allow you to step through the code but more see what has happened in the event of a crash dump being taken, or simply view any console statements that have been added to the code.

You can get the WinDbg tool from this link.

This tool is very useful and not just for debugging code, so be aware you will need to install most of the Windows Development SDK components to make it work. Once you have it all installed and ready you need to create a dump from the “w3wp.exe” process, by accessing the Task manager, right clicking the desired “w3wp.exe” process and choosing to create a dump file.

This can then be loaded into the WinDdg allowing for debugging and inspection. An article that was written quite a few years ago, by Kirk Evans from Microsoft, that still is a great example of this can be found using this link.

As you can see debugging SharePoint can be done using native Visual Studio and client side tools as well as Server Side Windows Debugging tools. The key is really determining what works best for you and your organization.

Comments

Plain text