none
VSTO events changes the Embedded doc behavior RRS feed

  • Question

  • Hello,

    I am using VSTO 3.0 with Visual studio 2008 and Office 2010. Recently I found a very strange issue with OLE objects. I made a sample app as below:

    private void ThisAddIn_Startup(object sender, System.EventArgs e)

            {

                Application.WorkbookOpen+= new Microsoft.Office.Interop.Excel.AppEvents_WorkbookOpenEventHandler(Application_WorkbookOpen);

            }

     

            void Application_WorkbookOpen(Microsoft.Office.Interop.Excel.Workbook Wb)

            {

                Marshal.ReleaseComObject(ref Wb);

            }

    Now if I open my word doc and then Excel OLE object from within, and then if I try closing Word it does not close EXCEL automatically. As soon as I Remove the Event registration, it starts working very fine. (Strange !!!)

    The same I can reproduce with WorkbookActivate and WorkbookDeactivate event. I checked the Excel startup folder, nothing else is loaded, so I am thinking if I am doing anything different? Please suggest if anyone has got the similar issue and can help me.

    Thanks

    Mukta


    M Sharma, Deloitte, USA
    Wednesday, July 13, 2011 6:14 PM

Answers

  • Thanks for that link, I hadn't seen it before and it's definitely interesting material.

    Here's a favorite link of mine, in return :-) that explains about GC vs. ReleaseCOMObject:
    http://msdn.microsoft.com/en-us/library/aa679807(office.11).aspx

    The article you link to says:

    1. <<To avoid that, it is suggested that you avoid using delegates (either directly, or via WithEvents if in VB.NET), and instead use a direct event sink which you can connect by ComTypes.IConnectionPointContainer. To do this, you will need to implement a stub of all the events on the Application object, even if you not plan to use all those events.
    2. From inside your stub function, call Marshal.ReleaseComObject on each Workbook object passed as a parameter to the event. This will free the reference .NET adds to the object when handing the event.>>

    There are a couple of problems with this approach and what you're doing. One is that you have a VSTO add-in, and VSTO is handing you its implementation, which is a delegate. So you're not fulfilling the first requirement, nor will you be able to within a VSTO add-in.

    The second problem is that, if you kill off an object VSTO has generated and passed to the event that you're "killing" that object for VSTO, which might still require it somewhere, "under the covers". You'll understand what I mean after you've read the material written by Andrew Whitechapel.

    You'll also notice that he sort of contradicts some statements made in the article, to whit, that it IS possible to force the garbage collection, thus clearing the problem object out of memory in a deterministic manner. I have trouble imagining that the folks who wrote the blog article wouldn't know how to do this, so there may well be additional factors that aren't covered in the article.

    I have a bit more time today, so have looked up those discussions in this forum I mentioned before:
    http://social.msdn.microsoft.com/Forums/en-CA/vsto/thread/cad1f818-64b1-41fe-8114-7c39d32cdc7d
    http://social.msdn.microsoft.com/forums/en-US/vsto/thread/8174dee7-f69d-4cbe-9767-519944ab4bf4/
    http://social.msdn.microsoft.com/Forums/en/vsto/thread/74aaea5b-a14f-4b60-8683-b2c3831120e1
    http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/0854a0f0-cf7f-4837-9471-82de3fa63177
    http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/019bacf6-99a9-4361-a274-f72febbcd04e

    Perhaps the content of these can help you figure out an approach that will work for your scenario.


    Cindy Meister, VSTO/Word MVP
    Thursday, July 14, 2011 2:43 PM
    Moderator
  • Thanks Cindy. Can you please elaborate the last statement - 'Use of Marshal.ReleaseComObject'? I am using this all over my code and my understanding says that we are suppose to control the dispose of Unmanaged objects in Manged code. Though, I am doing this in the end of my event-handlers using finally block, making sure it always calls. 

    Coming back to the original post - I got a very good article saying that the behavior I am seeing is a System Limitation. Please have a look.

    http://blogs.msdn.com/b/vsofficedeveloper/archive/2008/04/11/excel-ole-embedding-errors-with-managed-addin.aspx


    M Sharma, Deloitte, USA
    • Marked as answer by M Sharma Friday, February 17, 2012 9:46 PM
    Thursday, July 14, 2011 2:13 PM
  • <<Do you know if 2010 supports Embedding with VSTO and if I am not moving into dark? >>

    There is no change in the embedding situation in newer versions of VSTO. As mentioned in some of the articles I linked to, best is if your add-in can detect when it's in an embedded situation and simply not react to any events.

    <<Next time when you will open the same word doc and try accessing the embedded object, it says Excel app not present... >>

    I've seen this, now and again (as an end-user). It usually indicates that the embedded object has been "broken".


    Cindy Meister, VSTO/Word MVP
    Thursday, July 21, 2011 11:24 AM
    Moderator

