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).