Home Page › Forums › BizTalk 2004 – BizTalk 2010 › How to Debug a Custom C# Component Called by BizTalk
- This topic has 10 replies, 1 voice, and was last updated 9 years, 1 month ago by
community-content.
-
AuthorPosts
-
-
February 22, 2008 at 2:01 PM #18975
Is it possible to debug a C# assembly that is called from within a BizTalk orchestration?
We have a custom component that works fine when called directly from a windows app, but occasionally fails when called from a BizTalk orchestration – particularly during high-volume processing. I’d like to be able to debug through the component in BizTalk, but I can’t figure out how to get it to stop at the appropriate VS breakpoint.
Is this possible? How is it done?
Thanks!
-
February 22, 2008 at 10:53 PM #18978
You can debug by Attach to Process in Visual Studio
http://blogs.msdn.com/skaufman/archive/2004/06/22/162421.aspx
-
February 25, 2008 at 8:04 AM #18984
Thanks for your response, Max! Very interesting…I’ll give it a shot.
So, just to be sure…. I’ll need to build the component in debug mode, change the BT assembly references (or at least the one I want to debug) to point to the debug version, and change the BizTalk Application Resources to point to the debug version. Then, restart the service and proceed with debugging as described in the blog posting. Did I miss anything (or misunderstand anything)?
I appreciate your help! I’m a bit of a newbie on this stuff…
Kelly
-
February 26, 2008 at 10:52 AM #18991
Kelly, did you have any luck?
Load your custom assembly in Visual Studio, go to Debug->Attached to Process… and select BTSNTSvc.exe.
BTW be sure to set a break point in your custom assembly 😉
Greg
-
February 27, 2008 at 6:56 AM #18995
Nope…I haven’t had any success.
I built the component in Debug mode, replaced the GAC’ed assembly with the the debug assembly, replaced the reference in the BTS Assembly with the debug reference, replaced the BTS Application Resource reference with the debug reference, and deployed the BTS assembly that has the new reference. Finally I restarted the BTS service. I then used the Debug->Attach to Process to attach to BTSNTSvc.exe.
However, any breakpoint I set gets the “The Breakpoint will not currently be hit. No Symbols have been loaded for this document.” message and it won’t stop at the breakpoint.
I’ve googled this error and tried several solutions presented, but nothing is working.
I’m stumped… Any suggestions would be great…
-
March 1, 2008 at 2:12 PM #19010
Try manually undeploying the assembly from the GAC and then redeploying.
-
March 6, 2008 at 10:08 AM #19026
[quote user="jamesqua"]
Try manually undeploying the assembly from the GAC and then redeploying.
[/quote]
Yep, I did this without success. I GAC’ed the debug version.
Since it’s not a BizTalk component, I have to do all the GAC work manually rather than deploying from VisualStudio.
Thanks for the thought.
-
-
January 30, 2009 at 3:51 PM #21612
Hi Everyone,
After abandoning this issue for almost a year, I finally resolved this issue, and thought I’d share the solution for anyone else who has this problem in the future.
The short answer is that I didn’t go far enough. After I built the component in debug mode, I correctly GAC’ed the DLL and updated the reference for the calling project to point to the Debug version and updated the Admin Console Reference to the Debug version, then restarted the Host Instance.
At this point, when I did “Attach to Process” within the custom component, the breakpoints were still appearing with the same message as before: “The Breakpoint will not currently be hit. No Symbols have been loaded for this document.”
However, when I “ignored” this error and proceeded with submitting a message through BizTalk, the custom component “woke up” and realized that it was going to be called. The breakpoint errors went away, and debugging worked exactly as it was supposed to!
YAY!
Thanks to those of you who pointed me in the right direction.
-
February 16, 2009 at 8:28 PM #21752
Normal
0false
false
falseEN-US
X-NONE
X-NONEMicrosoftInternetExplorer4
<!–
/* Font Definitions */
@font-face
{font-family:”Cambria Math”;
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-charset:1;
mso-generic-font-family:roman;
mso-font-format:other;
mso-font-pitch:variable;
mso-font-signature:0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:-1610611985 1073750139 0 0 159 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:””;
margin-top:0in;
margin-right:0in;
margin-bottom:10.0pt;
margin-left:0in;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Calibri”,”sans-serif”;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:”Times New Roman”;
mso-bidi-theme-font:minor-bidi;}
.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:”Times New Roman”;
mso-bidi-theme-font:minor-bidi;}
.MsoPapDefault
{mso-style-type:export-only;
margin-bottom:10.0pt;
line-height:115%;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.Section1
{page:Section1;}
–>/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin-top:0in;
mso-para-margin-right:0in;
mso-para-margin-bottom:10.0pt;
mso-para-margin-left:0in;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Calibri”,”sans-serif”;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:”Times New Roman”;
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;}Great work
-
April 14, 2010 at 4:22 AM #24563
Hi,
I experienced this when the assembly in the GAC was locked by a process – if I ran gacutil /u on the assembly, it failed with message “The process cannot access the file because it is being used by another process”. After I resolved this, ran gacutil /u successfully and redeployed, the breakpoint warning disappeared.
Cheers,
Ant
-
August 22, 2013 at 4:18 AM #26125
"However, when I "ignored" this error and proceeded with submitting a message through BizTalk, the custom component "woke up" and realized that it was going to be called. The breakpoint errors went away, and debugging worked exactly as it was supposed to!"
Perfect ! That solved my problem … Thanks a lot !
-
-
-
-
-
-
-
AuthorPosts
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.