Some time ago I published a blog post about an add-in that I’m building, and the reasons why I elected to start using Add-In Express to manage the process. I still think Add-In Express is the best product for this kind of task, but figured I’d publish this post mainly to save me time the next time I get a new PC and have to go through this again.
The issue I ran into is that I need to set the CLR to work with .NET 3.5. To do this you have to set the host file to v2.0x. This is pretty easy, and Eugene has a good picture on how to do this here: http://www.add-in-express.com/forum/read.php?FID=5&TID=7912
Following the steps that Eugene provided set me off to the races… with Excel 2010. But when I tried to debug in Excel 2013 I wasn’t having much luck. I changed the “Program to Start” to Excel 2013, set a breakpoint in my code, and started debugging. Even though I’d set a breakpoint in my code, it was never activated. Instead, the breakpoint goes from a red dot to a red circle with a white fill, and mouse-ing over it yields the message “The breakpoint will not currently be hit. No symbols have been loaded for this document.”
This really sucks, as it’s pretty tough to work with. So what’s different, and how come Excel 2010 works, but Excel 2013 doesn’t?
The action of modifying that host config file as described by Eugene actually creates a new file that is stored within the appropriate Office subfolder held within the Program Files folder. Unfortunately, the program that is defined in your “Program to Start” settings seems to be ignored, and it actually creates the file in the folder that holds the oldest version of Office on your system. So in my case it created the following file:
- C:\Program Files\Microsoft Office\Office14\excel.exe.config
Now, I stand to be corrected on this, but I believe that this file is only used when launching the debugging tools from Visual Studio. When the app is started it will look for this file and, if it finds it will use it to provides the debugging symbols back to Visual Studio for the .NET framework specified.
At any rate, the key here is to copy this file and paste it into the same folder that contains the exe file specified in the “Program to Start” area in the Project Properties of Visual Studio. And once you do that:
Beautiful! Works nicely.
It’s also worth mentioning that this setup works whether you are using a version of Office that comes from an MSI installer file (such as a DVD or volume license version of Excel/Office), or if you are using the Click to Run (C2R) version of Office that you can download from Office365. The only thing you need to be concerned about is the file path in which to store the config file and find the Excel.exe executable:
- 64bit MSI: C:\Program Files\Microsoft Office\Office15
- 32bit MSI: C:\Program Files (x86)\Microsoft Office\Office15
- 64bit C2R: C:\Program Files\Microsoft Office 15\root\office15
- 32bit C2R: C:\Program Files (x86)\Microsoft Office 15\root\office15
I know this isn’t super Excel focussed, but hopefully it will help someone out there if they run into this error.
I should also throw a shout out to Andrei from Add-In Express who helped me sort this out last time I needed to figure this out. The support there was awesome in helping me get it resolved.
