Yesterday while writing code for the next article about creating add-ins for the VBA editor of Office using Visual Studio .NET I noticed that when I used this approach to debug it, the add-in project was not being rebuilt when I changed some code and hit F5 to debug:
- In the Solution Explorer of the Visual Studio project, right-click the solution
node and click the “Add”, “Existing Project…” menu entry.
- Select the path to Excel.exe, for example “C:\Program
- Right-click the EXCEL.EXE node and click the “Set as Startup Project” menu
- Right-click the EXCEL.EXE node and click the Properties menu entry.
- In the Debugger Type field, change its value from “Auto” to “Managed (v2.0)”.
- Click the “Debug”, “Start Debugging” menu.
- Excel will be launched.
- Open the VBA editor and load the add-in. The breakpoint should be hit in the
I remembered that the same happened to me some months ago with the solution of my add-in MZ-Tools 6.0, that contained the main add-in project and other projects for external operations of the MZ-Tools 6.0 SDK: the projects of the external operations were not rebuilt when I debugged the main add-in project.
The reason is that by default, the setting “Only build startup projects and dependencies on Run” that is in the “Tools, “Options…” window, “Projects and Solutions”, “Build and Run” section is checked. Once you uncheck it, the issue is solved.
I have updated the article that I wrote a couple of days ago to reflect this:
HOWTO: Debug an add-in for the VBA editor (32-bit or 64-bit) of Office with Visual Studio .NET.