468,168 Members | 1,649 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,168 developers. It's quick & easy.

Debugging external classes

I'm having troubles getting the debugging process to work consistenly for
external classes. I got it to work once and then I turned it off. But now I
can't get re-enabled. Here is what I'm doing. If someone could tell me what
I'm missing that would be great.

1. Create an external class and call it Test.dll.
2. Create a test Asp.net app called App.sln.
3. For App.sln I set a reference to Test.dll.
4. Compile App.sln and run it. The web page opens and it cals Test.dll fine.
5. Go back into Test.dll and set the Config/Debug properties to be:
Debug Mode - URL
Start URL - http://localhost/app/Index.aspx
6. Set a breakpoint in Test.dll.
7. Run Test.dll and the web page starts but the breakpoint doesn't get
triggered.

This didn't work, so I go back into Test.dll and try the following:
8. Set the Config/Debug properties to be:
Debug Mode - Project
Start Page - http://localhost/app/index.aspx.
9. I try to run Test.dll and get an error that it can't be run directly so
instead I launch the web app manually. The breakpoint doesn't get triggered.

I'm stuck here. The time it DID work I was when I ran the web page and it
immediately found the breakpoint in Test.dll and paused execution on the
proper line of code in Test.DLL. But I can't figure out how to recreate this
and I'm going around in circles. My breakpoints are always ignored.

Thanks for any help.

Brian

Dec 8 '05 #1
3 1532
double check that you are compiling in Debug and not Release.

Dec 8 '05 #2
Yeah, I definitely have that taken care of and it copies the .pdb file to
the local directory. So are you implying that what I'm doing is right? It's
so strange b/c the first time I did this it worked fine and I just assumed
it was a trivial exercise. But now that it doesn't work anymore I'm racking
my brain trying to figure out what is different this time.

Brian
"john_teague" <jc******@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
double check that you are compiling in Debug and not Release.

Dec 8 '05 #3
Over the past couple of hours I learned some interesting points about
debugging external DLLs/classes.

1) If the app is fairly complex where you have multiple DLLs you can run
into problems if you aren't careful with cross-referencing. For any
supporting DLL that references another DLL, set Copy Local=False. Otherwise
when you compile the main app, it tries to copy the DLLs on top of each
other and reports errors. It looks like when it loads a DLL then it tries to
load all the DLLs in the same folder since they are referenced. The only
place where you can set Copy Local=True is in the main app.
2) To debug an external DLL, the main app must reference it with the DLLs
bin folder. If you reference the copy from the main app's local folder then
it won't debug it. I say this b/c you have to double check the folder
location. I have one DLL that I reference from it's bin folder and
everything looks great. But when I compile the main app it overwrites the
folder reference and makes it point to the app's folder. All my other DLL
references still reference the appropriate bin folder, but this one DLL
keeps getting its reference overwritten after I compile the app and I can't
figure out why. Consequently, I can't debug this DLL b/c it isn't
referencing the DLL's bin folder.
3) When changing the Config|Debug property DebugMode, you have to click the
Apply button after selecting the property from the dropdown list. The other
textboxes below it stay disabled until clicking the Apply button, This drove
me crazy for a full day b/c I would say that I want the debug mode to be URL
and the URL property stayed disabled and I couldn't specify the URL address.
I finally got lucky and clicked Apply by mistake and saw that the URL
property immediately became enabled. I would say this is a bug and I hope
they fixed it in 2.0 b/c it's a tough one to figure out.
4) Another way to debug a DLL is to do it within a single instance of the
IDE and running the main app. Add the DLLs project to the main app's
solution to debug the DLL. Again, this only works if the main app is
referencing the DLL from the DLLs bin folder.
5) If you follow all the rules above, then you can open DLL in the IDE and
the option to debug from an external URL or an EXE works fine. Run the DLL
and the appropriate URL or EXE will open and your breakpoints will be hit.
In my earlier posts I reported that this wouldn't work, but that was because
rule #2 above wasn't being followed.
Hope this little FAQ helps anyone struggling to debug DLLs like I did for
the past two days.
Brian Bischof
www.CrystalReportsBook.com

"Brian Bischof" <bi******@hotmailx.com> wrote in message
news:us**************@TK2MSFTNGP10.phx.gbl...
Yeah, I definitely have that taken care of and it copies the .pdb file to
the local directory. So are you implying that what I'm doing is right?
It's so strange b/c the first time I did this it worked fine and I just
assumed it was a trivial exercise. But now that it doesn't work anymore
I'm racking my brain trying to figure out what is different this time.

Brian
"john_teague" <jc******@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
double check that you are compiling in Debug and not Release.


Dec 9 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

16 posts views Thread by Serdar Kalaycý | last post: by
1 post views Thread by DEWright_CA | last post: by
6 posts views Thread by Brian Bischof | last post: by
23 posts views Thread by keyser_Soze | last post: by
reply views Thread by Ken Allen | last post: by
2 posts views Thread by A_StClaire_ | last post: by
3 posts views Thread by vbMark | last post: by
reply views Thread by gcreed | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.