Debugging DLLs skips breakpoints

[Brian Bischof]

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 in debug mode 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 it seemed very simple and I didn't pay
a lot of attention to what I did. But now that it doesn't work anymore I'm
racking my brain trying to figure out what setp I'm missing. The breakpoints
in my DLL are always ignored.

Thanks for any help.

Brian

 

[Stoitcho Goutsev \(100\) [C# MVP]]

Brian,

Make sure that in the application's bin folder along with the dll there is
file with the same name, but extension 'pdb'. Without this file the debuger
won't stop on break points.

 

[Brian Bischof]

Yes, the pdb files are the main apps' bin folder as well. Is there some
trick to getting an ASP.NET app to debug an external DLL?

Brian,

Make sure that in the application's bin folder along with the dll there is
file with the same name, but extension 'pdb'. Without this file the
debuger won't stop on break points.


--

Stoitcho Goutsev (100) [C# MVP]

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 in debug mode 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 it seemed very simple and I didn't
pay a lot of attention to what I did. But now that it doesn't work
anymore I'm racking my brain trying to figure out what setp I'm missing.
The breakpoints in my DLL are always ignored.

Thanks for any help.

Brian

 

[Stoitcho Goutsev \(100\) [C# MVP]]

Brian,

Basically, in order to debug web application you have to set in the
application web.config
<compilation> element's attribute debug to "true"
e.g. <compilation defaultLanguage="c#" debug="true"/>
This flag has noting to do with the VS project configuration.

But I don't thing this is your problem because VS warn's if one runs with
debugger and this flag is off.

Usually when debugging ASP.NET application there is no problem to debug any
external dll which is compiled in debug version as long as the pdb file is
in the same folder where the dll is loaded from.
BTW make sure that the DLL is compiled in debug mode.

When you run the web application in the dubgger look at the VS's output
window. It shows the progress of loading the dlls as well as it gives
ingormation for each DLL whether the debug symbols are loaded or not. If
debug symbols are not loaded it won't stop on break points. Find in the
output window the path where ASP.NET loads your dll from and check if the
PDB file is in this folder (you know that ASP.NET runtime caches the
assemblies it doesn't load directly from application's bin folder).


--

Stoitcho Goutsev (100) [C# MVP]

Yes, the pdb files are the main apps' bin folder as well. Is there some
trick to getting an ASP.NET app to debug an external DLL?

Brian,

Make sure that in the application's bin folder along with the dll there
is file with the same name, but extension 'pdb'. Without this file the
debuger won't stop on break points.


--

Stoitcho Goutsev (100) [C# MVP]

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 in debug mode 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 it seemed very simple and I didn't
pay a lot of attention to what I did. But now that it doesn't work
anymore I'm racking my brain trying to figure out what setp I'm missing.
The breakpoints in my DLL are always ignored.

Thanks for any help.

Brian

 

[Brian Bischof]

Yes, the problem is not with debugging an APS.NET app, it's with setting a
breakpoint in an external DLL source file and the breakpoint gets skipped.

I looked at the log of loading DLLs and it keeps giving me errors that it
can't load a DLL b/c it would overwrite the existing DLL already there. This
is because I use multiple DLLs and they reference common libraries. Thus, it
looks like it tries to reload the common library for every DLL that uses it
and gives an error that they are overwriting each other. What a pain! I'm
going to try to fix the errors of overwriting these libraries and see if
that helps me make progress.

Any other ideas are appreciated.

Brian

Brian,

Basically, in order to debug web application you have to set in the
application web.config
<compilation> element's attribute debug to "true"
e.g. <compilation defaultLanguage="c#" debug="true"/>
This flag has noting to do with the VS project configuration.

But I don't thing this is your problem because VS warn's if one runs with
debugger and this flag is off.

Usually when debugging ASP.NET application there is no problem to debug
any external dll which is compiled in debug version as long as the pdb
file is in the same folder where the dll is loaded from.
BTW make sure that the DLL is compiled in debug mode.

When you run the web application in the dubgger look at the VS's output
window. It shows the progress of loading the dlls as well as it gives
ingormation for each DLL whether the debug symbols are loaded or not. If
debug symbols are not loaded it won't stop on break points. Find in the
output window the path where ASP.NET loads your dll from and check if the
PDB file is in this folder (you know that ASP.NET runtime caches the
assemblies it doesn't load directly from application's bin folder).


--

Stoitcho Goutsev (100) [C# MVP]

Yes, the pdb files are the main apps' bin folder as well. Is there some
trick to getting an ASP.NET app to debug an external DLL?

Brian,

Make sure that in the application's bin folder along with the dll there
is file with the same name, but extension 'pdb'. Without this file the
debuger won't stop on break points.


--

Stoitcho Goutsev (100) [C# MVP]

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 in debug mode 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 it seemed very simple and I didn't
pay a lot of attention to what I did. But now that it doesn't work
anymore I'm racking my brain trying to figure out what setp I'm
missing. The breakpoints in my DLL are always ignored.

Thanks for any help.

Brian

 

[Brian Bischof]

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

Yes, the problem is not with debugging an APS.NET app, it's with setting a
breakpoint in an external DLL source file and the breakpoint gets skipped.

I looked at the log of loading DLLs and it keeps giving me errors that it
can't load a DLL b/c it would overwrite the existing DLL already there.
This is because I use multiple DLLs and they reference common libraries.
Thus, it looks like it tries to reload the common library for every DLL
that uses it and gives an error that they are overwriting each other. What
a pain! I'm going to try to fix the errors of overwriting these libraries
and see if that helps me make progress.

Any other ideas are appreciated.

Brian

Brian,

Basically, in order to debug web application you have to set in the
application web.config
<compilation> element's attribute debug to "true"
e.g. <compilation defaultLanguage="c#" debug="true"/>
This flag has noting to do with the VS project configuration.

But I don't thing this is your problem because VS warn's if one runs with
debugger and this flag is off.

Usually when debugging ASP.NET application there is no problem to debug
any external dll which is compiled in debug version as long as the pdb
file is in the same folder where the dll is loaded from.
BTW make sure that the DLL is compiled in debug mode.

When you run the web application in the dubgger look at the VS's output
window. It shows the progress of loading the dlls as well as it gives
ingormation for each DLL whether the debug symbols are loaded or not. If
debug symbols are not loaded it won't stop on break points. Find in the
output window the path where ASP.NET loads your dll from and check if the
PDB file is in this folder (you know that ASP.NET runtime caches the
assemblies it doesn't load directly from application's bin folder).


--

Stoitcho Goutsev (100) [C# MVP]

Yes, the pdb files are the main apps' bin folder as well. Is there some
trick to getting an ASP.NET app to debug an external DLL?




Brian,

Make sure that in the application's bin folder along with the dll there
is file with the same name, but extension 'pdb'. Without this file the
debuger won't stop on break points.


--

Stoitcho Goutsev (100) [C# MVP]

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 in debug mode 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 it seemed very simple and I
didn't pay a lot of attention to what I did. But now that it doesn't
work anymore I'm racking my brain trying to figure out what setp I'm
missing. The breakpoints in my DLL are always ignored.

Thanks for any help.

Brian

 

[Guest]

Hi Brian,

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

Make sure that every library (dll) is only compiled once, so that you don't
have any version problems. I'm saying this in response to your first point
(copy dll's on top of each other???). So don't embed the library's project in
any other project.

What I do if I have a library that is referenced by multiple projects, is to
compile it and write the dll+pdb to a central bin folder (a central folder
outside any project folder). Then have your projects reference the library in
the central bin folder. The dependencies are less trivial this way because
you would have to manage build-order yourself. You can keep CopyLocal=True.

This works for me in my project. For instance, I can debug my logging
library from another project by setting breakpoints inside code from the
logging library. It is possible that the debugger asks you where to search
for the code-file; just navigate to the correct directory that contains the
code, and you're all set.

Don't know if this is of any help, but I hope it does =)

Kind regards,