As has been noted before in the lore of BizTalk, it sure would be useful to use a
real debugger with orchestrations – at least occasionally.

There are times when an expression shape winds up getting a bit sticky (not that I
would know…) and a debugger would be just the ticket.  Other times, the exception
you are getting from the orchestration engine isn’t at all clear.

Still other times, seeing the actual contents of messages or context as you step through
would be interesting.

Jon has posted
on debugging orchestrations (in IL) with an ILDASM/ILASM
, and had also discussed building your orchestration assemblies manually (using
xsharpp.exe).  (He correctly noted these approaches wouldn’t generate anything
supportable, but they work for spelunking.) 

I wanted to suggest something a bit different – I wanted to go back instead to the
venerable BTS File Dump utility that Charles
released in May of 2004 (before the GenerateCSFiles registry key was
discovered…) and propose a different technique for symbolic debugging.

First, install Charles’ BizTalk File Dump utility – you can download it from here. 
Fire it up, and change the output path in the utility to something easy, like c:\temp\BTSFileDump.

Here is the Edit/Debug cycle…(Start by making sure the file dump utility is running,
and click the “Start dumping files” button.)

  1. Build your orchestration project (or whole solution if need be.)

  2. Do a Ctrl-Shift-F (Find in Files) in Visual Studio, and change the “Look in:”
    folder to c:\temp\BTSFileDump

  3. Search for something in one of your expression shapes, say, “MyClass.Execute”. 
    The correct generated file (that the file dump utility grabbed) will appear in your
    Find Results – open it up, and set a breakpoint.  (Not on the xml designer portion
    – on the actual code!)

  4. From the Debug menu, choose Processes and attach to BTSNTSvc.exe.  (Have more
    than one?)  Choose CLR debugging only – not native.  The symbols should
    be loaded automatically – no need to copy PDBs to the GAC.

  5. Trigger your orchestration however you normally would.  Bask in a picture like
    this:  (Puts a Petzold-style WindowProc to shame…) 

  6. Use QuickWatch to examine message contents/context, if you like – you’ll be interested
    in expansions like
    this one (where sampleRequest is a message in the orchestration.)

  7. Find your problem, Debug-Detach All, and fix the problem in the orchestration.

  8. Click “Delete all files in output path” in the file dump utility (to avoid duplicates)
    and rebuild.  Repeat the process if you need to.  (To save time, consider
    an external tool that just re-GACs the orchestration assembly and resets the host
    process.  See here.)

Note that this technique will work in a production setting.  You could copy the
PDBs and sources to the production server, and use DbgClr.exe (in the Framework
SDK) or cordbg.exe to attach to the appropriate
host process.

Happy debugging…