To read an Excel file in C#, use the ExcelDataReader NuGet package. It streams rows from .xlsx and .xls files, runs on Windows, macOS, and Linux, and needs no Microsoft Office or COM Interop. If you also write spreadsheets, ClosedXML or ExcelMapper cover both directions.

dotnet add package ExcelDataReader

using ExcelDataReader;

using var stream = File.Open("Movies.xlsx", FileMode.Open, FileAccess.Read);
using var reader = ExcelReaderFactory.CreateReader(stream);

reader.Read(); // skip the header row
while (reader.Read())
{
    var id = Convert.ToInt32(reader.GetValue(0));
    var name = reader.GetString(1);
    var service = reader.GetString(2);

    Console.WriteLine($"{id}: {name} ({service})");
}

1: Dune: Part Two (max)
2: Oppenheimer (peacock)

That’s the quickest way to read Excel files. The rest of this post covers the other options, including how to read an .xlsx with no library at all. Every sample below uses the same Movie record from my post on writing Excel files in C#, and I compiled and ran each one on .NET 10 against a small Movies.xlsx (Id, Name, StreamingService).

public record Movie(int Id, string Name, string StreamingService);

Which C# Library Should I Use to Read an Excel File?

My rule of thumb: reach for ExcelMapper when you want objects, ExcelDataReader for raw cells or huge files, and ClosedXML when you’ll read and then edit. Can’t add a dependency at all? Keep reading.

How to Read an .xlsx File with ExcelDataReader

ExcelDataReader is a forward-only reader, similar in spirit to SqlDataReader. It never loads the whole workbook into a tree of objects, which is why it’s the quick option for large files. The example at the top is all you need for the .xlsx case.

A few things worth knowing:

• Columns are zero-based, and GetValue returns object?. Numbers come back as double, so Convert.ToInt32 is safer than a cast.
• A workbook with several sheets? Call reader.NextResult() to move to the next one, and read the current sheet name from reader.Name.
• For .xls files on .NET Core and .NET 5+, register the code pages encoding provider once at startup, or you’ll get an exception about encoding 1252:

using System.Text;

Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);

ExcelReaderFactory.CreateReader detects whether the stream is .xls or .xlsx, so the same reading code handles both formats.

using var stream = File.Open("Movies.xls", FileMode.Open, FileAccess.Read);
using var reader = ExcelReaderFactory.CreateReader(stream);

do
{
    while (reader.Read())
    {
        Console.WriteLine($"{reader.GetValue(0)} {reader.GetValue(1)}");
    }
} while (reader.NextResult());

How to Read Excel Rows into Objects with ExcelMapper

When you want a List<Movie> and nothing else, ExcelMapper is the least code. It maps header names to property names.

dotnet add package ExcelMapper

using Ganss.Excel;

var movies = (await new ExcelMapper().FetchAsync<Movie>("Movies.xlsx")).ToList();

foreach (var movie in movies)
{
    Console.WriteLine(movie);
}

public record Movie(int Id, string Name, string StreamingService);

Movie { Id = 1, Name = Dune: Part Two, StreamingService = max }
Movie { Id = 2, Name = Oppenheimer, StreamingService = peacock }

It also reads .xls, and the same library writes files back out. I go deeper on that in writing Excel files in C#.

How to Read Cell Values with ClosedXML

If you want to pick specific cells or edit the workbook afterward, ClosedXML is a pleasant API.

dotnet add package ClosedXML

using ClosedXML.Excel;

using var workbook = new XLWorkbook("Movies.xlsx");
var sheet = workbook.Worksheet("Movies");

foreach (var row in sheet.RowsUsed().Skip(1)) // skip the header
{
    var id = row.Cell(1).GetValue<int>();
    var name = row.Cell(2).GetValue<string>();
    var service = row.Cell(3).GetValue<string>();

    Console.WriteLine($"{id}: {name} ({service})");
}

GetValue<T>() converts the cell for you, and cells are 1-based. RowsUsed() skips empty rows, so you don’t need to find the last row yourself. You can also address a cell by A1 notation: sheet.Cell("B2").GetValue<string>().

How to Read an .xls (Legacy) File with NPOI

The older binary .xls format isn’t OpenXML, so the ZIP tricks below won’t work on it. ExcelDataReader and ExcelMapper handle it, and so does NPOI directly, which is a good choice if you want a low-level API.

dotnet add package NPOI

