In one of my previous posts, I reviewed Add-in Express for Office and .NET. Add-in Express is a great alternative to Visual Studio Tools for Office (VSTO) that enables you to create version-neutral desktop add-ins for Microsoft Office.
You can also create single-codebase solutions, such as one add-in that runs in Excel and Word. This approach can significantly reduce the time and cost needed to bring a product to market, but it’s not always appropriate.
This is not meant to be a long post, since build configurations are fairly straightforward. However, if you don’t know about build configurations, keep reading.
A simple Hello, World project!
Since Add-in Express already provides a lot of functionality out of the box, let’s start by setting up a sample project.
For the requirements, I want the add-in to run inside Word, Excel, PowerPoint, Visio, Project and Publisher. This is probably more than what most of us will ever need, but this is just a quick demo to see how it works.
So the first thing I do after creating a new Add-in Express COM add-in project is create the user interface. I start by adding a new ribbon tab, and the associated
HappyFace button. Happy days! I then specify which Office app I want the ribbon to load in, and then proceed to compile and register the add-in. I run it, just to make sure everything is in the right place.
When you first run the add-in, it typically loads with Excel. This can be a problem if you need to be able to switch to Word or PowerPoint to test it out. Recall we’re building a single-codebase solution that can run in any number of Office clients, such as Word, PowerPoint or Excel.
If you want to change the target to a different Office app, such as PowerPoint, you go to
Start external program and specify it there. Happy days!
However, changing this setting manually every single time is also quite tedious.
Using Build Configurations
To speed up the debugging of your add-in when switching from Excel to Word or PowerPoint, I like to use build configurations.
In case you’re not familiar with the concept, a build configuration is that little dropdown you use to switch from Debug to Release. Using build configurations is going to help you streamline the process of running and debugging the add-in, especially when switching between many hosts.
Here’s how I configured my build configurations for this scenario:
There you have it. We’ve added custom build configs to our Visual Studio project, so now we can run and debug faster. It’s far from perfect, but it’s a first step.
Build configs in Visual Studio are very simple and powerful. They enable you to quickly switch from one configuration to another, which is useful when you want to test your Office add-in on different hosts or in complex configurations.
Have you found a better or more efficient way of using build configuration to accelerate your Office add-ins development? Share your thoughts in the comments!