none
Call VSTO Addin functions from external application?

    Question

  • Hi all,

    Please pardon me if this is not the right place.

    I'm looking for a way to call functions in a VSTO Addin from an external application.

    In VS2003 and Shared Addins, I used to be able to do this using this code in the external app:


    lole_object = iole_outlook.COMAddIns.Item("OutlookIntegrator.Connect").Object

    -- synchroniseAppointments() is a publically declared function in the Addin
    lole_object.synchroniseAppointments(ls_diarynoteIDs)


    However, when trying this using a VSTO addin, it did not work.  From what I can gather after some research, this seems to be just the way VSTO addins are setup.  It is an Outlook addin.

    I was wonder what other methods do you use instead to access functions in a VSTO addins now?  Is there also certain benefits/limitations I should be aware of when doing so?


    Sunday, January 29, 2006 8:41 AM

Answers

  • Calling an external program through the COMAddIns property collection is pretty straight-forward.

    One thing to keep in mind is that a COM Add-in written using our VSTO Outlook add-in framework, you will not have the "Connect" class as part of the progID as you are accustomed to with a shared add-in solution.

    For example, here is code I wrote from a .NET winform app to get info about my VSTO Outlook add-in, "OutlookAddin18", admittedly, not a very creative name

    Dim olapp As Microsoft.Office.Interop.Outlook.Application = New Microsoft.Office.Interop.Outlook.ApplicationClass()

    Dim o As Microsoft.Office.Core.COMAddIn

    Dim addins As Microsoft.Office.Core.COMAddIns

    addins = olapp.COMAddIns

    o = addins.Item("OutlookAddin18")

    This should get you going. Please read the articles we have on the Add-in tools and how they work:

    http://blogs.msdn.com/johnrdurant/archive/2005/12/07/vsto_outlook_resourcelist.aspx

    Take care,

    John.

    Monday, January 30, 2006 3:59 PM