using NPOI.HSSF.UserModel;
using NPOI.SS.UserModel;

using var stream = File.OpenRead("Movies.xls");
IWorkbook workbook = new HSSFWorkbook(stream); // XSSFWorkbook for .xlsx
var sheet = workbook.GetSheetAt(0);

for (var i = 1; i <= sheet.LastRowNum; i++)
{
    var row = sheet.GetRow(i);
    Console.WriteLine($"{row.GetCell(0).NumericCellValue}: {row.GetCell(1).StringCellValue}");
}

HSSFWorkbook is for .xls, and XSSFWorkbook is for .xlsx. NPOI’s cell API is typed by cell kind, so reading a numeric cell as a string throws an exception. Check cell.CellType when you don’t control the input to ensure proper conversion is possible. Note that recent NPOI versions print a build warning asking you to accept their license terms with <AcceptNPOIOSMFLicense>true</AcceptNPOIOSMFLicense> in your project file.

How to Read an .xlsx File Without a Library

An .xlsx file is a ZIP archive of XML files, defined by the OpenXML (SpreadsheetML) standard. Rename Movies.xlsx to Movies.zip, open it, and you’ll see the elements that make up the original Excel file. The two files that matter are:

• xl/worksheets/sheet1.xml: the cells of the first sheet.
• xl/sharedStrings.xml: a table of every distinct string in the workbook.

That second file is the classic gotcha. A text cell in sheet1.xml stores an index into the shared strings table, marked with t="s", not the text itself. Numbers are different: they sit inline in the <v> element. If you skip the lookup, your names come out as 0, 1, 2.

Option 1: The Open XML SDK

Microsoft’s DocumentFormat.OpenXml package gives you typed access to those parts. It’s still just a NuGet package, with no Office and no Interop.

dotnet add package DocumentFormat.OpenXml

using DocumentFormat.OpenXml.Packaging;
using DocumentFormat.OpenXml.Spreadsheet;

using var document = SpreadsheetDocument.Open("Movies.xlsx", isEditable: false);
var workbookPart = document.WorkbookPart!;

var sharedStrings = workbookPart.SharedStringTablePart?.SharedStringTable
    .Elements<SharedStringItem>()
    .Select(s => s.InnerText)
    .ToList() ?? [];

var sheetPart = workbookPart.WorksheetParts.First();

foreach (var row in sheetPart.Worksheet.Descendants<Row>().Skip(1))
{
    var values = row.Elements<Cell>().Select(cell =>
    {
        var raw = cell.CellValue?.Text ?? "";
        return cell.DataType?.Value == CellValues.SharedString
            ? sharedStrings[int.Parse(raw)]
            : raw;
    });

    Console.WriteLine(string.Join(" | ", values));
}

1 | Dune: Part Two | max
2 | Oppenheimer | peacock

One caveat: First() isn’t necessarily the sheet named “Movies”. If you need a specific sheet, look it up through workbookPart.Workbook.Sheets and GetPartById. Also, empty cells are omitted from the XML, so row.Elements<Cell>() can skip columns. For ragged data, read each cell’s CellReference (like C2) to work out its column.

Option 2: Zero Dependencies with ZipArchive and XDocument

If you can’t add a package, the BCL has what you need. Open the file as a ZIP, as in my post on creating a ZIP file in .NET, and parse the XML with LINQ to XML.

using System.IO.Compression;
using System.Xml.Linq;

XNamespace ns = "http://schemas.openxmlformats.org/spreadsheetml/2006/main";

using var zip = ZipFile.OpenRead("Movies.xlsx");

// 1. load the shared strings table (it's absent if the workbook has no text)
var shared = new List<string>();
var sharedEntry = zip.GetEntry("xl/sharedStrings.xml");
if (sharedEntry is not null)
{
    using var sharedStream = sharedEntry.Open();
    shared = XDocument.Load(sharedStream)
        .Descendants(ns + "si")
        .Select(si => string.Concat(si.Descendants(ns + "t").Select(t => t.Value)))
        .ToList();
}

// 2. read the first worksheet
using var sheetStream = zip.GetEntry("xl/worksheets/sheet1.xml")!.Open();
var sheetXml = XDocument.Load(sheetStream);

foreach (var row in sheetXml.Descendants(ns + "row").Skip(1))
{
    var values = row.Elements(ns + "c").Select(c =>
    {
        var v = c.Element(ns + "v")?.Value ?? "";
        return (string?)c.Attribute("t") == "s" ? shared[int.Parse(v)] : v;
    });

    Console.WriteLine(string.Join(" | ", values));
}

