In my last
post I indicated there was a better story in BizTalk 2006 for working with the
C# code that is generated as an intermediate when compiling ODX (orchestration)
files – that is, better than having to deal with temporary files and the BizTalk
2004 File Dump utility.
I
If you’ve worked with BizTalk 2006, you might have already stumbled across this.
The xlang compiler for BizTalk 2006 is kind enough to place the intermediate C# file
for your ODX directly in the project directory. If you have multiple orchestrations
in an assembly, you will find a C# file for each orchestration – but only one of
those files will actually have content (all the generated C# code is consolidated
into one file.)
What this means is that you can do symblic debugging of orchestrations in a fashion
far easier than what I
described for BizTalk 2004. The Edit/Debug cycle might look like this:
- Build your orchestration project.
-
Open the associated (generated) C# file – perhaps make it a solution item
for convenience. -
Search for something in one of your expression shapes (say “MyClass.Execute”), and
set a breakpoint. -
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 for this case. - Trigger your orchestration however you normally would.
- Find your problem, Debug-Detach All, and fix the problem in the orchestration.
-
Decide that you really want Gilles’
MessageContext Debugger Visualizer
There is another benefit to having the generated C# files for orchestrations be more
accessible…If you deploy your PDBs
to the GAC, either using either my upcoming deployment work for BizTalk 2006 or
just the GetGacPath2 utility that I made available here,
you will find that stack traces that are recorded in the event log actually reference
line numbers within the generated C# code.
As I said in an earlier post, if you are responsible for troubleshooting BizTalk applications
in production, you are likely hungry for all the information you can get about why
something is failing. Since all BizTalk project assemblies are in
the GAC, the stack traces you get (either from your own logging, or the event logs
BizTalk generates for unhandled exceptions) do not contain file and line number information
by default. This makes post-mortem analysis a lot harder…
When a BizTalk 2006 application is deployed to production, you might consider archiving
the generated C# code for production support. If you use GetGacPath2 to
put PDBs in the GAC, you will have file and line number information within captured
stack traces to aid in troubleshooting. (Note that GetGacPath2 supports MSIL,
32 bit, and 64 bit assembly caches. MSIL is the right choice for BizTalk 2006
projects.)