"Robinson" wrote:

>
>
>
> > On closing our App, we get following 'InvalidComObjectException': "COM
> > object that has been separated from its underlying RCW cannot be used"
>
>
>
> Hi,
>
>
> I used to get this error often when trying to use an object that has been
> garbage collected.  You should make sure you explicitly dispose and RELEASE
> all COM objects you are using, rather than relying on GC to do it for you.
> This means paying attention to return values from COM interfaces, which may
> be COM instances themselves.  You should obviously follow the general
> pattern:
>
>
>
> Dim theObject as MyComObject = Nothing
>
> Try
>
>     theObject = MyOtherComObject.GetAReferenceToSomething
>
>     ...
> Catch Ex As Exception
>
>     If theObject IsNot Nothing Then
>         Marshal.ReleaseComObject ( theObject )
>         theObject = nothing
>     End If
>
> End Try
>
>
> Also this error can occur if the application invoked to manage your com
> objects is destroyed before the objects are themselves in VB.  This means
> you have VB objects alive and well but no underlying server to handle them.
> When creating a new instance the server should be automagically started, but
> in some instances this won't happen.
>
>
>
>

"Robinson" wrote:

>
> > Hi Robinson,
> >
> > Thanks for your info.
> > Pitty enough we use quite a few com-objects in that project, making it
> > difficult to trace the problem.
> > Also al com's are subclassed through our custom framework (making it more
> > difficult to track).
> > Do you have any idea on how to know which com is/are involved?
> >
>
> Hi,
>
> To be honest I had such a headache with this kind of thing when I first
> started out with interop, I now overcompenstate and go into a paranoid panic
> whenever I instantiate anything COM related.    The basic problem is you
> have a managed COM wrapper, but the underlying object it refers to has been
> destroyed.   To get it clearer in your mind, here's a simple example:
>
>
> Dim xlApp As Microsoft.Office.Interop.Excel.Application
> Dim xlBook As Microsoft.Office.Interop.Excel.Workbook
> Dim xlSheet As Microsoft.Office.Interop.Excel.Worksheet
>
> xlApp = CType(CreateObject("Excel.Application"),
> Microsoft.Office.Interop.Excel.Application)
> xlBook = CType(xlApp.Workbooks.Add, Microsoft.Office.Interop.Excel.Workbook)
> xlSheet = CType(xlBook.Worksheets(1),
> Microsoft.Office.Interop.Excel.Worksheet)
>
> System.Runtime.InteropServices.Marshal.ReleaseComObject(xlSheet)
>
> ' This will fail - you released xlSheet above.
>
> xlSheet.Cells(2, 2) = "This is column B row 2"
>
>
> Now, how do you debug this in your application?  It's very tough. First
> thing to do is look at where you are releasing COM objects.  You must ensure
> there aren't any references to that object elsewhere in the application.
> Another way of doing this is to NEVER explicitly release the object, but to
> implement the IDisposable pattern in a wrapper class to do it for you on
> garbage collection.  Then you can explicitly "dispose" of the object if you
> want, or let GC do it when all references have been released.  I *always*
> implement the IDisposable pattern in any class I have that holds references
> to COM objects:
>
> Protected Overridable Sub DisposeManagedResources()
>
> End Sub
>
> Protected Overridable Sub DisposeUnmanagedResources()
>
> Marshal.ReleaseComObject ( xxxxxxx )
> xxxxxx = nothing
>
> End Sub
>
> Public Sub Dispose() Implements IDisposable.Dispose
>
> If m_bDisposed Then
>     Return
> End If
>
> Me.DisposeManagedResources()
> Me.DisposeUnmanagedResources()
>
> m_bDisposed = True
>
> GC.SuppressFinalize(Me)
>
> End Sub
>
> Protected Overrides Sub Finalize()
>
> If Not m_bDisposed Then
>     Me.DisposeUnmanagedResources()
> End If
>
> End Sub
>
>
>
>