Debugging BizTalk is pretty simple from within HAT. See HAT BizTalk debugging for further info on that, it should be everywhere. Things get only slightly more complicated when you want to debug a .NET component that is being invoked from an orchestration.
If an orch is going to invoke a .NET component you first install the component to the GAC. At runtime it will run within the BTSNTSvc.exe process. So just open your .NET component, set your breakpoints and use Debug > Processes to attach to the BTSNTSvc process.
Now when you execute your orchestration, it will pause on your breakpoint when you get to the stage where the orchestration calls your component and you can step through as you normally would.
Make a script to automatically redeploy your orchestrations and components, if they are out-of-date, debugging will not work (I'll address how to create this script in another blog, but several solutions are “out there“ already if you take a look at some of the more prominent BizTalk blogs)
Caveats:
- Be sure that you build and redeploy your .NET component(s) AND your BTS assemblies before debugging, this is the #1 reason why debugging fails or gives unexpected results on step through
- SysInternal's DebugView does not catch trace messages when you attach to the BizTalk server process in this way, the output is intercepted by VS.net so look for your trace messages in the output window NOT in the DebugView console (This behaviour is by design and makes sense if you think about the message interception)