// output
// 1 | Dune: Part Two | max
// 2 | Oppenheimer | peacock

I join the <t> elements inside each <si> because rich-text strings are split into several runs. Just be mindful about the limits, though. This version ignores dates (stored as serial numbers plus a style), inline strings (t="inlineStr"), formulas, and skipped empty cells. It’s great for a known, simple file, such as a template your own system generates, but for unfamiliar files, use a library.

FAQ

How do I read an Excel file in C# without Interop?

Use a managed library such as ExcelDataReader, ClosedXML, or ExcelMapper, or read the .xlsx yourself with the Open XML SDK or ZipArchive and XDocument. None require Excel, COM, or Office, and all work on Windows, macOS, and Linux.

How do I read an .xlsx file in C#?

Add ExcelDataReader, call ExcelReaderFactory.CreateReader(stream), and loop with reader.Read(). For objects instead of raw cells, call await new ExcelMapper().FetchAsync<T>("file.xlsx").

Can I read an Excel file without Microsoft Office installed?

Yes. An .xlsx is a ZIP of XML files, and these libraries parse it directly. Microsoft.Office.Interop.Excel is the only approach that needs Excel installed, and I’d avoid it, especially on servers.

How do I read Excel data into a list of objects?

Make a record or class whose property names match the header row, then call FetchAsync<Movie> with ExcelMapper. You get one Movie per row. If you need more control, loop over ExcelDataReader or ClosedXML rows and construct the objects yourself.

What’s the fastest way to read a large Excel file in C#?

ExcelDataReader, because it streams rows forward-only instead of building the whole workbook in memory. A hand-rolled XmlReader over the sheet XML can go lower on memory still, at the cost of doing everything yourself. ClosedXML and ExcelMapper load the workbook, so expect more memory use on big files.

Can I read an .xls file in C#?

Yes. ExcelDataReader, ExcelMapper, and NPOI all read the legacy .xls format. On .NET Core and .NET 5+, call Encoding.RegisterProvider(CodePagesEncodingProvider.Instance) first for ExcelDataReader. ClosedXML, the Open XML SDK, and the ZIP approach only handle .xlsx.

Reading a spreadsheet is the easy half. If you need to produce one too, see writing Excel files in C#. For the bigger picture, check out reading files in C#, and if the data should leave as CSV or another format, converting C# objects to almost any format.

Thanks for reading, and please leave a comment below. Also, follow me on Mastodon at @khalidabuhakmeh to get the latest .NET news and tutorials.

Written by Khalid Abuhakmeh. If this guide helped your workflow, feel free to buy me a coffee.

Get a sense for how software development teams work together, what various roles are and how they coordinate workloads.

I often talk to people who are curious about how a software development team actually works. Some of them haven’t started computer science yet and want to understand what working in the industry is really like. Others are already part of the tech industry but work in companies with very different structures and are interested in learning how other teams operate.

I’ve even had conversations with people outside the technology field who are building digital products and want to better understand how software is developed.

And honestly, I love that. Understanding how a software development team works is not only helpful for people who want to become developers. It also makes communication between technical and business teams much easier. When a client has a general understanding of the software development process, it becomes easier to understand technical decisions, development timelines and the challenges that naturally arise along the way.

That’s why I decided to write this article. I want to show you how software development teams work in the real world, based on my professional experience. Of course, every company has its own culture, processes and methodology, so there isn’t a single “right” way of working.

However, having a general understanding of how these teams operate will give you a solid foundation for understanding how software products are built and how the people behind them collaborate to make them happen.

Let’s Get to Know the Most Common Roles

When building an application, different roles work together to make it possible. While the team structure may vary from one company to another (some teams have fewer roles, while others have more), these are some of the most common roles:

• Project Manager: This person is responsible for planning and coordinating the execution of the project. They oversee the project so that deadlines are met, resources are managed effectively and project requirements are delivered according to the plan.
• UI/UX Designers: They are responsible for designing the application’s user interface and user experience. They define how the screens will look, how users will navigate through the application, the colors, typography, images and all the visual elements needed so that developers can later turn the design into a functional application.
• Developers: They are responsible for turning requirements and ideas into code. They build the application, whether it’s a mobile, web or any other type of application defined by the project, implementing the features established during the design and planning phases.
• Quality Assurance (QA): This role is responsible for validating the quality of the product. QA verifies that every feature meets the expected requirements, identifies bugs before the application reaches users and works closely with the development team so that those issues are resolved in time.

