none
OLE not releasing document when VSTO-Addin is loaded RRS feed

  • Question

  • Hi

    I have developed a VSTO-Addin for Word 2007 using Visual Studio 2008 in Visual Basic.

    There is no problem with the VSTO-Addin itself, rather than in co-operation with OLE-opened documents.

    One of my clients systems is using an OLE-container to show document-text in a Windows form.
    They have developed this application using Delphi, but I have managed to replicate the behaviour using a very simple VB6 windows form application.

    This is the scenario:

    In the VB6 applications form, a standard OLE-control (OLE1) is used. With that control I code as follows:

     OLE1.AutoActivate = 0
     OLE1.AutoVerbMenu = False
     OLE1.CreateEmbed (<string with path to a rtf-formatted .DOC-file>)
     
    

    If I run the code above and my VSTO-Addin isn't loaded, I can see av WINWORD.EXE process starting AND closing.
    The text from the document file is then shown in the VB6 form, as requested.

    If I activate my VSTO-Addin the WINWORD.EXE process is not terminated.
    After some research I find that 1 document actually is closed, but it is "Document without name"???, and not the documentfile I opened from the VB6 form.

    If you later on open a document the "ordinary way", the preciously OLE-opened document is also shown, which is not desired.

    I have tried to comment code in all Application events without any change in behaviour.

    What can be done to prevent this "not-closing-document" from happening?

    Thanks in advance


    Best Regards Peter Karlström Midrange AB, Sweden
    Tuesday, March 8, 2011 12:23 PM

Answers

  • Hello Peter,

    Thanks for the report on your tests. Several years ago another customer reported the same problem (not the message, but the problem dismissing WinWord. ) The message results from the Add-in registering as "WordAddIn.ThisAddin" as not a _ComObject. The basic problem was reported as a bug with the description "Word 12\Programmability: VSTO 3.0: Word 2007 hangs after inserting file using "Insert Object" and if Word Addin registered to an application event (E.g: DocumentbeforeClose)" This differs from your code by the E.g being DocumentOpen rather than the DocumentBeforeClose.

    The root cause is explained in the blog at the following address: http://blogs.msdn.com/vsofficedeveloper/pages/excel-ole-embedding-errors-with-managed-addin.aspx
    In that article it talks about why this behavior occurs. It’s because of design conflict between OLE (which expects deterministic reference count) and .NET (which uses non-deterministic GC).

    I tested using Word 2007 and VSTO 3 on a Windows 7 system, and did not get the error message about WordAddIn .ThisAddin (i.e. sender) not being a Com object. That difference could stem from one or all of the differences between that system and yours The primary one being Windows 7 versus Windows XP. Is you test machine Windows XP. If not that or Windows Vista, but Windows 7, then one or more of the other differences may be the source of that message. The system I use for test has
    Microsoft .NET Compact Framework 2.0 SP2 build 2.0.7045
    Microsoft .NET Compact Framework 3.5 build 3.5.7283
    Microsoft .NET Framework 4 Client Profile build 4.0.30319
    Microsoft Enterprise 2007 build 12.0.6425.1000
    Microsoft Visual Studio 2008 Professional Edition - ENU
    Visual Studio Tools for Office Second Edition Runtime
    Visual Studio Tools for Office System 3.0 Runtime

    The solution for the other customr's problem is to not use event handler delegate for the Word events, but instead replace them with late-binding IConnectionPoint event handlers. There is a knowledge base article that describes doing this for PowerPoint events. The approach described there works well with WinWord events.  The KB article is
    308330 How to handle PowerPoint 2002 events by using Visual Basic .NET 2002
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;308330
    You need to include a 'stub' Method as the event handler for every WinWord 2007 event. This will be a method with a call to inside your stub function, call Marshal.ReleaseComObject on each document object passed as a parameter to the event. This will free the reference .NET adds to the object when handing the event.  Where you need application code you place it in the event stub and at the end call Marshall.ReleaseComObject for the document object.

    Please let us know if you have questions about the information above, and the results from using it.
    Regards

    Wednesday, March 30, 2011 5:43 PM
    Moderator

