none
Shared Add-in vs. VSTO Add-in: What's the difference between/how can I tell if I'm developing?

Answers

  • Hi Mike

     

    the VSTO Add-ins build on the same COM interfaces as the Shared Add-in uses, but there are differences in actual practice:

     

    1. Shared Add-ins, true to their name, can be written for more than one application (can be shared among applications). For example, you can develop and Add-in that works with Word, Excel AND Powerpoint. VSTO Add-ins are application-specific.

     

    2. Because Shared Add-ins work across applications, you need to add a lot of code to distinguish which application is currently calling your Add-in and branch accordingly. This is not necessary with a VSTO Add-in; it's taken care of for you "behind the scenes".

     

    3. A Shared Add-in has to implement five methods for connection, start-up, unconnecting and shutdown. A VSTO Add-in has only two, for startup and shutdown. The rest is taken care of behind the scenes. The developer can get right down to writing code without needing to implement the interfaces.

     

    4. VSTO provides additional programming "shortcuts" and useful objects not available in a Shared Add-in (unless the developer creates them). As VSTO Add-in for Office 2007 also takes care of implementing the Ribbon and Custom Task Pane interfaces for you, if you choose to add them to a solution.

     

    5. The two types of Add-ins must be deployed quite differently (the VSTO 2005 SE Add-in deployment usually being the more complicated of the two).

     

    These are the main reasons we need to differentiate between the two types of Add-in in forum support discussions. A code example for VSTO often won't work "as it stands" for a Shared Add-in because it will use objects and programming conventions only available in VSTO. And deployment must be discussed entirely according to the type of Add-in.

     

    OTOH, any code that strictly deals with manipulating an application's object model will probably translate fairly well. (Although, strictly speaking, such a discussion would be off-topic here in the forum.)

    Wednesday, November 07, 2007 4:10 PM
    Moderator
  •  Mike Smith-Lonergan wrote:

    Then as I understand it:

    • The core code that the developer writes may look the same, but there is a whole lot more "housekeeping" code that the developer will have to add to their core Office code to be able to share that code across Office apps.

      Correct

      • Anyone who's writing an add-in for only one Office application should have no reason to take the Shared Add-in approach, unless their version of Visual Studio doesn't support the document or application add-in template they would otherwise use.

        The only other reason to perhaps work with a Shared Add-in is the simpler deployment.

        • Any code that's been written in a VSTO-template-based project should be portable to a comparable Shared add-in project (with the addition of the rest of the wrapping code).

          Correct

          Couple of remaining questions:

          PIAs - does the Shared Add-in generate the PIAs you'd need for each target app, or does this still require that we deploy the Office PIAs?  Are there different PIAs needed for Shared vs. VSTO add-ins, or do the Office PIAs work equally well for both?

          For Office 2002 and onwards, PIAs are available from Microsoft. In 2003 and later, they're distributed with the applications and should automatically be installed if the .NET Framework is already present. The PIAs for 2002 and 2003 can also be d/l from Microsoft and distributed with your application (put into the GAC).

           

          Only Microsoft can create PIAs (PRIMARY interop assemblies); these are manually optimized. The Visual Studio tool TlbImp.exe can generate IAs from the COM type libraries, and will do so if the PIAs are not present in the GAC when you set a reference to a COM typelib. These will be created in your solution's folder hierarchy and should be distributed with your solution, in that same folder hierarchy (generally not put in the GAC). This is the only approach available for Office 2000. (But only shared Add-ins were designed to work with 2000-2002, anyway. VSTO Add-ins are for Office 2003 and later.)

           

          PIAs are a common interface, used by anything that works with a COM object model. So a WinForms application would use the PIAs, same as a Shared or VSTO Add-in.

           

          If I saw a fragment of .NET code for an Office add-in, are there any obvious "signatures" that would alert me to it being a VSTO vs. a Shared Add-in?  I now understand that the

          Depends on the fragment :-) If you see a procedure named OnConnect, for example, you'd know it's a Shared Add-in. If you'd see the term Globals at the beginning of an object definition, you could be fairly sure its VSTO.

           

          If I had the entire source code for a Shared Add-in vs. a VSTO add-in, would there be any significant differences in the total codebase (other than what you describe in your #(2))?  I get the impression from what you've said that a lot of what is "generated automatically" by the VSTO template & "hidden" by the VS IDE is code that would have to be implemented one way or another by hand by the Shared add-in developer.

          I'd say the answer would be "Yes", although I haven't done enough comparisons to be able to list any details. VSTO does things behind the scenes by default that a Shared Add-in might not need.

          Thursday, November 08, 2007 1:51 PM
          Moderator

        All replies

        • Hi Mike

           

          the VSTO Add-ins build on the same COM interfaces as the Shared Add-in uses, but there are differences in actual practice:

           

          1. Shared Add-ins, true to their name, can be written for more than one application (can be shared among applications). For example, you can develop and Add-in that works with Word, Excel AND Powerpoint. VSTO Add-ins are application-specific.

           

          2. Because Shared Add-ins work across applications, you need to add a lot of code to distinguish which application is currently calling your Add-in and branch accordingly. This is not necessary with a VSTO Add-in; it's taken care of for you "behind the scenes".

           

          3. A Shared Add-in has to implement five methods for connection, start-up, unconnecting and shutdown. A VSTO Add-in has only two, for startup and shutdown. The rest is taken care of behind the scenes. The developer can get right down to writing code without needing to implement the interfaces.

           

          4. VSTO provides additional programming "shortcuts" and useful objects not available in a Shared Add-in (unless the developer creates them). As VSTO Add-in for Office 2007 also takes care of implementing the Ribbon and Custom Task Pane interfaces for you, if you choose to add them to a solution.

           

          5. The two types of Add-ins must be deployed quite differently (the VSTO 2005 SE Add-in deployment usually being the more complicated of the two).

           

          These are the main reasons we need to differentiate between the two types of Add-in in forum support discussions. A code example for VSTO often won't work "as it stands" for a Shared Add-in because it will use objects and programming conventions only available in VSTO. And deployment must be discussed entirely according to the type of Add-in.

           

          OTOH, any code that strictly deals with manipulating an application's object model will probably translate fairly well. (Although, strictly speaking, such a discussion would be off-topic here in the forum.)

          Wednesday, November 07, 2007 4:10 PM
          Moderator
        • Cindy, thank you for such a considered and detailed response.  This definitely helps fill in many gaps in my understanding of the practical differences between VSTO and Shared add-ins.

           

          Then as I understand it:

          • The core code that the developer writes may look the same, but there is a whole lot more "housekeeping" code that the developer will have to add to their core Office code to be able to share that code across Office apps.
          • Anyone who's writing an add-in for only one Office application should have no reason to take the Shared Add-in approach, unless their version of Visual Studio doesn't support the document or application add-in template they would otherwise use.
          • Any code that's been written in a VSTO-template-based project should be portable to a comparable Shared add-in project (with the addition of the rest of the wrapping code).

          Couple of remaining questions:

          1. PIAs - does the Shared Add-in generate the PIAs you'd need for each target app, or does this still require that we deploy the Office PIAs?  Are there different PIAs needed for Shared vs. VSTO add-ins, or do the Office PIAs work equally well for both?
          2. If I saw a fragment of .NET code for an Office add-in, are there any obvious "signatures" that would alert me to it being a VSTO vs. a Shared Add-in?  I now understand that the
          3. If I had the entire source code for a Shared Add-in vs. a VSTO add-in, would there be any significant differences in the total codebase (other than what you describe in your #(2))?  I get the impression from what you've said that a lot of what is "generated automatically" by the VSTO template & "hidden" by the VS IDE is code that would have to be implemented one way or another by hand by the Shared add-in developer.
          Thursday, November 08, 2007 6:13 AM
        •  Mike Smith-Lonergan wrote:

          Then as I understand it:

          • The core code that the developer writes may look the same, but there is a whole lot more "housekeeping" code that the developer will have to add to their core Office code to be able to share that code across Office apps.

            Correct

            • Anyone who's writing an add-in for only one Office application should have no reason to take the Shared Add-in approach, unless their version of Visual Studio doesn't support the document or application add-in template they would otherwise use.

              The only other reason to perhaps work with a Shared Add-in is the simpler deployment.

              • Any code that's been written in a VSTO-template-based project should be portable to a comparable Shared add-in project (with the addition of the rest of the wrapping code).

                Correct

                Couple of remaining questions:

                PIAs - does the Shared Add-in generate the PIAs you'd need for each target app, or does this still require that we deploy the Office PIAs?  Are there different PIAs needed for Shared vs. VSTO add-ins, or do the Office PIAs work equally well for both?

                For Office 2002 and onwards, PIAs are available from Microsoft. In 2003 and later, they're distributed with the applications and should automatically be installed if the .NET Framework is already present. The PIAs for 2002 and 2003 can also be d/l from Microsoft and distributed with your application (put into the GAC).

                 

                Only Microsoft can create PIAs (PRIMARY interop assemblies); these are manually optimized. The Visual Studio tool TlbImp.exe can generate IAs from the COM type libraries, and will do so if the PIAs are not present in the GAC when you set a reference to a COM typelib. These will be created in your solution's folder hierarchy and should be distributed with your solution, in that same folder hierarchy (generally not put in the GAC). This is the only approach available for Office 2000. (But only shared Add-ins were designed to work with 2000-2002, anyway. VSTO Add-ins are for Office 2003 and later.)

                 

                PIAs are a common interface, used by anything that works with a COM object model. So a WinForms application would use the PIAs, same as a Shared or VSTO Add-in.

                 

                If I saw a fragment of .NET code for an Office add-in, are there any obvious "signatures" that would alert me to it being a VSTO vs. a Shared Add-in?  I now understand that the

                Depends on the fragment :-) If you see a procedure named OnConnect, for example, you'd know it's a Shared Add-in. If you'd see the term Globals at the beginning of an object definition, you could be fairly sure its VSTO.

                 

                If I had the entire source code for a Shared Add-in vs. a VSTO add-in, would there be any significant differences in the total codebase (other than what you describe in your #(2))?  I get the impression from what you've said that a lot of what is "generated automatically" by the VSTO template & "hidden" by the VS IDE is code that would have to be implemented one way or another by hand by the Shared add-in developer.

                I'd say the answer would be "Yes", although I haven't done enough comparisons to be able to list any details. VSTO does things behind the scenes by default that a Shared Add-in might not need.

                Thursday, November 08, 2007 1:51 PM
                Moderator
              •  

                Hi Cindy,

                Many thanks for posting such a nice response. I am new to office 2007 development and have some queries regarding office development. I am now in architecture design phase of an office application and need few clarifications to proceed further.

                 

                My query follows :

                 

                           My current application is a VBA application and supports different functionality to Word and Excel.

                I need to re-write the entire application in .net and my new application need to support both Office 2003 and 2007.

                Also while deploying my application, the installer should install my application toobar to both Word and Excel though both have different functionality.

                 

                I have started designing the new application using VSTO 2008.

                Later on I came to know about shared addins and then looked for comparision between VSTO and shared addins.

                 

                So I need suggestion from your side regarding which option should I choose for development. Shoud I opt for VSTO  2008 or shared add ins.

                 

                Also I am not able to deploy addins build by VSTO while shared addins can be deployed.

                 

                Your early response will be highly useful.

                 

                Thanks

                Girija

                 

                 

                 

                Tuesday, June 10, 2008 8:49 AM
              • Hi Grija

                 

                I think we need to clarify this statement before delving into your other questions in any detail

                 

                Also I am not able to deploy addins build by VSTO while shared addins can be deployed.

                 

                Do you mean your project design does not allow deploying VSTO or that you haven't been able to figure out how to do it?

                 

                If your project design does not allow it, then any further discussion about VSTO vs. Shared Add-ins is meaningless, it seems. If you can't figure out how to do it (or whether what you need can or cannot be done), that's another matter, entirely...

                 

                 Girija1111111111 wrote:

                           My current application is a VBA application and supports different functionality to Word and Excel.

                I need to re-write the entire application in .net and my new application need to support both Office 2003 and 2007.

                Also while deploying my application, the installer should install my application toobar to both Word and Excel though both have different functionality.

                 

                RE the toolbar: Have you considered that Office 2007 applications no longer support toolbars completely? Are you sure having your toolbar buttons in the "Add-ins" tab, possibly together with buttons from other Add-ins, is an acceptable result?

                 

                If it is not, you should consider whether you need to use RibbonXML or possibly a CustomTaskPane for the 2007 applications. In the end, this may not affect whether you use VSTO or not, but it could seriously affect the architecture of your project.

                 

                I have started designing the new application using VSTO 2008.

                Later on I came to know about shared addins and then looked for comparision between VSTO and shared addins.

                 

                So I need suggestion from your side regarding which option should I choose for development. Shoud I opt for VSTO  2008 or shared add ins.

                Tuesday, June 10, 2008 11:45 AM
                Moderator
              •  

                Hi Cindy,

                Thanks for quick response. Appologies that I could not explain the issue properly.

                 

                Regarding toolbar :

                Actually I want to create separate commandbar to contain buttons rather than having buttons with 'Add-ins' tab.

                 

                Regarding Deployment: 

                To give an demo to my client, I created a sample application using VSTO 2008/ Excel 2003.

                When I run the application (by F5) from VS IDE, I am able to see my add-in in the invoked excel application.

                 

                But when I tried to create a setup package and installed and then opened new instance of excel , then could not see my add-in in the invoked excel application.

                 

                Regarding Architecture:

                My current application is VBA based. I need to write the complete thing in .net again. And my application needs to support both Office 2003/Office 2007 depending on the version installed in client m/c. So should I go for VSTO.

                And if so, then does VSTO supports multiple versions or should I create different versions of my application for office 2003/2007?.

                 

                Regards,

                Girija

                Tuesday, June 10, 2008 1:10 PM
              • Hi Girija

                 Girija S. Behera wrote:

                Regarding toolbar :

                Actually I want to create separate commandbar to contain buttons rather than having buttons with 'Add-ins' tab.

                 

                Yes, but this is not possible in 2007. No if, ands, buts or workarounds. You cannot have a separate CommandBar in an office 2007 application that supports the Ribbon UI - which means Excel and Word. That's why I mentioned you really need to research this and make a decision about what interface you're going to use.

                 

                Regarding Deployment: 

                To give an demo to my client, I created a sample application using VSTO 2008/ Excel 2003.

                When I run the application (by F5) from VS IDE, I am able to see my add-in in the invoked excel application.

                 

                But when I tried to create a setup package and installed and then opened new instance of excel , then could not see my add-in in the invoked excel application.

                 

                Yes, deployment of VSTO 2003 Add-ins is a very complex matter. There's a lot of documentation, I recommend you work through everything you find in the message VSTO 2005 & 2003 Resource List pinned at the top of the forum. Note there are upwards of 100 pages(!) on this topic. The main issue is Visual Studio 2005 security requirements, in conjunction with Office 2003 security and registration requirements. This is one reason many developers have stayed with Shared Add-ins for pre-Office 2007 versions.

                 

                VSTO 2008 + Office 2007 is simpler because ClickOnce can be used instead of an MSI.

                 

                Regarding Architecture:

                My current application is VBA based. I need to write the complete thing in .net again. And my application needs to support both Office 2003/Office 2007 depending on the version installed in client m/c. So should I go for VSTO.

                And if so, then does VSTO supports multiple versions or should I create different versions of my application for office 2003/2007?.

                 

                Keeping in mind things can still be influenced by your decision about the UI interface for Office 2007...

                 

                A single VSTO Add-in can support multiple versions of Office (it's not necessarily recommended, but is possible). However, a VSTO Add-in cannot support multiple Office applications. You'd have to create a separate Add-in for Excel and for Word. If they share common functionality, this can be put in a separate DLL that both can use.

                 

                Coming back to the UI interface: Word and Excel 2007 could easily share the XML that defines the Ribbon, or the class defining a Custom Task Pane. (This irregardless whether VSTO or Shared Add-in).

                Tuesday, June 10, 2008 2:02 PM
                Moderator