Yes, this can be done, I do it every day. (Well, I was doing it every day in VS 2005 until we upgraded to VS 2008 a few months back, but it works the same in both versions).
You should have the project/solution in which you build your DLL loaded in Visual Studio. Then you should be able to attach to the third-party application, and Visual Studio will find the DLL loaded within it and enable your breakpoint. If the breakpoint is not enabling, the first thing I would look at is whether your DLL is actually loaded in the third party application. As someone pointed out you can see this in the Modules list in Visual Studio.
One trick that we use for situations like this is we have some code similar to this in the early startup code of our DLL:
#ifdef DEBUG
::MessageBox( NULL, "Attach debugger now", "ATTACH", MB_OK );
#endif
That way, only when debugging, you get a nice noticeable prompt that (a) your DLL did in fact load and (b) now is the time to attach the debugger. It's even fairly straightforward to build a Visual Studio macro that you can assign to a hotkey that will look for this popup in the process list and attach for you.
Warning: do NOT put this code in the DllMain() function of your DLL. It's rarely if ever safe to do anything significant in DllMain(). Instead, put it in the function that the third-party application calls first in whatever plugin API you are implementing.
If you never see the popup, then you know the third party application is actually refusing to load your DLL, or tried and failed. In this case I would look at the following:
- Make sure you are following whatever rules required by the third party plug-in API to get your DLL loaded. I.e. your DLL is in the right directory and whatever configuration settings are necessary are in place.
- If everything above is OK, it is possible LoadLibrary() is failing when the third party application tries to load you into memory. In this case the most likely culprit is you are linking to other DLLs from your code, and those aren't located along the path.