All replies

  • Hello Peter ,
     
    Thank you for your question. I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience. Thank you for your understanding and support.

    Have a nice day.


    Bessie Zhao [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, March 9, 2011 8:15 AM
  • Hello Peter,

    Is your VSTO Add-in a DocumentLevel add-in, and if so, in your VB application how do you load the Add-in?

    If the Add-in is an Application level Add-in for Word, what does the Add-in do about generating Word documents?

    Wednesday, March 9, 2011 7:37 PM
    Moderator
  • Hi cjatms?

    Addin is an application level add-in and loads automatically whenever Word i started.

    I can't really understand your question: What does the Add-in do about generating Word documents?

    Even if I comment out all code from Words document events (Document_Open, NewDocument and DocumentBeforeClose), the problem persists.

     


    Best Regards Peter Karlström Midrange AB, Sweden
    Thursday, March 10, 2011 11:48 AM
  • Hello Peter,

    Following your description in the original post, I repeated the process.  My WinWord program loads with 3 VSTO Add-ins and 2 COM Add-ins. When I run the VB code I see WinWord start, see the document load, and see WinWord disappear.  The document is a .rtf document, not a .doc file that contains RTF text. (When I create a new word document, enter some text, save it as a file-type 'Rich Text .rtf" then say the name of the file is MyDoc.doc it is now re-named MyDoc.doc.rtf.)

    Perhaps the different results between those of my test and those of yours is because of that difference in file format. Please tell me how to build a .doc file containing rtf text, then show only that rtf text in the OLE control.

    Other than that difference the only other difference has to be in the Add-in. You commented that you didn't understand my question in my first reply. It comes from seeing other examples of Add-ins where the code spawns more documents. If your Add-in contains logic to do that you would see the behavior you report.

    Thursday, March 10, 2011 4:26 PM
    Moderator
  • Hi

    Thanks for your replies

    I have tested with different files in the OLE-object, both rtf-files saved as .DOC and "pure" Word 97-2003 .DOC-file with the same result.

    I created my file with Wordpad, saved it in RTF-format and simply renamed file extension.

    What do you mean by "spawns more documents"?

    I have a version of my add-in where all the logic is cut off, all events from documents is turned off and not a single object is created, but with the same annoying behaviour.

     


    Best Regards Peter Karlström Midrange AB, Sweden
    Thursday, March 10, 2011 9:33 PM
  • Hi Peter,

    > I have a version of my add-in where all the logic is cut off, all events from documents is turned off and not a single object is created, but with the same annoying behaviour.

    Try reproducing the same on a new empty add-in. Make sure that all other COM add-ins and smart tags are turned off. Also the effect can be produced by VBA code in a template attached to the document.

    Regards from Belarus (GMT+2),

     

    Andrei Smolin

    Add-in Express Team Leader

    Friday, March 11, 2011 8:19 AM
  • Hello Andrei and Peter,

    On a Windows 7 system, I used Peter's description to build a RTF file named RTFTest.rtf and renamed that to RTFTest.doc. It opened without incident in Word 2010. I removed all add-ins from Word's Add-in option list. Then built a new empty VB .Net Word Add-in in Visual Studio 2010. The code is :

     

     

     

    Class ThisAddIn

     

     

    Private Sub ThisAddIn_Startup() Handles Me.Startup

     

     

    End Sub

     

     

    Private Sub ThisAddIn_Shutdown() Handles Me.Shutdown

     

     

    End Sub

    End

     

     

    Class

     

     

     


    I already had the VB6 test project. I ran it, saw the contents of RTFTest.doc embed into the OLE1 container, saw WinWord appear in Task Manager's Processes list, disappear from the list, and Word was not running. When I re-opened RTFTest.doc outside of the VB6 project there was only one instance of WinWord in the processes list.

    On a different Windows 7 system I installed Office 2007, VB6, and Visual Studio Professional 2008. Using the same RTFTest.doc, a new VB6 project, Word 2007, and no Add-ins the contents of RTFTest.doc appeared without incident in OLE1. Then I created a Word 2007 Add-in using VS2008. The code is identical to that shown above. When I repeated the test with the add-in loaded the problem didn't occur.

    Please tell me whether I have missed a step or an element when creating any of the components of the test on my systems.

    If my process matches those of yours, since you both report the problem, and Andrei doesn't have Peter's add-in and you both are in Europe, while my locale is EN-US, a guess is that some difference in the context of your respective environments is the source of the problem. 

    Public

    Monday, March 14, 2011 7:25 PM
    Moderator
  • Hi agian

    Sorry for the dealy, but you know about busy days, right?

    I found out what's causing this behaviour.

    I followed Andrei Smolin suggestion and created a brand new empty Add-in.

    I then added code and declarations bit by bit from my original Add-in.
    The procedure that causes Word to not end, is this one:

    Private Sub Application_DocumentOpen(ByVal Doc As Microsoft.Office.Interop.Word.Document) Handles Application.DocumentOpen
    
    
    
    End Sub
    
    

    The Sub doesn't have to have any code in it.
    As soon as the procedure exists Word doesn't end automatically.

    Now, this is a rather important Sub in my Addin, and I guess for many others too, so I can't really do without it.

    Is there a workaround for this?

    Thanks in advance

     

     


    Best Regards Peter Karlström Midrange AB, Sweden
    Friday, March 18, 2011 12:09 PM
  • Hi Bessie

    Have you got in contact with tha person you had in mind for my problem?

    See also my latest response below about the Sub DocumentOpen.

     


    Best Regards Peter Karlström Midrange AB, Sweden
    Friday, March 18, 2011 12:11 PM
  • Hi Peter,

    Try releasing the argument of that event handler by calling System.Runtime.InteropServices.Marshal.ReleaseComObject(Doc). Does it help?


    Regards from Belarus (GMT + 2),

    Andrei Smolin
    Add-in Express Team Leader
    Friday, March 18, 2011 4:56 PM
  • Hi Andrei

    Where and when should I do the ReleaseComObject?

    I have added some logging to my addin for everything that happens, and a strange happens:

    The Sub Application_DocumentOpen runs BEFORE ThisAddin_Startup? Is this normal?

     

    Thanks in advance


    Best Regards Peter Karlström Midrange AB, Sweden
    Wednesday, March 23, 2011 1:21 PM
  • Hi Peter,

    Private Sub Application_DocumentOpen(ByVal Doc As Microsoft.Office.Interop.Word.Document) Handles Application.DocumentOpen


        System.Runtime.InteropServices.Marshal.ReleaseComObject(Doc)
    End Sub

    > The Sub Application_DocumentOpen runs BEFORE ThisAddin_Startup? Is this normal?

    The VSTO loader intercepts the AddinInitialize and AddinStartupComplete methods of the IDTExtensibility2 interface. They decided to do this provide you with a single event: ThisAddin_Startup. I suppose in your case, they had no other choice as to fire DoumentOpen before ThisAddin_Startup. It seems, the other variant is to not fire DocumentOpen at all.


    Regards from Belarus (GMT + 2),

    Andrei Smolin
    Add-in Express Team Leader
    Wednesday, March 23, 2011 2:35 PM
  • Hi Peter and Andrei,

    Thank you both for supplying the code snippets. When I added the event handler to the Add-in and ran the test WinWord stayed in the process list.

    When I added Andrei's code to the event handler then rebuilt the add-in WinWord appeared, then disappeared from the process list.

    The problem arises because of the way .NET handles delegates. The event handler created the object from WinWord, and doesn't tell the garbage handler to clear it. The ...ReleaseComObject(Doc) call gives the object to the garbage handler.

    Thanks, again to both of you for giving us a reproducable case and the fix.

    Wednesday, March 23, 2011 2:40 PM
    Moderator
  • Hi

    This is not exactly true when I try this.

    What happens here is that the handle to the RTF-document finally releases, (the ~tempfil.doc disappears), but the winword process remains in tasklist. When I start Word manually afterwords, the previously RTF-documents are not visible.

    So, this resolves half the problem. The Winword process remains in memory without visible windows when the OLE-client ends. This doen't feel like a prefect scenario.

    cjatms, can you send my your hole source-code for this testproject? Maybe there is some other setting in the compiled Add-In which differs from my solution.

     


    Best Regards Peter Karlström Midrange AB, Sweden
    Thursday, March 24, 2011 6:28 AM
  • Hi Peter,

    > The Winword process remains in memory without visible windows when the OLE-client ends.

    Do you reproduce this with an empty add-in that intercepts ONLY DocumentOpen and releases the Doc parameter in that event?


    Regards from Belarus (GMT + 2),

    Andrei Smolin
    Add-in Express Team Leader
    Thursday, March 24, 2011 9:51 AM
  • Hi Andrei

    Yes. That and nothing else. Dokument handle releases but Winword process remains running.

    This is all the code:

    Public Class ThisAddIn
    
    
      Private Sub ThisAddIn_Startup(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Startup
    
    
      End Sub
    
    
      Private Sub ThisAddIn_Shutdown(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Shutdown
    
    
      End Sub
    
    
      Private Sub Application_DocumentOpen(ByVal Doc As Microsoft.Office.Interop.Word.Document) Handles Application.DocumentOpen
    
    
        System.Runtime.InteropServices.Marshal.ReleaseComObject(Doc)
    
    
      End Sub
    
    End Class
    

    What can differ from my test and yours?


    Best Regards Peter Karlström Midrange AB, Sweden
    Thursday, March 24, 2011 3:58 PM
  • Hi Peter,

    I don't understand. You said DocumentOpen occurs before ThisAddin_Startup; but the add-in above is empty, Application_DocumentOpen is never called and releasing anything in that method doesn't make sense.

    If the issue is reproducible with this add-in, I'd look for the cause in some other place. Say, did you install all updates on Windows, Office, Visual Studio and .NET Framework? Also, do you use VB6 SP6?

    I cannot reproduce the issue in Windows 7 + VS 2008 (VS 2010) + Word 2010.

    Have you turned off COM add-ins, Smart tags and extra Word templates?


    Regards from Belarus (GMT + 2),

    Andrei Smolin
    Add-in Express Team Leader
    Thursday, March 24, 2011 5:27 PM
  • Hi Peter and Andrei,

    Here is the total class for my example:

    Public Class ThisAddIn
    
    
    
     Private Sub ThisAddIn_Startup() Handles Me.Startup
    
    
    
     End Sub
    
    
    
     Private Sub Application_DocumentOpen(ByVal Doc As Microsoft.Office.Interop.Word.Document) Handles Application.DocumentOpen
    
      System.Runtime.InteropServices.Marshal.ReleaseComObject(Doc)
    
    
    
     End Sub
    
    
    
     Private Sub ThisAddIn_Shutdown() Handles Me.Shutdown
    
    
    
     End Sub
    
    
    
    End Class
    
    


    This is the add=in generated by VS 2010 and the version of VSTO that comes as a component. The difference between this and Peter's is apparently the result of using an earlier version of VSTO.  This encounters the same problem with .NET delegates.  Both the ThisAddIn_Startup(... and the ThisAddIn_Shutdown(... in Peter's code specify parameters ByVal sender and ByVal e

    Peter, try adding these calls to your Startup and Shutdown methods:
    System.Runtime.InteropServices.Marshal.ReleaseComObject(sender)
    &
    System.Runtime.InteropServices.Marshal.ReleaseComObject(e)
    Try using only the first call, and if that works, splendid.  If it doesn't work, add the second call.

    Please let us know the results.

     

    Friday, March 25, 2011 2:10 PM
    Moderator
  • Hi

    The difference between our solutions is that my VST Addin is created for Word 2007, which is the one my customer has installed on all their clients, and as I mentioned in the primary post.

    It seems this is Office version-related issues, but I would appreciate any help solving this for Word 2007, Visual Studio 2008 and .NET Framework 3.5.

    Thanks in advance


    Best Regards Peter Karlström Midrange AB, Sweden
    Friday, March 25, 2011 2:34 PM
  • Hi Andrei

    The code I ran (and logged) differs from the one posted here. Only thing added is a logging function, but the result is the same with or without the logging.

    And the problem is not in Word 2010, it's in Word 2007 as I mention in my primary post.

    Also, my customers clients are running Windows XP SP3, not yet Windows 7.

    Thanks any way


    Best Regards Peter Karlström Midrange AB, Sweden
    Friday, March 25, 2011 2:39 PM
  • Hi Peter,

    in my last reply I suggested you try releasing the 'sender' objects from the Startup and Shutdown methods. On the system with Word 2007, VS 2008 and .NET framework 3.5 I tested using this VB .NET code:

    Public Class ThisAddIn

     Private Sub ThisAddIn_Startup(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Startup

     End Sub

    Private Sub Application_DocumentOpen(ByVal Doc As Microsoft.Office.Interop.Word.Document) Handles Application.DocumentOpen
      
    End Sub

    Private Sub ThisAddIn_Shutdown(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Shutdown

    End Sub

    End Class

    This ran with the same results as you see.
    Then I added this call in the Application_DocumentOpen delegate
      System.Runtime.InteropServices.Marshal.ReleaseComObject(Doc)
    Now the project contained the following code:

    Public Class ThisAddIn

    Private Sub ThisAddIn_Startup(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Startup

    End Sub

    Private Sub Application_DocumentOpen(ByVal Doc As Microsoft.Office.Interop.Word.Document) Handles Application.DocumentOpen

       System.Runtime.InteropServices.Marshal.ReleaseComObject(Doc)


    End Sub

    Private Sub ThisAddIn_Shutdown(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Shutdown

    End Sub

    End Class

    This caused Winword to remain in the process list, but the unnamed Docment1 was no longer in WinWord.

    Then I changed the code thus:

    Public Class ThisAddIn

    Private Sub ThisAddIn_Startup(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Startup
       System.Runtime.InteropServices.Marshal.ReleaseComObject(sender)
    End Sub

    Private Sub Application_DocumentOpen(ByVal Doc As Microsoft.Office.Interop.Word.Document) Handles Application.DocumentOpen
       System.Runtime.InteropServices.Marshal.ReleaseComObject(Doc)
    End Sub

    Private Sub ThisAddIn_Shutdown(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Shutdown
      System.Runtime.InteropServices.Marshal.ReleaseComObject(sender)

    End Sub

    End Class

    As you type the statement "System.Runtime.InteropServices.Marshal.ReleaseComObject(
    just at that point the intellesense will show you a list of objects (light blue icons) that include 'sender' .  That is the one to release.

    This really stems from the use by .NET of the iUnknown interface. When you program in C++ or C# or VB .Net they all use layers of objects built atop iUnknown. iUnknown has 3 methods - QueryInterface, AddRef, and Release. Other COM objects all are built by overriding iUnknown. If the release call is not made the object remains in the process. In the project you use as an example the 3 objects for which .NET's delegate is called you leave a Doc, and a sender object in the WinWord process. The VSTO 3.0 or 3.5 that is used with VS 2008 writes a method signature that includes the ByBal Doc to the DocumentOpen method, and the ByVal sender As Object and e As System.EvenArgs parameters. The VSTO that is built into VS2010 does not generate a method signature with parameters for the Startup and Shutdown methods. Since you don't get the sender object you don't have to release it.

    Peter. Please try changing you code by adding the call
       System.Runtime.InteropServices.Marshal.ReleaseComObject(sender)
    to both the Startup and the Shutdown methods.
    What do you have to lose?

    Monday, March 28, 2011 8:23 PM
    Moderator
  • Hi Chris

    Thanks for your reply.
    I thought for a moment that this must be IT, but unfortunately I get exception errors running exactly your code.

    This is the error I get in both ThisAddIn_Startup and ThisAddIn_Shutdown (translated from swedish...):

    The type of the object must be either _ComObject or be derived from _ComObject. Parametername: o
    (Objektets typ måste antingen vara __ComObject eller vara härledd från __ComObject. Parameternamn: o)

    System.ArgumentException was unhandled by user code
      Message="Objektets typ måste antingen vara __ComObject eller vara härledd från __ComObject. Parameternamn: o"
      ParamName="o"
      Source="mscorlib"
      StackTrace:
           vid System.Runtime.InteropServices.Marshal.ReleaseComObject(Object o)
           vid SKBMall.ThisAddIn.ThisAddIn_Startup(Object sender, EventArgs e) i D:\Data\Kunder\Logica\SKB\Källkod\Word Addin\Version 4.0.4.7\SKBMall\ThisAddIn.vb:rad 61
           vid Microsoft.Office.Tools.AddIn.OnStartup()
           vid SKBMall.ThisAddIn.FinishInitialization() i D:\Data\Kunder\Logica\SKB\Källkod\Word Addin\Version 4.0.4.7\SKBMall\ThisAddIn.Designer.vb:rad 55
           vid Microsoft.VisualStudio.Tools.Office.EntryPointComponentBase.Microsoft.VisualStudio.Tools.Applications.Runtime.IEntryPoint.FinishInitialization()
           vid Microsoft.VisualStudio.Tools.Applications.AddInAdapter.ExecutePhase(ExecutionPhases executionPhases)
           vid Microsoft.VisualStudio.Tools.Applications.AddInAdapter.CompleteInitialization()
           vid Microsoft.VisualStudio.Tools.Office.Internal.OfficeAddInAdapter.ExecuteEntryPointsHelper()
           vid Microsoft.VisualStudio.Tools.Office.Internal.OfficeAddInAdapter.ExecuteEntryPoints()
           vid Microsoft.VisualStudio.Tools.Applications.AddInAdapter.Microsoft.VisualStudio.Tools.Applications.Contract.IEntryPointContract2.ExecuteEntryPoints()
      InnerException:

    Is there som other settings in a default VSTO Addin that I have to change?

    Thanks in advance


    Best Regards Peter Karlström Midrange AB, Sweden
    Monday, March 28, 2011 9:45 PM
  • Hello Peter,

    The problem you report makes it sound as though the ...ReleaseComObject parameter is not defined - it's brand new to the compiler or to CLR. Is the string in within the parentheses of the ReleaseComObject(... the exact same string shown as the first parameter of the signature of the StartUp and ShutDown methods supplied by VSTO?

    When the add-in is compiled the first parameter of the signature (ByVal sender as Object,...) is added to the objects tree of the add-in, where it should been seen by the name of 'sender'. Once it is in the objects tree then 'sender' is defined as an object, and if it is not released and set to null it won't throw the error when it is used as the argument in the ...ReleaseComObject(sender) call.  When you write the line of code:
         System.Runtime.InteropServices.Marshall.ReleaseComObject(
    do you get the intellisense list of the registered Com Objects? If so, does the list include 'sender' (without the quotes)?  If you press the tab key to choose that object, by name, and close the call with the final ) parenthesis, then build the project do you see any error?  When you load the add-in into Word and run Word do you get the error?

    As an experiment try modifying the StartUp event handler by commenting out the code to ...ReleaseComObject

    That leaves your project with a call in the in the DocumentOpen handler and in the ShutDown handler.

    If the error doesn't happen try changing the code again - uncommenting the call in StartUp, and commenting the code in ShutDown.  If the error doesn't happen uncomment all three calls to ...ReleaseComObject, build the project and start Word again. Please post the results for each test run.

    Tuesday, March 29, 2011 5:51 PM
    Moderator
  • Hi Chris

    Thanks for hanging on here...

    Yes, same string is seen both in Sub declaration and the ReleaseComObject call:
    This is my complete code:

    Public Class ThisAddIn 
    Private Sub ThisAddIn_Startup(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Startup
     System.Runtime.InteropServices.Marshal.ReleaseComObject(sender)
     End Sub
     Private Sub Application_DocumentOpen(ByVal Doc As Microsoft.Office.Interop.Word.Document) Handles Application.DocumentOpen
     System.Runtime.InteropServices.Marshal.ReleaseComObject(Doc)
     End Sub
     Private Sub ThisAddIn_Shutdown(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Shutdown
     System.Runtime.InteropServices.Marshal.ReleaseComObject(sender)
     End Sub
    End Class

    Also, when I put a Break at the ReleaseComObject line, I can se that sender is of type {WordAddIn.ThisAddin}.

    Regarding intellisense, I get sender (in blue) in the list when I type the first parentesis after ReleaseComObject.

    Here is result for the tests:

    TEST 1: (comment ReleaseComObject in Startup)
    Handle to unnamed Docment1 is closed, but winword remains running.

    TEST 2: (comment ReleaseComObject in ShutDown)
    RTF-text is displayed in OLE-program and at the same time an excetion error in Word occurs as described earlier. A messagebox is showm about this exception, and when I click OK winword closes.

    Test with all calls uncommented not run due to the errors above.

    Thanks for your help


    Best Regards Peter Karlström Midrange AB, Sweden


    Wednesday, March 30, 2011 10:25 AM
  • Hello Peter,

    Thanks for the report on your tests. Several years ago another customer reported the same problem (not the message, but the problem dismissing WinWord. ) The message results from the Add-in registering as "WordAddIn.ThisAddin" as not a _ComObject. The basic problem was reported as a bug with the description "Word 12\Programmability: VSTO 3.0: Word 2007 hangs after inserting file using "Insert Object" and if Word Addin registered to an application event (E.g: DocumentbeforeClose)" This differs from your code by the E.g being DocumentOpen rather than the DocumentBeforeClose.

    The root cause is explained in the blog at the following address: http://blogs.msdn.com/vsofficedeveloper/pages/excel-ole-embedding-errors-with-managed-addin.aspx
    In that article it talks about why this behavior occurs. It’s because of design conflict between OLE (which expects deterministic reference count) and .NET (which uses non-deterministic GC).

    I tested using Word 2007 and VSTO 3 on a Windows 7 system, and did not get the error message about WordAddIn .ThisAddin (i.e. sender) not being a Com object. That difference could stem from one or all of the differences between that system and yours The primary one being Windows 7 versus Windows XP. Is you test machine Windows XP. If not that or Windows Vista, but Windows 7, then one or more of the other differences may be the source of that message. The system I use for test has
    Microsoft .NET Compact Framework 2.0 SP2 build 2.0.7045
    Microsoft .NET Compact Framework 3.5 build 3.5.7283
    Microsoft .NET Framework 4 Client Profile build 4.0.30319
    Microsoft Enterprise 2007 build 12.0.6425.1000
    Microsoft Visual Studio 2008 Professional Edition - ENU
    Visual Studio Tools for Office Second Edition Runtime
    Visual Studio Tools for Office System 3.0 Runtime

    The solution for the other customr's problem is to not use event handler delegate for the Word events, but instead replace them with late-binding IConnectionPoint event handlers. There is a knowledge base article that describes doing this for PowerPoint events. The approach described there works well with WinWord events.  The KB article is
    308330 How to handle PowerPoint 2002 events by using Visual Basic .NET 2002
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;308330
    You need to include a 'stub' Method as the event handler for every WinWord 2007 event. This will be a method with a call to inside your stub function, call Marshal.ReleaseComObject on each document object passed as a parameter to the event. This will free the reference .NET adds to the object when handing the event.  Where you need application code you place it in the event stub and at the end call Marshall.ReleaseComObject for the document object.

    Please let us know if you have questions about the information above, and the results from using it.
    Regards

    Wednesday, March 30, 2011 5:43 PM
    Moderator
  • Hi Chris

    Thanks for all your investigations and support in this.

    The solution is unfortunately a little to big of a change in the current solution, specially since the problem don't seem to occur in Windows 7 and/or Office 2010.
    My customer is moving towards a client upgrade to Office 2010 and Windows 7 in the "almost" near future, and I will suggest for them to just wait for this.

    Again, THANKS for your support and wisdom.

     


    Best Regards Peter Karlström Midrange AB, Sweden
    Thursday, March 31, 2011 5:13 PM