Debugging DLLs skips breakpoints

**Stoitcho Goutsev \(100\) [C# MVP]** · Dec 8 '05, 09:15 PM

Re: Debugging DLLs skips breakpoints

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]

"Brian Bischof" <bischofb@hotma ilx.com> wrote in message
news:un$xu8C$FH A.356@TK2MSFTNG P12.phx.gbl...[color=blue]
> 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
>
>
>[/color]

**Brian Bischof** · Dec 8 '05, 09:25 PM

Re: Debugging DLLs skips breakpoints

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?

"Stoitcho Goutsev (100) [C# MVP]" <100@100.com> wrote in message
news:uFrVKqD$FH A.1256@TK2MSFTN GP15.phx.gbl...[color=blue]
> 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]
>
> "Brian Bischof" <bischofb@hotma ilx.com> wrote in message
> news:un$xu8C$FH A.356@TK2MSFTNG P12.phx.gbl...[color=green]
>> 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
>>
>>
>>[/color]
>
>[/color]

**Stoitcho Goutsev \(100\) [C# MVP]** · Dec 8 '05, 10:25 PM

Re: Debugging DLLs skips breakpoints

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]

"Brian Bischof" <bischofb@hotma ilx.com> wrote in message
news:ehK2suD$FH A.2036@TK2MSFTN GP14.phx.gbl...[color=blue]
> 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?
>
>
>
>
> "Stoitcho Goutsev (100) [C# MVP]" <100@100.com> wrote in message
> news:uFrVKqD$FH A.1256@TK2MSFTN GP15.phx.gbl...[color=green]
>> 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]
>>
>> "Brian Bischof" <bischofb@hotma ilx.com> wrote in message
>> news:un$xu8C$FH A.356@TK2MSFTNG P12.phx.gbl...[color=darkred]
>>> 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
>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

**Brian Bischof** · Dec 8 '05, 11:45 PM

Re: Debugging DLLs skips breakpoints

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

"Stoitcho Goutsev (100) [C# MVP]" <100@100.com> wrote in message
news:%23ILsTUE$ FHA.2324@TK2MSF TNGP11.phx.gbl. ..[color=blue]
> 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]
>
> "Brian Bischof" <bischofb@hotma ilx.com> wrote in message
> news:ehK2suD$FH A.2036@TK2MSFTN GP14.phx.gbl...[color=green]
>> 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?
>>
>>
>>
>>
>> "Stoitcho Goutsev (100) [C# MVP]" <100@100.com> wrote in message
>> news:uFrVKqD$FH A.1256@TK2MSFTN GP15.phx.gbl...[color=darkred]
>>> 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]
>>>
>>> "Brian Bischof" <bischofb@hotma ilx.com> wrote in message
>>> news:un$xu8C$FH A.356@TK2MSFTNG P12.phx.gbl...
>>>> 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
>>>>
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

**Brian Bischof** · Dec 9 '05, 01:05 AM

Re: Debugging DLLs skips breakpoints

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

https://www.CrystalReportsBook.com

"Brian Bischof" <bischofb@hotma ilx.com> wrote in message
news:Or3aLCF$FH A.3452@TK2MSFTN GP10.phx.gbl...[color=blue]
> 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
>
>
>
>
> "Stoitcho Goutsev (100) [C# MVP]" <100@100.com> wrote in message
> news:%23ILsTUE$ FHA.2324@TK2MSF TNGP11.phx.gbl. ..[color=green]
>> 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]
>>
>> "Brian Bischof" <bischofb@hotma ilx.com> wrote in message
>> news:ehK2suD$FH A.2036@TK2MSFTN GP14.phx.gbl...[color=darkred]
>>> 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?
>>>
>>>
>>>
>>>
>>> "Stoitcho Goutsev (100) [C# MVP]" <100@100.com> wrote in message
>>> news:uFrVKqD$FH A.1256@TK2MSFTN GP15.phx.gbl...
>>>> 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]
>>>>
>>>> "Brian Bischof" <bischofb@hotma ilx.com> wrote in message
>>>> news:un$xu8C$FH A.356@TK2MSFTNG P12.phx.gbl...
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

**TT (Tom Tempelaere)** · Dec 12 '05, 02:55 PM

Re: Debugging DLLs skips breakpoints

Hi Brian,

"Brian Bischof" wrote:
[color=blue]
> 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[/color]

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,
--
Tom Tempelaere.

Debugging DLLs skips breakpoints

Debugging DLLs skips breakpoints

Comment

Comment

Comment

Comment

Comment

Comment