I have seen a lot developers struggle with debugging pipeline components and other .NET classes that get executed by BizTalk host instances. I have also often heard statements claiming that these sorts of artifacts are hard or impossible to debug in the BizTalk runtime. I would very much like to clear up this notion for those who aren’t clear on how to debug such artifacts and to describe how one can debug them.

The first thing you need to do is to ensure that your component has been installed to the pipeline components folder (for pipeline components) or to the GAC (for other .NET assemblies) in its debug build profile, as this is a prerequisite to being able to debug your code. The next thing you need to do is to get the process ID (PID) for the relevant BizTalk host instance that is going to be executing your code, this is most important if you have multiple BizTalk host instances running in your environment as you need to know exactly which one to attach to and Visual Studio will not list them by host name, only by PID. In order to do this you need to open task manager (CTRL + SHIFT + ESC) and browse to the services tab. If you sort by name you should see a list of all your BizTalk host instances by name and the PIDs in the next column as below. Take note of the PID you are interested in attaching to.

TaskManager

Next up, open your Visual Studio project and apply breakpoints in your code wherever you want to by navigating to the line you want to break on and pressing F9.

Breakpoint

Next, expand the Debug option in the file menu and choose attach to process. Highlight the BizTalk service with the PID matching the one you took note of from the task manager and choose to attach to it. Note that if the host instance is running under another user’s account then you will need to tick the checkbox option “Show processes from all Users” in order to see it displayed in the list.

Attach to process

Your instance of Visual Studio is now attached the BizTalk host instance in question and anytime the host instance executes code upon which you have placed a breakpoint, Visual Studio will enter debugging mode and you will be able to step through the code / inspect objects and properties etc… For a nice guide on the basics of debugging check out the article “Mastering Debugging in Visual Studio 2010 – A Beginner’s Guide“, while the article is focused on Visual Studio 2010 the majority of the practices described apply to earlier and later versions of Visual Studio as well.