Running multiple versions of the same Excel VSTO add-in simultaneously

Question

We have an internal tool that allows users to configure and launch their Excel sessions. For example, they can choose specific versions of our Excel add-ins, different environment variables etc. Some users even start two different Excel sessions simultaneously that use different add-ins versions.

We want to allow users to select different versions of our Excel VSTO add-in. Right now the tool executes a batch script that sets the appropriate registry entries prior running Excel. Ideally, they should be able to run different versions simultaneously. Is that possible?

One option would be to publish different versions of the VSTO add-in with distinct names and then select the right version to be loaded programmatically when Excel starts. I'm not sure how to achieve that, however it isn't ideal because all of the versions would appear in the list of COM Add-Ins in Excel.

I'm thinking about customising the script that creates the VSTO registry entries to change the entry prior running excel. So we'll have only one entry for our VSTO add-in, and we'll be changing it's location property to point to different versions of the add-in. Would that work and do you see any potential issues when two Excel instances are started with different locations for the same VSTO plugin?

Did you find a solution to your Problem? We have basically the same problem. — Gener4tor, Jun 27 '19 at 09:13
That sounds completely backwards - why not instead give your user a way to configure how your addin works so they can explicitly chose how they want your addin to perform? Nothign prevents your addin from performing its work based on some user configurable values. — Dmitry Streblechenko, Dec 01 '21 at 03:12

aliceraunsbaek · Answer 1 · 2021-12-01T11:16:49.673

I think I found a 'fix' for this. Not particularly pretty, but it works so far.

My issue is that we would like to be able to have a VSTO installed, AND develop on it (running it from VS) on the same PC without uninstalling it all the time.

When I change the assembly name, so that it is different from when it is deployed I get no conflict. To help not fudge it up I added a pre-build event:

if $(ConfigurationName) == Release ( if '$(ProjectName)' == '$(TargetName)' ( exit 0 ) else (
 echo "Assembly name must be same as project name in RELEASE"
 exit 21) )
if $(ConfigurationName) == Debug ( if '$(ProjectName)' == '$(TargetName)' (
 echo "Assembly name must be different from project name in DEBUG"
 exit 20 ) )

Seeing as it is built in Release when deployed, and we run it in Debug locally.

I had to change the ControlIdType of the RibbonTab to Custom.

I also wanted to make it clear which version the user/developer/I was interacting with, so in the ribbon I have added a function:

    private void PostInitialize()
    {
    #if DEBUG
        tabRdTools.Label += " DEVELOPMENT";
        tabRdTools.Name += "Dev";
    #endif
    }

In the ...Designer.cs file I have added the call to PostInitialize:

    public RDToolsRibbon()
        : base(Globals.Factory.GetRibbonFactory())
    {
        InitializeComponent();
        PostInitialize();
    }

Basically the idea is that the developer adds ".dev" to the assembly name when developing (in Debug mode).

This will cause the ribbon to be post-fixed with " DEVELOPMENT", causing no interference with the installed VSTO.

Draw backs: you have to manually change the assembly name. If you change the assembly name to different things every time, you may end up with a lot of echos.

Running multiple versions of the same Excel VSTO add-in simultaneously

1 Answers1