none
VSTO 2008 Add-in for 2003 to load on demand

    Question

  • I have a VSTO 2008 application-level assembly for Office 2003. If I implement the five methods for a Shared Add-In, could the user load / unload my assembly via the COM AddIns dialog?

     

    I ask because I would rather that the assemblies not load when Excel loads. I understand that I can write a connector (for me, it would be in VBA) that would access Application.COMAddins, but I would prefer to keep all my code in one place, ie, the VSTO solution.

     

    Thanks for your help.

    Sunday, June 01, 2008 5:52 PM

Answers

  • Hi Mercury,

     

    As far as I know, we have to use another Add-in to control over VSTO Add-ins LoadBehavior. If you want to stay away from VBA. I second your third approach. And as Cindy said, Office 2003 Add-in in HKLM will not appear in COM Add-in dialog, so you can register your VSTO Add-in in HKLM and the loader Shared Add-in in HKCU. Then, the loader Add-in will be loaded and connected in COM Add-in Dialog while VSTO Add-ins cannot be accessed there. I have a quick test on my end. It works as required.

    I have to mention a problem I can see in this approach. If users are running your solution in Vista or Windows Server 2008 and UAC is turned on. All modification to HKLM needs Administrator right. It means that users must run Office Application via right clicking the application and click Run As Administrator. Otherwise, it will throw an error that says "HKLM COMAddIn.Connect cannot be changed".

     

     

    Thanks,

    Ji

     

    Friday, June 06, 2008 9:05 AM

