There are two methods I've come across:
1) Accessing the DLL project from the using project
This involves building the DLL in a separate instance of VS then accessing the DLL through a different project in VS (this assumes you have the source code).
There a number of ways to accomplish this:
- You can add Trace.WriteLine
statements in the DLL that will show
up in the 'Output' window in VS.
- You
can add
System.Diagnostics.Debugger.Break()
statements to the DLL code. When
running the calling project in VS,
program execution will stop there.
From here you can add access the
call stack (including all function
calls in DLL itself) and set break
points (although you the icon for
the break point will appear disabled
and the hover text for the break
point will read "The breakpoint will
not currently be hit. No symbols
have been loaded for this
document").
- If the DLL is throwing
an exception (which you can see from
the 'Output' window if the exception
is caught and handled by the DLL)
you can tell VS to always break when
that type of exception is thrown.
Hit Ctrl-Alt-E, find the type of
exception being thrown, and click
the 'Throw' column for that
exception. From here it is exactly
as if you had used
System.Diagnostics.Debugger.Break()
(see above).
2) Attaching a using process to the DLL project
This involved hooking the VS debugger into a running process.
- Open the DLL project in VS.
- Run an
application that uses the DLL (this
application can't be run from
another instance of VS since the
process will already have a debugger
attached to it).
- From here you can
add break points and step through
the DLL code loaded in VS (although
the break point will appear disabled
the same as in method 1).