All replies

  • Add-ins running in embedded Office applications don't work the same way as when the Office application is running on its own. There are a couple of discussions in this forum - fairly old - between me and Andrew Whitechapel where Andrew goes into some detail on why this is so. Basically, add-ins running in an embedded application aren't supported. It may work, it may not, it may cause problems.

    Do you need this add-in in the embedded scenario, or is it getting in the way, so to speak.

    One thing I'd certainly try would be to comment out the Marshal.ReleaseComObject call in the code you show us. You shouldn't be using that within a VSTO add-in to release an object created by the Add-in. That will break things, internally...


    Cindy Meister, VSTO/Word MVP
    Wednesday, July 13, 2011 6:44 PM
    Moderator
  • Hello,

    Does the issue persists if you deattach the event handler in ThisAddIn_ShutDown?


    Regards from Belarus (GMT + 2),

    Andrei Smolin
    Add-in Express Team Leader
    Thursday, July 14, 2011 7:46 AM
  • Thanks Cindy. Can you please elaborate the last statement - 'Use of Marshal.ReleaseComObject'? I am using this all over my code and my understanding says that we are suppose to control the dispose of Unmanaged objects in Manged code. Though, I am doing this in the end of my event-handlers using finally block, making sure it always calls. 

    Coming back to the original post - I got a very good article saying that the behavior I am seeing is a System Limitation. Please have a look.

    http://blogs.msdn.com/b/vsofficedeveloper/archive/2008/04/11/excel-ole-embedding-errors-with-managed-addin.aspx


    M Sharma, Deloitte, USA
    • Marked as answer by M Sharma Friday, February 17, 2012 9:46 PM
    Thursday, July 14, 2011 2:13 PM
  • Yes Andrei, the issue persists even if you detach the events in ShutDown. Please have a look to the link. 

    http://blogs.msdn.com/b/vsofficedeveloper/archive/2008/04/11/excel-ole-embedding-errors-with-managed-addin.aspx

    Thanks 

     


    M Sharma, Deloitte, USA
    Thursday, July 14, 2011 2:15 PM
  • Thanks for that link, I hadn't seen it before and it's definitely interesting material.

    Here's a favorite link of mine, in return :-) that explains about GC vs. ReleaseCOMObject:
    http://msdn.microsoft.com/en-us/library/aa679807(office.11).aspx

    The article you link to says:

    1. <<To avoid that, it is suggested that you avoid using delegates (either directly, or via WithEvents if in VB.NET), and instead use a direct event sink which you can connect by ComTypes.IConnectionPointContainer. To do this, you will need to implement a stub of all the events on the Application object, even if you not plan to use all those events.
    2. From inside your stub function, call Marshal.ReleaseComObject on each Workbook object passed as a parameter to the event. This will free the reference .NET adds to the object when handing the event.>>

    There are a couple of problems with this approach and what you're doing. One is that you have a VSTO add-in, and VSTO is handing you its implementation, which is a delegate. So you're not fulfilling the first requirement, nor will you be able to within a VSTO add-in.

    The second problem is that, if you kill off an object VSTO has generated and passed to the event that you're "killing" that object for VSTO, which might still require it somewhere, "under the covers". You'll understand what I mean after you've read the material written by Andrew Whitechapel.

    You'll also notice that he sort of contradicts some statements made in the article, to whit, that it IS possible to force the garbage collection, thus clearing the problem object out of memory in a deterministic manner. I have trouble imagining that the folks who wrote the blog article wouldn't know how to do this, so there may well be additional factors that aren't covered in the article.

    I have a bit more time today, so have looked up those discussions in this forum I mentioned before:
    http://social.msdn.microsoft.com/Forums/en-CA/vsto/thread/cad1f818-64b1-41fe-8114-7c39d32cdc7d
    http://social.msdn.microsoft.com/forums/en-US/vsto/thread/8174dee7-f69d-4cbe-9767-519944ab4bf4/
    http://social.msdn.microsoft.com/Forums/en/vsto/thread/74aaea5b-a14f-4b60-8683-b2c3831120e1
    http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/0854a0f0-cf7f-4837-9471-82de3fa63177
    http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/019bacf6-99a9-4361-a274-f72febbcd04e

    Perhaps the content of these can help you figure out an approach that will work for your scenario.


    Cindy Meister, VSTO/Word MVP
    Thursday, July 14, 2011 2:43 PM
    Moderator
  • Hello Cindy, 

    After reading all these, I tried to change my code a little bit. I am still using the .NET eventing and just updated the code for COM release. I would like to share some of the findings here. 

    I see LOTS of problems with embedding feature (Excel embedded in Word). When I try to open Excel object which is embedded inside word, sometimes Excel does not return back and goes into infinite busy mode. The only way is to come out of these situation is TaskKill (Most hated !!! )

    And later on, if you still save Word. Next time when you will open the same word doc and try accessing the embedded object, it says Excel app not present... Phew !! I do not have a slightest idea why this is happening. Do you know if 2010 supports Embedding with VSTO and if I am not moving into dark? 

    One more update, Observed that making the object = null make things worse. Embedding looks better with COM release.

    Thanks for your resourceful suggestions.

    Regards

    Mukta 


    M Sharma, Deloitte, USA
    Wednesday, July 20, 2011 8:54 PM
  • Yes, releasing COM objects is what Office expects from you. I wrote an article on releasing COM objects, see When to release COM objects in Office add-ins developed in .NET.

    > Next time when you will open the same word doc and try accessing the embedded object, it says Excel app not present...

    If you do this on Vista, Windows 7 or Windows 2008 Server with UAC turned on, make sure that both the debugging session and all involved parties are run with the same integrity level. Say, if you run VS via "run as administrator", then both Word and Excel must be run via "run as administrator" as well. Probably, it would be easier if you turn UAC off. Or, you can try checking this flag in the properties of winword.exe and excel.exe.


    Regards from Belarus (GMT + 2),

    Andrei Smolin
    Add-in Express Team Leader
    Thursday, July 21, 2011 7:16 AM
  • <<Do you know if 2010 supports Embedding with VSTO and if I am not moving into dark? >>

    There is no change in the embedding situation in newer versions of VSTO. As mentioned in some of the articles I linked to, best is if your add-in can detect when it's in an embedded situation and simply not react to any events.

    <<Next time when you will open the same word doc and try accessing the embedded object, it says Excel app not present... >>

    I've seen this, now and again (as an end-user). It usually indicates that the embedded object has been "broken".


    Cindy Meister, VSTO/Word MVP
    Thursday, July 21, 2011 11:24 AM
    Moderator