All replies

  • Hi Mercury

     

    See this message thread for a discussion about how to change the load behavior (you have to change a Registry setting in your setup program).

     

    You do not want to implement any methods from the Shared Add-in: VSTO is already doing that behind the scenes, and you must leave that alone.

    Monday, June 02, 2008 7:24 AM
  • Hi, Cindy. I'm looking for something a little bit different. I've already changed the load behavior of the add-in. My question now is the the "on demand" part of "load on demand".

     

    My users generally use Tools->Add-Ins in their Office apps to close and open the XLAs they are interested in at the moment. Most of my apps generate a custom menu, so this cuts down on visual clutter.

     

    I am trying to find the lowest effort way to give them the same sort of experience with a VSTO add-in. I understand that I could write a "VBA Loader" add-in that would appear in the add-ins menu, and then that would connect to my real add-in via the COMAddIn interface my assembly exposes. Ex: COMAddIn("MyCOMVisibleName").Connect = True. I would prefer not to do this because I'm trying to stay away from VBA code, and it requires maintaining code in two separate places.

     

    It seems to me that if I could get something to be available in the COM Add-Ins dialog, that that would be the closest thing to what my users already experience. So I am asking if it is practical / possible to make my add-in loadable from that dialog, which I believe means my add-in would need to implement the Extensibility.IDTExtensibility2 interface (though from what you are saying above, perhaps it already does).

     

    If I can't include this class in my VSTO project, can I put a VSTO project and a .NET Add-in project together in the same solution, and use the .NET Add-In as my loader app?

     

    Thanks again.

    Monday, June 02, 2008 5:18 PM
  • Hi Mercury

     Mercury Schroeppel wrote:

    I'm looking for something a little bit different. I've already changed the load behavior of the add-in. My question now is the the "on demand" part of "load on demand".

     

    My users generally use Tools->Add-Ins in their Office apps to close and open the XLAs they are interested in at the moment. Most of my apps generate a custom menu, so this cuts down on visual clutter.

     

    I am trying to find the lowest effort way to give them the same sort of experience with a VSTO add-in. I understand that I could write a "VBA Loader" add-in that would appear in the add-ins menu, and then that would connect to my real add-in via the COMAddIn interface my assembly exposes. Ex: COMAddIn("MyCOMVisibleName").Connect = True. I would prefer not to do this because I'm trying to stay away from VBA code, and it requires maintaining code in two separate places.

     

    It seems to me that if I could get something to be available in the COM Add-Ins dialog, that that would be the closest thing to what my users already experience. So I am asking if it is practical / possible to make my add-in loadable from that dialog, which I believe means my add-in would need to implement the Extensibility.IDTExtensibility2 interface (though from what you are saying above, perhaps it already does).

     

    If I can't include this class in my VSTO project, can I put a VSTO project and a .NET Add-in project together in the same solution, and use the .NET Add-In as my loader app?

     

    Mmmm. I always see VSTO Add-ins (not document-level customizations) in the Tools/COM Add-ins dialog box if they're regsitered in HKCU. Add-ins registered in HKLM can't show in this dialog box. Does that help at all?
    Tuesday, June 03, 2008 5:46 AM
  • Hm, maybe a little bit. Smile

     

    Let me try and give a little bit more background. I am traditionally a VBA developer. I am used to providing users with XLAs physically located on a network drive. This makes for easy updates and easy delivery - users can browse to the network location, and choose to load it. Once it's loaded, it remains accessible via the Tools->Add-ins dialog. Users can access the code by actually clicking the Add-In, which OPENS it, which is what drives my menus' appearance. When users are not interested in a given application, they unclick (close) the app (though in VBA parlance, it remains loaded, since it is visible in the Add-Ins dilaog).

     

    I am switching over to VSTO, whose default behavior is to load on Excel startup (I only do Excel add-ins, so I'll ignore others for now). At some point this will not work for me because if I give a user five separate VSTO add-ins, they are stuck with extra menus when they open Excel. I would like to provide them with an experience similar to what they have now.

     

    I believe I understand how to prevent my add-ins from loading automatically with the Registry value "LoadBehavior". So here I am, happy that my menu didn't automatically appear on startup. But wait - how are my users going to get access to my non-loaded add-in? Before, this was controlled by the nice little Add-Ins dialog. Here's where I think I need to get creative. You are correct that my VSTO add-in appears in the COM Addins dialog. However, if users try to select it, they get an error message along the lines of "<your vsto addin> is not a valid COM add-in". Based on my reading, it appeared to me that .NET Office Add-Ins CAN be loaded via this dialog because they implement the five methods of IExtensibility2.

     

    Bottom line, what is the simplest way for my users to choose to load my VSTO add-in? I have come up with three options so far:

     

    1) Write an XLA that simply acts as a loader. It appears in the Add-ins dialog. When the user loads/opens it, it in turn connects my VSTO add-in via my VSTO add-in's ComAddin interface. I'm confident I can do this. However, I would like to stay away from VBA if possible, and if I do need to build a specific loader, I'd like to be able to keep all the code in the same .NET solution.

     

    2) Modify my VSTO add-in to implement the IExtensibility2 interface, so not only is it VISIBLE from the COM AddIns dialog, user can CONNECT to it from there. From what I understand so far, you don't think this will work.

     

    3) Add a .NET Add-in for Office to my VSTO add-in solution to act as a loader. This is similar to option 1, except that this .NET Add-In would be connected / loaded in the COM Add-Ins dialog. If we go this route, I would prefer that my VSTO app not show up in the COM Add-Ins dialog at all - I would just want the loader to show, so it's clear to the user what to choose. The .NET Add-In would perform exactly the same function for my VSTO add-in as the VBA loader would in point 1.

     

    Hopefully that clarifies my interest. It sounds complicated, but I'm a little surprised I haven't seen more discussion about this in the forums, given the change in user experience.

     

    Any insight you can provide would be greatly appreciated. Thanks for still paying attention!

    Tuesday, June 03, 2008 6:57 AM
  • Hi Mercury,

     

    As far as I know, we have to use another Add-in to control over VSTO Add-ins LoadBehavior. If you want to stay away from VBA. I second your third approach. And as Cindy said, Office 2003 Add-in in HKLM will not appear in COM Add-in dialog, so you can register your VSTO Add-in in HKLM and the loader Shared Add-in in HKCU. Then, the loader Add-in will be loaded and connected in COM Add-in Dialog while VSTO Add-ins cannot be accessed there. I have a quick test on my end. It works as required.

    I have to mention a problem I can see in this approach. If users are running your solution in Vista or Windows Server 2008 and UAC is turned on. All modification to HKLM needs Administrator right. It means that users must run Office Application via right clicking the application and click Run As Administrator. Otherwise, it will throw an error that says "HKLM COMAddIn.Connect cannot be changed".

     

     

    Thanks,

    Ji

     

    Friday, June 06, 2008 9:05 AM