| cduffy@ideacorporation.com 2006-02-26, 10:47 am |
| Hi Chris,
I've used the FFDASM successfully in the past, but find it far easier
to debug in real-time and in situ using the .Net debugger.
To do this :
*Build and deploy an assembly containing your pipe
*Set up a file or msmq receive port making sure to specify your pipe in
the configuration
*Disable the receive port
*Open your pipeline project
*Set a breakpoint (will probably show a question mark next to it)
*Attach to the biztalk host process from within the .net ide
*enable the receive port
*drop a message to the file or queue location configured in the receive
port
Be patient and your breakpoint will be hit. Now you have access to
watches and quickwatches of your code.
I've done a couple dozen pipes this way and once you get into it you
won't want to do it any other way :-)
This also works well for developing adapters ....
There were some other posts about writing to the event log for
debugging.
That's a method I very rarely use. When I want to debug
'non-interactively' I just use debug.writeline and pick up the output
with DebugView from www.sysinternals.com. The beauty of this method is
that you can view insanely high levels of debug information in realtime
without clogging and plodding through the event viewer.
Chuck
have your pipeline component project open in the ide, attach to the
biztalk
Chris wrote:[vbcol=seagreen]
> To tell you the truth, I have never used the pipeline debugger tool. It was
> easier for me to place debug statements in the code to write to the event
> viewer, and run a message through the deployed pipeline.
>
> The first time I installed and deployed the schema resolver project, it
> worked, so it very well could be an issue occurring due to the pipeline
> debugger.
>
> I would recommend just trying to start from scratch with the schemaresolver
> solution in the SDK, and add code in as needed. That is essentially what I
> did.
>
> Chris
>
> "jakew@nospam.nospam" wrote:
>
|