众所周知，在.net的世界里，程序员只负责使用new创建对象，而对象的销毁则完全交给垃圾回收器负责，只有当发生垃圾回收的时候，.net中的类型才会被销毁。这通常不会引起什么不妥。但是，当使用了非托管的com对象的时候，则会带来特别的问题。
com使用引用计数来确定对象的生存期，com客户每次引用对象的时候，就调用IUnKnown->AddRef()，而每次释放对象的时候，就调用IUnKnown->Release()，一旦引用计数达到零，就释放实例。问题就这样产生了，让我们看下面的代码：
这是在CSDN的asp.net版广为流传的一段使用excel com组件导出excel文件到客户端的c#代码，在添加这段代码之前，运行了添加com引用的向导。
Excel.Application oExcel;
Excel.Workbook oBook;
Object oMissing = System.Reflection.Missing.Value;
oExcel = new Excel.Application();
oBook = oExcel.Workbooks.Add(oMissing);
for (int i=1;i <=4;i++)
{
oExcel.Cells[i,1]=i.ToString();
oExcel.Cells[i,2]= "'bbb2 ";
oExcel.Cells[i,3]= "'ccc3 ";
oExcel.Cells[i,4]= "'aaa4 ";
}
oBook.Saved = true;
oExcel.UserControl = false;
string filename = DateTime.Now.Ticks.ToString();
string mm=Server.MapPath( ".")+ "\\" + filename + ".xls";//服务器保存地址
oExcel.ActiveWorkbook.SaveCopyAs (mm);
oExcel.Quit();
//GC.Collect();
Response.Redirect(filename+".xls");
这段代码能够实现导出文件的功能，但是如果察看Windows任务管理器，就会发现如下图的精彩场面
于是，有人就在代码中加了一句“GC.Collect();”，很好，EXCEL.EXE没有那么多了，如下图。
但是，如何能彻底释放呢？
幸运的是，在.net中，允许程序员显式地自己调用com的Release方法，这个方法经过.net的包装，叫做System.Runtime.InteropServices.Marshal.ReleaseComObject，在上面的代码中，调用“GC.Collect();”之前，先调用“System.Runtime.InteropServices.Marshal.ReleaseComObject((object)oExcel);”，把引用计数减一，这样，引用计数就变成了零，垃圾回收发生时，oExcel所对应的com对象，就被扫地出门。