How Does the Development of an Application Begin?

Now that we’ve covered the main roles, let’s talk about how the development of an application or any software requirement actually begins.

Everything starts when the client (which can be either an external customer or an internal team within the company) defines what they need to build. And they work on these requirements hand in hand with the project manager (sometimes shortened to “PM”).

The project manager evaluates the team’s workload to determine when and how the work will be assigned. At this stage, Agile frameworks such as Scrum are extremely helpful, as they make it easier to organize the work, plan tasks and track the team’s progress.

Once the work has been planned, the project manager presents the requirements to the UI/UX design team, who are responsible for designing the application’s screens and defining the complete user flow. When the design is ready, the developers have everything they need to begin implementing the feature.

The development time depends on the complexity of the requirement. Some features may take only a few hours to complete, while others may require several days or even weeks of work.

Once the development team finishes the implementation, the feature is handed over to the QA (quality assurance) team for validation.

Environments

Although this process may vary from one company to another, it’s common to work with multiple environments. Typically, there is a Development (DEV) environment, where developers implement and perform initial testing; a Staging (STG) environment, where QA tests and validates that everything works correctly in an environment that closely mirrors production; and finally the Production (PROD) environment, where the live application is available to real users.

If QA finds any issues during testing in the Staging environment, they report them back to the development team so they can be fixed. Once the issues have been resolved and successfully validated, the app/feature is ready to be in the stores.

Using separate environments is extremely important because it allows both developers and QA engineers to test new features using test data without affecting real users or putting the stability of the production application at risk.

Why Is It Important to Understand How Software Development Teams Work?

Understanding how software development teams work can help you in many ways:

• It helps you better understand development timelines and costs. Building software involves much more than writing code, and every stage of the process takes time.
• It improves communication between technical and non-technical teams. Whether you’re a client, product manager, designer or developer, understanding the process makes collaboration much easier.
• It helps you set more realistic expectations. Understanding how software is built makes it easier to see why requirements can change and why features go through multiple stages before reaching production.
• It prepares you for your first job in tech. If you’re planning to become a software developer, understanding how software teams work will help you start your career with a stronger foundation and greater confidence.

Conclusion

And that’s it! I hope this article gave you a better understanding of how software development teams work and what the software development process looks like behind the scenes.

Remember, every company has its own way of working, but understanding the fundamentals will help you better collaborate with software teams and prepare you for the industry.

See you in the next article! ‍♀️

How many times this week did you re-explain the same task to an agent? How many times did you ask your colleague with deep institutional knowledge how to solve a specific problem? That context shouldn’t be lost in a chat or locked in one person’s head. Agent skills let you capture repeatable instructions so you and your agents can reuse them. The skill you write for yourself tonight can later become part of a team’s pipeline.

An agent skill is a versioned directory centered on a SKILL.md file that describes when and how to do a repeatable task. You can share those instructions across agents, but the environment still needs to provide the tools, credentials, and permissions to carry them out. A skill can describe how to query a database, for example, but it doesn’t grant access to that database.

I covered this topic live with Shishir Tewari, Senior Manager, Data Engineering at Procore, during GitHub Universe 2026. Our session was titled “Build once, run on any agent: a practical guide to agent skills”.

Define one job and when it applies

A skill works best when it has a clear job, input, and output. For example, let’s say you’re building an agent that checks AI-generated changes against the original request. If the same agent assesses its own work, its explanation might influence the review. With Proof Agent, we use a separate verifier to examine the changes and provide evidence for its findings. The skill’s frontmatter names the task and describes its purpose:

---
name: proof-agent
description: Adversarial verification of AI-generated work. Spawns an independent verifier to check for false claims, broken code, and security issues.
---

At the center is a simple rule: self-verification is not verification.

The When to Verify section in Proof Agent’s SKILL.md says when to invoke the skill. The remaining instructions explain what the verifier reviews and what evidence to include in its findings.

Coordinate multiple skills for a larger workflow

When the judgment that makes a data pipeline correct lives in four different people’s heads, those four people are the roadmap. Each change to the pipeline depends on their availability and knowledge of the data. Data Forge is an example of how to capture parts of that judgment in skills that work together.

