Debugging Word-addins

Debugging addins always ends up being cumbersome. The best solution when developing addins, I have found, is to be very careful to ensure that your business logic is separated from the addin itself, so that you can load that very same business logic in a test harness whenever you need to add new features, or identify and correct bugs. However, if you are stuck with an existing solution, you can generally debug your addin by starting the hosting process - Word in this case - and then attach to that process (Debug - Attach to Process). Don't worry if you see seval Word processes running - you can attach to more than one by CTRL-clicking. Then, once you are attached, just set breakpoints in your code and execute the addin functionality to start debugging.
It's not working! If you've followed the guide above and you're still not hitting any breakpoints, the code in your environment and the one deployed as your addin may not be in sync. To work around this issue, shut down Word, build your solution and copy-and-replace the addin-dlls that were deployed with your addon to the ones you have just created. Here, though, pay close attention that you are actually debugging the same code, so that you are seeing the same behaviour as your customer. If you are using Team Foundation Server, you can easilly get a previous version of your code by right-clicking a node in your Source Control Explorer, choose Get Specific Version, change Type to Changeset and click the "..."-button to precisely identify the code you want.

Good luck!

Comments

Popular posts from this blog

Auto Mapper and Record Types - will they blend?

Unit testing your Azure functions - part 2: Queues and Blobs

Testing WCF services with user credentials and binary endpoints