All replies

  • Calling an external program through the COMAddIns property collection is pretty straight-forward.

    One thing to keep in mind is that a COM Add-in written using our VSTO Outlook add-in framework, you will not have the "Connect" class as part of the progID as you are accustomed to with a shared add-in solution.

    For example, here is code I wrote from a .NET winform app to get info about my VSTO Outlook add-in, "OutlookAddin18", admittedly, not a very creative name

    Dim olapp As Microsoft.Office.Interop.Outlook.Application = New Microsoft.Office.Interop.Outlook.ApplicationClass()

    Dim o As Microsoft.Office.Core.COMAddIn

    Dim addins As Microsoft.Office.Core.COMAddIns

    addins = olapp.COMAddIns

    o = addins.Item("OutlookAddin18")

    This should get you going. Please read the articles we have on the Add-in tools and how they work:

    http://blogs.msdn.com/johnrdurant/archive/2005/12/07/vsto_outlook_resourcelist.aspx

    Take care,

    John.

    Monday, January 30, 2006 3:59 PM
  • Gishmibop, there's another part to the process -- specifying what class the addin will expose when you return its Object property using the method that John showed. Jay Harlow covers this in his sample at http://www.tsbradley.net/Samples/VSTO/Xml.Export.Sample.aspx. The AutomationObject type (AutomationObject.vb) has two public properties and a public method and gets set as the Object with this statement in ThisApplication_Startup:

        Me.COMAddIns.Item(ThisApplication.ProgId).Object = New AutomationObject(Me)

    Wednesday, March 01, 2006 9:44 PM
    Moderator
  • Sue, do you have any idea why this won't work with c#?

    the c# equivalent of the line above is:

    this.COMAddins.Item(ThisApplication.ProgId).Object = new AutomationObject(this);

    I ahve set up a "ProgID" property and made an AutomationObject as defined by the sample in your response.

    When this line is run, I get an invalid cast exception.

    This code works, but obviously does nothing:

    object oTest = new object;

    this.COMAddins.Item(ThisApplication.ProgId).Object = oTest;

     

    As soon as I try to put anything other than a "native" object into this.COMAddins.Item(ThisApplication.ProgId).Object, I get the invalid cast exception.  I have tried all sorts of casts to no avail.  Do you have any ideas?

     

    Thank you very much

    Kelly Johnson

    Wednesday, March 29, 2006 8:00 AM
  • Hi John

    Would you be able to expand on your code example above?  I've created a simple Outlook Addin with a public method, which I would like to call from my winform app.  I use your code down to the o = addins.Item("OutlookAddin18") line, but not sure what to do next to get access to the public Addin methods.  Do I need to cast it somehow. Please help me.

    Thanks, Colin.

    Wednesday, March 29, 2006 10:07 AM
  • Hi Kelly

    I am also using c# and try to reproduce Jay Harlow's example.  Like you I get to the COMAddins line and receive a 'Specified cast is not valid.' error.  If you get any further with this could you please post how you did it as it would really be a great help to me and I will do the same.  Good luck...

    Colin.

    Thursday, March 30, 2006 8:50 AM
  • For a minute there i thought all my troubles were over but then I got the same cast error.

    HEEEEEEEEELLLLLLLLLLLLLLLLLLP

    Saturday, July 29, 2006 7:04 AM
  • Hi David

    Does the approach described in this thread get you any further?

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=462998&SiteID=1

    Tip: Don't post at the end of a very old thread already marked as an answer. The "answered" flag will keep a lot of people from noticing there's a new question. Instead, start your own new question and paste a link to any existing topics relating to your problem

    Saturday, July 29, 2006 12:21 PM
    Moderator
  • Hi John,

     

       I tried to write similar code for c# but it doesnot work out

    how can i call a VSTO method from other c# application

    can you please provide a sample code.

     

    Thanks & Regards

    Ajay

    Wednesday, December 06, 2006 1:58 PM
  • ..?
    Thursday, January 18, 2007 3:27 PM
  • I assume Kelly is long gone, but, for future surfers, here's an approach that sets .Object to a reasonable-looking entity without producing a cast exception:

     

    Code Block

    using Office = Microsoft.Office.Core;
     . . .
        object thisNamespace = (object) this.GetType().Namespace;
        Office.COMAddIn thisAddin = this.COMAddIns.Item(ref thisNamespace);
        thisAddin.Object = thisAddin;

     

     

    I'm sure there's a better, cleaner way and that the Namespace hack may not work for everybody (it's working for me in a very simple Outlook Add-in project.  I think that's the default for what the Outlook project puts in the registry for ProgId when you build). Any road up, the code above is what got me past the exception.

     

    Not that I've figured out how to do anything useful with this.  I can do a CreateObject('Outlook.Application') equivalent - I'm using Perl for now because it allow easy, quick interfaction - and navigate to my add-in and its Object property.  But I can't yet see any public methods.  If I get that part working I'll be back here.

     

    Wednesday, December 12, 2007 10:15 PM
  • doh!  The problem just needed a little more googling.  The (long) thread at

     

    http://www.tech-archive.net/Archive/VisualStudio/microsoft.public.vsnet.vstools.office/2006-10/msg00012.html

     

    has the answers.  I wasn't on completely the wrong track.  Highlights of the thread: make sure you've got ComVisible(true) in AssemblyInfo.cs; wrap the public functions in a separate class from the mainline of your add-in (I don't think this is strictly necessary, but it does seem reasonable designwise).

     

    There's also a discussion on where to grab the ProgId from.  I thought I might be able to grab it from the registry via the GUID.  I went looking for the GUID in the solution tree and found it in the .sln, .suo, .csproj and XXXSetup files (using Sysinternals' strings -s both Visual Studio's Find in File* and Window Explorer Search missed all these occurrences).  But I couldn't find it in the text or binary in the .dll.  And the .sln, .suo, .csproj and XXXSetup files aren't available at runtime.

     

    I'm beginning to think the only robust approach to finding the ProgId is to cycle through add-ins until one finds oneself.

     

    *to be fair, VS2005 doesn't find these when you search Entire Solution, but if you go into the Choose Search Folders dialog and specify the top level directory of the solution, the only one it misses is the .suo
    Thursday, December 13, 2007 2:31 PM
  • OK.  I've looked at it semi-carefully and come up with what I think is the clean, safe way, using no shortcuts or undocumented interfaces, to get the ProgID of the currently running add-in:

     

        for each COMAddIn in this.COMAddIns
            go to HKEY_CURRENT_USER\Software\Classes\CLSID\addin.Guid\InprocServer32
            fetch ManifestLocation and ManifestName
            open the manifest
            for each installFrom element in the dependency element
                use the codebase attribute to find the assembly or assemblies
                (optimization: start with the one whose name matches the manifest's name)
                call GetAssemblyName on each resulting filename
                stop when assemblyname.Fullname matches GetExecutingAssembly().Fullname
       go back and get ...\addin.Guid\ProgID and use it for the ProgID

     

    I'm going to use the shortcut recommended in http://www.tech-archive.net/Archive/VisualStudio/microsoft.public.vsnet.vstools.office/2006-10/msg00012.html

    Thursday, December 13, 2007 4:47 PM