Mathias Brandewinder on .NET, F#, VSTO and Excel development, and quantitative analysis / machine learning.
by Mathias 15. July 2010 12:14

Time to wrap this series on VSTO add-ins for Excel 2007. Now that we have a working application-level add-in, we want to deploy it on the user machine. There are two ways to do that: ClickOnce and Windows Installer. In this post, I will go over creating a basic installer using Windows installer with Visual Studio 2008. Very soon, we’ll have a VIP guest blogger who will tell you all you need to know about ClickOnce deployment and VSTO.

This post borrows heavily from the Microsoft white paper linked below, which is absolutely excellent. I mostly paraphrased it, focusing on the how and not the why. I strongly encourage you to go to the source and read it for more details:

Deploying a VSTO 3.0 Solution for Office 2007 System Using Windows Installer

The white paper comes with sample code, covering a few scenarios:

VSTO installer sample code 

Note: the following applies to Office 2007 projects. If your add-in needs to run on Excel 2003, you should follow this guidance instead: Deploying VSTO Solutions Using Windows Installer (Part 2 of 2)

Surgeon General Warning: prolonged reading of material pertaining to msi deployment can cause drowsiness or confusion; absolutely no risk whatsoever of euphoria is to be expected.

This post is not going to be sexy. My goal is to have a check-list of what to do to get your add-in to install correctly. The steps require no thinking, and are frankly rather boring. I find some steps pretty obscure, and recommend patience and soothing music; you may consider also having  some sacrificial offering ready to appease the Great Installer Voodoo deity (a nice chicken will usually do). 

Prepare the add-in

We will start from where we left off, with a working add-in (download the add-in here). Let’s first fill in the fields describing our assembly, by right-clicking on the project:

ClearLines.Anakin > Properties > Application > Assembly information:


Next, let’s set the configuration to Release, so that we feed the optimized release version to the installer. Right-click on the Solution (not the add-in project), select Configuration Manager, and set ClearLines.Anakin to Release instead of Debug.



by Mathias 12. October 2009 10:54

I just found a solution to an issue which has been bothering me for a while. The reference article by Microsoft which describes how to deploy a Visual Studio 2005 Tools for Office solution using Windows Installer (a life-saver) doesn’t say anything about how to grant trust to multiple assemblies. This is a problem if you want to use satellite dlls in your add-in.

I figured out a workaround a while back, but I wasn’t convinced this was a good solution. Today, I came across this thread, where the second post (by Lex007) describes a simple way to do that, by modifying the SetSecurity project. Instead of passing only one dll, the tweak allows to pass a comma-separated list of dlls. I just tried it out, and it works like a charm.

by Mathias 9. August 2009 17:25

The first of Scott Hanselman’s “Top 10 Tips Working Developers Should Know about Windows 7” really made my day: Win 7 includes .NET 3.5 SP1. This probably doesn’t matter to you if you are not a .NET developer, but if you are, chances are you have had the same frustration as I did. .NET 3.5 SP1 is really what you want to be developing against, because it includes so much goodness, but in my experience, most users don’t have it on their machines. As a result, your potential user has to go through a good 15 minutes of download and a reboot – and that’s assuming the IT department is fine with that, which is not a given (personal experience).

This is of particular importance to me, because my pet project Akin, a free application that helps track down differences between Excel files, is written against .NET 3.5. I really needed WPF to create the kind of user interface I wanted, but this has proven a hurdle in getting people to try it out. You might be able to convince people you know personally that they should install .NET 3.5, but for the casual visitor who stumbles across a webpage and wants to just try out an application, asking them to download a giant file for unclear purposes first is just a killer. You lost one potential user, right there.

With Windows 7 pre-sales making a solid start, hopefully I will be relieved of that issue. This is very motivating – time to get back to it, and implement some of the great suggestions I received so far!

by Mathias 8. June 2009 08:53

No matter how much you think you have your bases covered, users will do unexpected things with your application. Writing good unit tests: priceless. For everything else, there is logging. So I decided to add exception logging to Akin, and opted for NLog.

NLog rocks. It is very easy to configure: basically, add the NLog dll to your project, a configuration file defining what you want to log, and where it should go, and you are set. My configuration file looks something like that:

<?xml version="1.0" ?>
<nlog xmlns=""
    <target name="file" xsi:type="File"
        layout="${longdate} ${stacktrace} ${message} ${exception:format=message,type,method,stacktrace}"
        concurrentWrites="true" />
    <logger name="*" minlevel="Trace" writeTo="file" />
Which I use then to log exceptions this way:
    // try to open a file
catch(Exception e)
    logger.TraceException(string.Format("Failed to open {0}.", path), e);

The exception gets appended to a file like 2009-06-08.log, in the logs folder located in the application folder, in that case, C:\Program Files\Akin; if the file or folder do not exist, it gets automatically created. This worked like a charm, once I realized I also needed to add the config file to the installer.

And then I deployed on a Vista machine. Everything looked fine (I checked that logging to a message box worked), except that… there was no log file to be found. Damn.

After much anxiety and help of StackOverflow, I found my logs. Turns out, there was a log file, but not where I expected it to be. Vista uses File System Virtualization, and writes the log to another location – in my case,

C:/Users/JohnDoe/AppData/Local/VirtualStore/Program Files (x86)/Akin/Logs/

So if you can’t find your log files, no worries. It’s just Vista playing hide-and-seek with you…

by Mathias 26. October 2008 04:40

Last Friday, I had a meeting to present a VSTO Excel add-in to a client - and I got an unpleasant surprise: not only did the client not have .NET 3.5 installed on his laptop, but the IT department was not willing to install it, as they had not evaluated it. Rather than trying to convince them that 3.5 was innocuous, I thought, let's try to change the project target from .NET 3.5 to .NET 2.0. After removing all dependencies, I rebuild, do an install on a clean, 2.0-only virtual machine, and... it fails miserably, with the message "This setup requires the .NET Framework 3.5". Not good.

When I had nearly given up figuring out what reference I had forgotten (and was bracing myself for a lengthy discussion with IT), XL-Dennis came to the rescue with this post, via the Excel User Group. Thank you a million. It turns out that when you change the Target Framework from 3.5 to 2.0, most things get updated, except... the launch condition that checks the presence of the .NET Framework on the target machine, which stays stuck on 3.5. Once you manually change it to 2.0, everything works fine.


Comment RSS