none
Difference betwen "Microsoft.Office.Interop" and "Microsoft.Office.Tools"? RRS feed

  • Question

  • I have been scavenging all over the Internet, looking for usable VSTO code, for Excel development. In doing so, I have found a large degree of overlap between these two References:

    Microsoft.Office.Interop

    and

    Microsoft.Office.Tools

    Oftentimes, the ambiguity must be resolved:

    using Excel = Microsoft.Office.Interop.Excel;

    This duality is very annoying and the source of confusion, and non-working code.

    I speculate that one of the assemblies is being phased out? If so: which is the "better" (newer) one?

    TIA

    Sunday, July 20, 2014 12:42 AM

Answers

  • Hi Travis,

    The Microsoft.Office.Tools is assembe belongs Visual Studio Tools for Office Runtime.

    Microsoft.Office.Tools.Excel.dll provides interfaces that represent host items and host controls for Excel projects, and supporting types. For more information, see Automating Excel by Using Extended Objects. You can get more detail about it from link below:

    Assemblies in the Visual Studio Tools for Office Runtime

    The Microsoft.Office.Interop.Excel.dll is Microsoft Excel 2013 Primary Interop Assembly (PIA). Here is the statement for the Office PIAs:

    To use the features of a Microsoft Office application from an Office project, you must use the primary interop assembly (PIA) for the application. The PIA enables managed code to interact with a Microsoft Office application's COM-based object model.

    When you create a new Office project, Visual Studio adds references to the PIAs that are required to build the project. In some scenarios, you might need to add references to additional PIAs (for example, if you want to use a feature of Microsoft Office Word in a project for Microsoft Office Excel).


    You can get more detail about Office PIAs from link below:

    Office Primary Interop Assemblies

    Also here is the reference for the Excel PIAs:

    Welcome to the Excel 2013 Primary Interop Assembly Reference

    Bset regards

    Fei


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    • Marked as answer by Travis Banger Monday, July 21, 2014 7:12 PM
    Monday, July 21, 2014 7:24 AM
    Moderator

All replies

  • Hello Travis,

    It depends on your needs. These are two entirely different references: the first belong to Office interops and the second reference contains VSTO base classes (provides the base class for the ThisAddIn class in application-level add-ins that you create by using Visual Studio).

    Sunday, July 20, 2014 5:59 AM
  • I have noticed that in a lot of code out there some of the"using" statements can be removed.

    using Microsoft.Office.Interop.Excel
    using Microsoft.Office.Tools.Excel
    using Excel = Microsoft.Office.Interop.Excel;
    

    I have found several pieces of code in which the 2 bottom lines can be eliminated.

    It is also interesting that the Interop assembly is deployed under the Visual Studio folder while  the Tools, under the "Reference Assemblies" folder.

    Sunday, July 20, 2014 12:46 PM
  • These are different assemblies.
    Sunday, July 20, 2014 2:57 PM
  • Hi Travis,

    The Microsoft.Office.Tools is assembe belongs Visual Studio Tools for Office Runtime.

    Microsoft.Office.Tools.Excel.dll provides interfaces that represent host items and host controls for Excel projects, and supporting types. For more information, see Automating Excel by Using Extended Objects. You can get more detail about it from link below:

    Assemblies in the Visual Studio Tools for Office Runtime

    The Microsoft.Office.Interop.Excel.dll is Microsoft Excel 2013 Primary Interop Assembly (PIA). Here is the statement for the Office PIAs:

    To use the features of a Microsoft Office application from an Office project, you must use the primary interop assembly (PIA) for the application. The PIA enables managed code to interact with a Microsoft Office application's COM-based object model.

    When you create a new Office project, Visual Studio adds references to the PIAs that are required to build the project. In some scenarios, you might need to add references to additional PIAs (for example, if you want to use a feature of Microsoft Office Word in a project for Microsoft Office Excel).


    You can get more detail about Office PIAs from link below:

    Office Primary Interop Assemblies

    Also here is the reference for the Excel PIAs:

    Welcome to the Excel 2013 Primary Interop Assembly Reference

    Bset regards

    Fei


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    • Marked as answer by Travis Banger Monday, July 21, 2014 7:12 PM
    Monday, July 21, 2014 7:24 AM
    Moderator
  • Hi Travis

    Microsoft.Office.Interop.Excel is a reference to the PIAs .NET requires to work with the Office COM applications. The PIAs are generated (by Microsoft) from the native *.tlb (TypeLibrary) files that the Office applications themselves use for their own programming language (VBA). So, if you work with something from this namespace you're communicating with the "native" objects, properties, methods.

    VSTO builds on and extends the Office applications' capabilities. This capability is found in the Microsoft.Office.Tools namespace. Where you have objects/properties/methods with the same names as in the Interop namespace it means that VSTO has done something with them; often, this will be a shortcut in the number of lines of code required to do something, or added functionality, such as data-binding (which is actually a shortcut, too). The VSTO object "wraps" the native object, which can sometimes lead to the kinds of problems you've been reading about. Thus, if you don't want to use something VSTO provides, specifically, it's a good idea to work with the native object, directly.

    <<This duality is very annoying and the source of confusion, and non-working code.

    I speculate that one of the assemblies is being phased out? If so: which is the "better" (newer) one?>>

    So, no, neither namespace is being phased out - both are required in a VSTO add-in and you use the one appropriate to the task.


    Cindy Meister, VSTO/Word MVP, my blog

    Monday, July 21, 2014 2:22 PM
    Moderator
  • A very important point that should be mentioned is this: You cannot cast between an .Interop. worksheet and a .Tools. worksheet. It is done as follows:

    Microsoft.Office.Interop.Excel.Workbook nativeWorkbook = Globals.ThisAddIn.Application.ActiveWorkbook;
    if (nativeWorkbook != null)
    {
        Microsoft.Office.Tools.Excel.Workbook vstoWorkbook = Globals.Factory.GetVstoObject(nativeWorkbook);
    }

        The following code example demonstrates how to generate a host item for the active workbook


    Tuesday, July 22, 2014 3:13 AM
  • A very important point that should be mentioned is this: You cannot cast between an .Interop. worksheet and a .Tools. worksheet. It is done as follows:

    Microsoft.Office.Interop.Excel.Workbook nativeWorkbook = Globals.ThisAddIn.Application.ActiveWorkbook;
    if (nativeWorkbook != null)
    {
        Microsoft.Office.Tools.Excel.Workbook vstoWorkbook = Globals.Factory.GetVstoObject(nativeWorkbook);
    }

        The following code example demonstrates how to generate a host item for the active workbook


    Hi Travis

    The important question is: Is it necessary to do this? You only need to do this if you want to use functionality provided ONLY by the Tools. As long as what you want to manipulate is part of the Interop, stick to that.

    You also need to note, if you do use the Tools in a workbook via Add-in code, that this will not be "remembered" once the code in the add-in goes out of scope. If your add-in needs to work with this again it will be necessary for you to save all necessary information about the state somewhere (a Custom XML Part would be appropriate) so that it can be recreated the next time.


    Cindy Meister, VSTO/Word MVP, my blog

    Tuesday, July 22, 2014 3:15 PM
    Moderator