The programming example is completely inadequate to demonstrate how to use interop with Excel. In your example, you skip the most difficult steps (saving and exiting). I suspect this is because the interface is problematic.

It's widely known that Excel simply won't exit properly if you do nearly anything useful. The "community hive mind" solution is to add a huge amount of extra code to cleanup:

if (excel != null)
{
	excel.DisplayAlerts = true;
        excel.Quit();
        System.Runtime.InteropServices.Marshal.FinalReleaseComObject(excel);
        excel = null;
}

Why should I need to use marshaling to release this object? Why do I have to set the object to null? Why can't these cleanup chores be part of excel.Quit()? Why doesn't garbage collection deal with this when the application closes?

You don't just need to do that with the excel object either. You do this for every excel object you used: workbooks, worksheets, ranges, etc. I find myself writing no more than a line or two of code before I debug and check to see if there is an orphaned Excel app in task manager.

It would be nice if this worked better, but in it's current state, developing with Office interop is terribly expensive due to the time it takes to debug.

Even in your example, if you close the excel app without saving, you will be left with an orphaned excel app process in task manager.

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 5f0293f1-9cc7-1c81-351b-4f37784dd39d
• Version Independent ID: 5925edd7-d9bb-80d4-c722-922ef3cbc1a3
• Content: Walkthrough: Office Programming (C# and Visual Basic)
• Content Source: docs/csharp/programming-guide/interop/walkthrough-office-programming.md
• Product: dotnet-csharp
• Technology: csharp-advanced-concepts
• GitHub Login: @BillWagner
• Microsoft Alias: wiwagn

Associated WorkItem - 447342