In the last release of the BizTalk Deployment Framework, an additional feature was
added that I thought deserved its own post for explanation...
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. This makes post-mortem
analysis a lot harder...
A new custom NAnt task (getgacpath) and corresponding support within BizTalkDeploymentInclude.nant
was added for placing PDB (program database) files for all BizTalk and component assemblies
into the GAC. (You can use just this NAnt task without the rest of the Deployment
Framework, of course. In addition, a standalone command line utility called
GetGacPath has been included in the "Tools" download.)
Why is this interesting? Well, because it allows you to get stack traces that
include file and line number information even when assemblies reside in the GAC.
(This is obviously useful and useable outside the domain of BizTalk...) Without
extra work, file and line number information is generally missing from a stack
trace if a PDB file is not co-located physically with the corresponding assembly.
Putting the PDB file directly into the GAC is an easy way of solving this problem.
Set the "deployPDBsToGac" NAnt property to "true" in your project-specific NAnt file
to get this functionality.
A couple of points are worth mentioning:
 ERROR BizTalkSample.Orchestrations.TopLevelOrch - An exception was caught.
System.Exception: Something exceptional happened.
at BizTalkSample.Orchestrations.TopLevelOrch.segment2(StopConditions stopOn) in
c:\Documents and Settings\Scott\Local Settings\Temp\h0li3wbi.0.cs:line 2538