VB.NET与C# Office Interop差异：为何Excel随VB.NET程序结束自动关闭？

二者的核心处理差异 #

1. COM对象引用管理机制不同 #

• C#对COM互操作对象（RCW，Runtime Callable Wrapper）的引用管理是显式且严格的：Interop生成的包装类不会自动释放底层COM对象，必须手动调用Marshal.ReleaseComObject或Marshal.FinalReleaseComObject来减少原生COM对象的引用计数。如果遗漏了某个嵌套对象（比如Workbook下的Worksheet、Range）的释放，或者释放顺序错误，就会导致原生COM对象的引用计数无法降到0，Excel进程无法退出。
• VB.NET内置了COM对象自动回收逻辑：VB.NET的RCW会在对象被垃圾回收时，自动调用释放逻辑清理底层COM对象。就算开发者完全不写手动释放代码，只要RCW被GC回收，对应的COM引用就会被清理，不需要逐个处理嵌套对象。

2. 程序退出时的GC执行逻辑差异 #

• C#控制台程序退出时，CLR不会强制立即触发完整的垃圾回收，尤其是如果还有未被标记为可回收的RCW对象，它们的终结器（Finalizer）可能来不及执行，导致COM对象残留。就算手动写了释放代码，只要存在隐式引用（比如某个局部变量的引用还留在栈上），就可能导致释放不彻底。
• VB.NET控制台程序退出时，CLR会更彻底地触发GC，并且结合VB.NET特有的RCW终结逻辑，所有关联的COM对象都会被清理，Excel进程会正常退出。

为什么VB.NET在该场景下表现更优 #

1. 原生适配COM互操作：VB.NET从设计阶段就针对COM场景做了优化，默认启用了"Release on Finalize"机制，开发者不需要手动管理COM对象的引用计数，大幅降低了遗漏释放的概率。
2. RCW终结器实现差异：VB.NET生成的RCW在终结阶段会自动调用Marshal.ReleaseComObject释放底层COM对象，而C#的RCW默认没有这个逻辑，必须依赖开发者手动处理，很容易出错。
3. 变量生命周期的隐式处理：VB.NET中变量超出作用域后，会更快地被标记为可回收；而C#中局部变量的引用可能会在栈上保留一段时间，导致GC延迟回收RCW，进而延迟释放COM对象。

C#场景下的正确处理建议 #

如果要在C#中确保Excel进程正常退出，需要做到：

• 逐个释放所有层级的COM对象（Application、Workbook、Worksheet、Range等），释放顺序与创建顺序相反
• 使用Marshal.FinalReleaseComObject替代Marshal.ReleaseComObject，确保一次性将COM对象的引用计数降到0
• 释放后将变量置为null
• 手动触发GC并等待终结器执行：

// 释放完所有COM对象后执行
GC.Collect();
GC.WaitForPendingFinalizers();

内容的提问来源于stack exchange，提问作者t3chb0t