By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,476 Members | 889 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,476 IT Pros & Developers. It's quick & easy.

Debugging a VB.Net DLL

P: n/a
Hi everyone,

I have a DLL and a console app I'm using together, both created in VB
..Net. I've added both projects to a Visual Studio solution, and have a
breakpoint set on my console app, where it calls a public method on one of
the dll's objects.

When I reach my console app's breakpoint and hit F11 to "step into" the
dll method, I just skip to the next line of the console app. That is,
unless I have a breakpoint set on the dll's method.

Is that behavior by design, or can I arrange things so that I don't need to
set breakpoints in ancillary projects when debugging my main app? Thanks
for helping me clear this up.

-Jim


Nov 20 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Did you set a reference to the project or the file dll? If you set it to the
file reference, this is the behavior you can expect.

Steve

"Jim Bancroft" <bo********@nowhere.com> wrote in message
news:et**************@tk2msftngp13.phx.gbl...
Hi everyone,

I have a DLL and a console app I'm using together, both created in VB
.Net. I've added both projects to a Visual Studio solution, and have a
breakpoint set on my console app, where it calls a public method on one of
the dll's objects.

When I reach my console app's breakpoint and hit F11 to "step into" the
dll method, I just skip to the next line of the console app. That is,
unless I have a breakpoint set on the dll's method.

Is that behavior by design, or can I arrange things so that I don't need to set breakpoints in ancillary projects when debugging my main app? Thanks
for helping me clear this up.

-Jim

Nov 20 '05 #2

P: n/a
Hi Steve,

Well, you're right in that I did set a reference to the file dll originally.
But I'm not quite sure how to set a reference to the project, instead of the
file-- when adding references this time I clicked the "Project" tab (I
removed my file reference first), and sure enough my dll project was right
there. I selected it, am now using it, but the problem remains.

I must be doing something wrong-- maybe I didn't pick the "project"
reference correctly? In case you hadn't guessed, I'm somewhat new to
multi-project debugging in .Net.

-Jim
"Steve Long" <St**********@NoSpam.com> wrote in message
news:eg*************@TK2MSFTNGP10.phx.gbl...
Did you set a reference to the project or the file dll? If you set it to the file reference, this is the behavior you can expect.

Steve

"Jim Bancroft" <bo********@nowhere.com> wrote in message
news:et**************@tk2msftngp13.phx.gbl...
Hi everyone,

I have a DLL and a console app I'm using together, both created in VB .Net. I've added both projects to a Visual Studio solution, and have a
breakpoint set on my console app, where it calls a public method on one of the dll's objects.

When I reach my console app's breakpoint and hit F11 to "step into" the dll method, I just skip to the next line of the console app. That is,
unless I have a breakpoint set on the dll's method.

Is that behavior by design, or can I arrange things so that I don't need

to
set breakpoints in ancillary projects when debugging my main app? Thanks for helping me clear this up.

-Jim


Nov 20 '05 #3

P: n/a

Well, I'm not sure which layout you are using in your IDE, I have the VB
developer selected so when I hit F8, it steps into. However, you probably
left it as default so F11 is probably step into.

Nowever, if you remove the reference to the file dll and then add the
reference to the project dll, that should work. Sometimes you have to close
down the IDE and reopen it for things to work right. I don't know why that
is. NTL, if you put a break point in your dll project, you should be able to
step into it just fine.

Steve

"Jim Bancroft" <bo********@nowhere.com> wrote in message
news:Ok**************@TK2MSFTNGP10.phx.gbl...
Hi Steve,

Well, you're right in that I did set a reference to the file dll originally. But I'm not quite sure how to set a reference to the project, instead of the file-- when adding references this time I clicked the "Project" tab (I
removed my file reference first), and sure enough my dll project was right
there. I selected it, am now using it, but the problem remains.

I must be doing something wrong-- maybe I didn't pick the "project"
reference correctly? In case you hadn't guessed, I'm somewhat new to
multi-project debugging in .Net.

-Jim
"Steve Long" <St**********@NoSpam.com> wrote in message
news:eg*************@TK2MSFTNGP10.phx.gbl...
Did you set a reference to the project or the file dll? If you set it to the
file reference, this is the behavior you can expect.

Steve

"Jim Bancroft" <bo********@nowhere.com> wrote in message
news:et**************@tk2msftngp13.phx.gbl...
Hi everyone,

I have a DLL and a console app I'm using together, both created in VB .Net. I've added both projects to a Visual Studio solution, and have a breakpoint set on my console app, where it calls a public method on one of
the dll's objects.

When I reach my console app's breakpoint and hit F11 to "step into" the dll method, I just skip to the next line of the console app. That
is, unless I have a breakpoint set on the dll's method.

Is that behavior by design, or can I arrange things so that I don't
need to
set breakpoints in ancillary projects when debugging my main app?

Thanks for helping me clear this up.

-Jim



Nov 20 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.