In the support-desk pipeline example, we start with a request for metrics that count incidents created and resolved. Before building the pipeline, the forge-init skill discovers details such as source tables and naming conventions, then writes them to a resolved manifest. The other skills read that manifest for the project context they need.

The forge-builder skill then coordinates the work from the issue through to a pull request. It uses forge-dbx to query the data platform and forge-lint to apply the team’s standards as it designs and builds the pipeline. A person reviews the proposed decisions along the way, and the resulting pull request contains the pipeline code, schema changes, and tests.

Each skill has a defined responsibility, and they share project context instead of rediscovering it independently. When a step changes, you can change one skill and leave the rest alone.

Skills fit bounded, repeatable work that benefits from reusable judgment, such as a checklist, release, migration, or metric pipeline. If a workflow needs a stable interface, shared state, an audit trail, long-running control, or permissions enforced outside the model, an application is a better fit.

Keep project configuration out of the skill

We don’t want to hardcode every project’s names, database, or conventions into the skills. In the Data Forge support-desk example, a manifest describes the project, metric store, and platform so the skills can use the right project details without baking them into their instructions:

project:
  name: "support-desk"
  store_name: "support_metric_store"

platform:
  engine: "duckdb"
  pipeline_framework: "spark_python"
  duckdb_dir: "warehouse"

With the discovered details in the resolved manifest, the other skills don’t have to make their own assumptions about the project.

Keep discovered project details separate from team standards. The forge-init initialization skill can inspect existing schemas and code patterns; the forge-lint skill supplies the rules to follow before code is generated. A pattern found in a repository isn’t automatically a rule to preserve, so make discovered details reviewable and let people confirm or change them where business judgment is needed. To check portability, ask: could another team use these skills with its own manifest without rewriting them?

Share execution paths between skills

The forge-dbx skill gives the other Data Forge skills one way to access the data platform. It reads the manifest and selects a Databricks or DuckDB adapter, so each skill doesn’t need its own connection and query logic.

The manifest can choose DuckDB for the local support-desk demo, but it can’t install the DuckDB CLI or grant database access. Those remain setup responsibilities for the environment and its user. The manifest picks the engine; the host provides the access.

Put checks and approval points in the workflow

The Data Forge support-desk workflow has seven phases, with a human checkpoint at each one. The workflow overview shows how the skills fit together. Before a phase proceeds, the workflow checks that the previous phase is complete; before schema changes run, it asks for approval.

The Proof Agent example applies the same principle to code review. A GitHub Actions workflow gives the verifier the original request and code changes, but not the coding agent’s own assessment. The verifier returns PASS, FAIL, or PARTIAL and must cite evidence in the changed files. The GitHub Action does a static review of the diff; it doesn’t execute code or run tests. In the demo workflow, we set block-on-fail: false so findings were advisory. By default, a FAIL fails the check, which blocks the merge if the check is required. The aim is to keep test results and merge requirements in your repository’s CI checks and rules.

Package for each agent client, then verify its setup

Supporting multiple clients can mean keeping several copies of the same instructions in sync. In the Data Forge example, we keep skills/*/SKILL.md as the source and use a packaging script to generate client-specific files: .claude-plugin/plugin.json for Claude Code, .cursor-plugin/plugin.json for Cursor, and .github/agents/*.agent.md for GitHub Copilot. The script also includes a check mode for CI:

node scripts/package.mjs --check

Clients can differ in their available models, tools, credentials, and permissions. After installing a skill, check that the client recognizes it for the intended task, loads its references, can use the required tools, and returns the evidence the skill calls for.

Three practices for building agent skills

1. Put business context in one file. Keep project-specific names, schemas, and conventions in a manifest, and have each skill read it instead of duplicating those facts. This gives the team one visible place to update configuration.
2. Give related skills one consistent way to use the platform. Have related skills use the same path to run queries, jobs, and schema changes instead of each defining its own commands and connection logic. This makes the workflow’s access easier to understand and its behavior easier to check in each client.
3. Use instructions to guide the work, and checks to verify it. A skill can tell an agent which standards to follow and when to ask for approval. Add human review at decisions that need context or judgment, and use tests and CI checks to catch issues before a change moves forward. If a check must block a merge or deployment, configure that requirement in your repository’s rules.

Start with the task you’re tired of explaining. Write down what it needs, where it stops, and what a reviewer sees. Then try it with another agent and improve it as you learn what works.

The post Build once, run on any agent: A practical guide to agent skills appeared first on The GitHub Blog.