none
How can I have one AddIn for all versions of Office? RRS feed

  • Question

  • Hi all;

    At present we have a shim and addin for each version of Office (2002 - 2010). Same source code but we have #if's in the code that determine what code is called by version.

    However, we have customers that have multiple versions of Office installed. This is a giant problem when they have 2002/2003 and 2007/2010 because one uses menus and the other the ribbon.

    Thought number one was to have a single shim that called the correct AddIn. However, the shim has no way to find the version of Office that called it prior to loading the AddIn.

    Would it be ok to have a single AddIn that we build against the 2010 PIAs? And then use "if (Version >= 12)" in the code to determine what code to execute? My worries are:

    1. That the PIA API has changed (not been added to but changed) and therefore some calls to Office will fail.
    2. That the AddIn won't load if references used in the AddIn don't exist in the PIAs (like IRibbon not existing in 2002/2003).

    What is the best way to have an AddIn that works correctly with all versions of Office?

    thanks - dave

    ps - Our AddIn is IExtensibility, not VSTO.


    The Programming Olympics - Code Wars
    • Edited by DavidThi808 Friday, January 6, 2012 8:07 PM
    Friday, January 6, 2012 8:04 PM

All replies

  • Hi David,

    In our practice, a typical Add-in Express based add-in (it implements IDTExtensibility2, too) is a single codebase which uses a single interop to work with several Office versions; we suggest using an interop for the oldest Office version that you need to support. You use "if (Version >= 12)" and late binding (=Type.InvokeMember()) to access features introduced in versions which are "newer" than the interop.

    > That the PIA API has changed (not been added to but changed) and therefore some calls to Office will fail.

    There are calls that changed, I've won one of them here (now I try to solve the localization issue).

    I don't understand what you told about your shim. In my understanding a shim is an unmanaged dll that implements IDTExtensibility2 and other required interfaces. When Office loads it, the shim can check everything e.g. Application.Version; then the shim creates an AppDomain and loads your assembly to the AppDomain.

    On multiple Office versions.

    Scenario #1. You unregister your add-in on a PC with Word 2003 and Word 2007 installed. To remove custom command bars saved in normal.dot, you run Word via Automation and instead of Word 2003, Word 2007 is run. This ends with command bars hanging in Word 2003.

    Scenario #2. Two Word versions are installed in a wrong order and this prevents your add-in from functioning. Wouldn't be surprised if reparing Word 2003 requires repairing also Word 2007 (again, for your add-in only). Then updating existing Office installation to add an Office feature or even an Office application, service packs etc. Note that end-user related stuff will work perfectly in these situations but your add-in will fail.

    I think there're no solutions for these problems.


    Regards from Belarus (GMT + 3),

    Andrei Smolin
    Add-in Express Team Leader
    Friday, January 6, 2012 9:22 PM
  • Hi Andrei/David

    Shouldn't this "if (Version >= 12)"  be "if (Version <= 12)" ? (Just for the case if others read the discussion who aren't aware of how we do version checking :-))

    And FWIW I agree with Andrei's assessment of the problem. About the only thing that I can imagine is:

    Have two add-ins, a "manager" and the actual add-in. Only the "manager" loads on-demand. It checks the version then loads the required "real" add-in.


    Cindy Meister, VSTO/Word MVP
    Saturday, January 7, 2012 7:57 AM
    Moderator
  • Cindy,

    For me, writing "if (Version >= 12)" in an add-in means (in most cases) that the add-in uses an interop for Office 2000, 2002 or 2003. On the negative side: you need to use late binding. To minimize the volume of late binding code, you use an interop for the oldest Office version you need to support. On the positive side: 1) you can develop the add-in on a machine with a newest Office version installed; 2) you get a compile-time error if your code uses a class or class member introduced in a newer Office version.

    Writing "if (Version <= 12)" means the add-in uses an interop for Office 2007 or 2010. On the positive side: you use only early binding. On the negative side: 1) you need to know in which Office version every given class and/or its member exists (or does not exist); 2) you get a run-time error if you use a class or class member missing in a given Office version when that Office version loads your add-in.


    Regards from Belarus (GMT + 3),

    Andrei Smolin
    Add-in Express Team Leader
    Saturday, January 7, 2012 4:07 PM
  • Hi Andrei;

    When Office loads it, the shim can check everything e.g. Application.Version; then the shim creates an AppDomain and loads your assembly to the AppDomain.

    That's the problem I'm facing - how can I cann Application.Version in the shim? If there's a way to do that, then this all becomes very easy.

    thanks - dave


    The Programming Olympics - Code Wars
    Sunday, January 8, 2012 10:11 PM
  • Hi Andrei

    Right. For some reason my brain was thinking "2012" (the year), not the internal version number. Senior moment! Thanks for taking the time to type all that out - I'm sure it will help others who read this thread.


    Cindy Meister, VSTO/Word MVP
    Monday, January 9, 2012 6:55 AM
    Moderator
  • Hi Dave,

    A shim is an unmanaged COM add-in, i.e. it implements IDTExtensibility2. When Office loads it, the Application object is supplied in the OnConnection method.  


    Regards from Belarus (GMT + 3),

    Andrei Smolin
    Add-in Express Team Leader
    Monday, January 9, 2012 8:05 AM
  • Hi Andrei;

    I think we're going to have to restructure the AddIn code because it creates the app domain and loads up the .net AddIn before the OnConnection() method is called. But there should be no reason it can't wait till that point.

    thanks - dave


    The Programming Olympics - Code Wars
    Monday, January 9, 2012 4:29 PM
  • Hi Dave,

    Exactly. Good luck! See you :)


    Regards from Belarus (GMT + 3),

    Andrei Smolin
    Add-in Express Team Leader
    Tuesday, January 10, 2012 9:06 AM