Bagaimana untuk menggunakan C# untuk mengautomasikan tugas dalam Microsoft Excel?

Use Microsoft.Office.Interop.Excel for full Excel control when Excel is installed; otherwise prefer EPPlus for fast, cross-platform, server-safe Excel I/O without Excel.

Use Microsoft.Office.Interop.Excel to open and edit workbooks

You can automate Excel from C# by referencing the COM interop library. This is the most direct way when you need full control — like formatting cells, inserting charts, or interacting with VBA objects. But it requires Excel to be installed on the machine, and it’s not thread-safe.

Key points:

• Add reference to Microsoft.Office.Interop.Excel (via COM tab in Visual Studio’s “Add Reference” dialog)
• Always release COM objects explicitly using Marshal.ReleaseComObject() — otherwise Excel.exe stays alive in background
• Prefer early binding: declare types like Application, Workbook, Worksheet instead of object
• Set app.Visible = false unless you need UI feedback during automation

using Excel = Microsoft.Office.Interop.Excel;
using System.Runtime.InteropServices;
<p>var app = new Excel.Application();
var wb = app.Workbooks.Open(@"C:\data\report.xlsx");
var ws = wb.Sheets[1] as Excel.Worksheet;</p><p>ws.Cells[1, 1].Value = "Updated by C#";
wb.Save();
wb.Close();
Marshal.ReleaseComObject(ws);
Marshal.ReleaseComObject(wb);
app.Quit();
Marshal.ReleaseComObject(app);</p>

Prefer EPPlus for fast, server-safe Excel I/O without Excel installed

If your task is reading/writing cell data, formulas, or basic styling — and you don’t need macros, charts, or real-time interaction — skip Interop entirely. EPPlus is faster, lightweight, and runs on Linux/macOS/Windows without Office.

Important notes:

• Requires NuGet package EPPlus (v6+ needs a license for commercial use; v5.8.7 is MIT-licensed and still widely used)
• No support for VBA, pivot tables, or complex drawing objects
• Works only with .xlsx — not legacy .xls
• Memory usage is low: uses Open XML SDK under the hood, no Excel process spawned

using OfficeOpenXml;
<p>ExcelPackage.LicenseContext = LicenseContext.NonCommercial; // or Commercial if licensed
using var package = new ExcelPackage(new FileInfo(@"C:\data\output.xlsx"));
var ws = package.Workbook.Worksheets.Add("Data");
ws.Cells["A1"].Value = "Hello from EPPlus";
ws.Cells["A2"].Formula = "SUM(A1:A1)";
package.Save();</p>

Handle COMException and zombie Excel processes reliably

The biggest pain point with Interop isn’t syntax — it’s cleanup. If an exception occurs before releasing objects, Excel.exe hangs. Always wrap in try/finally, and null-check before releasing.

• Catch COMException specifically — often thrown on missing sheets, invalid ranges, or Excel already busy
• Never assume ws.Cells[row, col] exists — check for null or use ws.Cells[row, col].Value2 instead of .Value for safer type handling
• Call GC.Collect() and GC.WaitForPendingFinalizers() *after* all ReleaseComObject() calls in finally
• Use Process.GetProcessesByName("EXCEL") in dev to detect leaks — but avoid killing processes in production

When to avoid automation entirely — and what to use instead

Not every Excel-related task needs automation. If you’re generating reports from databases, consider exporting CSV or using SqlClient + DataTable.WriteXml() + XSLT. If users just need to view filtered data, a web grid with export-to-Excel button (e.g., via EPPlus on ASP.NET Core) is simpler and more scalable.

Interop makes sense only when:

• You must preserve existing Excel templates with macros or complex formatting
• You’re building an internal tool where Excel is guaranteed present
• You need to trigger or debug VBA logic from C#

Otherwise, default to EPPlus, or even CSV + System.Text.Json for structured interchange — especially if Excel is just a delivery format, not a runtime dependency.

Atas ialah kandungan terperinci Bagaimana untuk menggunakan C# untuk mengautomasikan tugas dalam Microsoft Excel?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!