众所周知，在.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对象，就被扫地出门。