Normally, we can debug almost all pipeline components in run-time mode by attaching Visual Studio to the BTSNTSvc.exe process (see: Debugging External assemblies or pipeline components – Attach to Process – which BizTalk process to use?)
This is true for components that are running on an In-Process Host. The exception is Custom Pipeline Components that are running on an Isolated Host.
📝 One-Minute Brief
Debugging BizTalk custom pipeline components usually involves attaching Visual Studio to the BTSNTSvc.exe process. However, components running on an Isolated Host (like those using WCF or HTTP adapters) run under IIS. To debug these, you must attach to the w3wp.exe process. This post explains how to trigger the process by accessing the receive location URL and correctly identifying the target process for successful real-time debugging.
One of the differences between an Isolated Host and an In-Process Host is that an Isolated Host must run under another process, in most cases, IIS, and an In-Process Host is a complete BizTalk service alone.
So, if you are using custom pipelines that are associated, for example, with HTTP, SOAP, or WCF Adapter, then you need to attach to the properly isolated host process, in this case, the w3wp.exe process.
Note:
The application pool process (w3wp.exe) is typically not started until the first request is received.
You can use a browser to access the receive location URL. This should return a WSDL and should cause the w3wp.exe process to initiate.
Related articles
Special thanks
One of the pleasures of trying to help other people is that sometimes you learn some things, and this is one of these cases, thanks to Ritesh.
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.
