And I thought COM to Excel was a pain.  Having eventually discovered the tech
note that lays out the idiom for referencing Excel COM objects from .NET, I'm
still getting the familiar memory errors on program termination under certain
circumstances. The problem seems to revolve around passing Excel references
across procedure or method boundaries. I've included some sample code that
reproduces the problem consistently.  It only occurs when the loop is
executed repeatedly and if the application object passed into the function
call (as shown below). If the application object setup and teardown is moved
into the function, then no problem. This came up repeatedly in trying to
write some wrapper classes that would hide the tedious required idiom.  Is
this a futile quest? In effect, can Excel objects only be acccessed in local
variables from .NET? Thanks!
--
Module TestExcel
 Public Sub Main()
   Dim Application As New Excel.Application

   For i As Integer = 1 To 2
     Debug.WriteLine(GetCellValue(Application))
   Next

   Application.Quit()
   System.Runtime.InteropServices.Marshal.ReleaseComObject(Application)
 End Sub

 Public Function GetCellValue(ByVal Application As Excel.Application) As
String
   Dim Workbooks As Excel.Workbooks = Application.Workbooks
   Dim Workbook As Excel.Workbook = Workbooks.Add([some file name])
   Dim Worksheets As Excel.Sheets = Workbook.Worksheets
   Dim Worksheet As Excel.Worksheet = Worksheets(1)
   Dim Range As Excel.Range = Worksheet.Cells(1, 1)
   Dim rtn As String = Range.Value
   System.Runtime.InteropServices.Marshal.ReleaseComObject(Range)
   System.Runtime.InteropServices.Marshal.ReleaseComObject(Worksheet)
   System.Runtime.InteropServices.Marshal.ReleaseComObject(Worksheets)
   Workbook.Close(False)
   System.Runtime.InteropServices.Marshal.ReleaseComObject(Workbook)
   System.Runtime.InteropServices.Marshal.ReleaseComObject(Workbooks)
   Return rtn
 End Function
End Module