File I/O in C# — Reading, Writing and Managing Files the Right Way
Every meaningful application eventually needs to talk to the file system. Whether you're building a log aggregator, a config-file reader, a report exporter, or a data pipeline that processes CSV files overnight — the moment your app needs to persist something beyond memory, File I/O is what stands between you and a working product. Yet it's one of those topics where developers confidently write code that works on their machine and silently fails in production because of an unclosed stream, a missing directory, or a race condition with another process.
The .NET runtime gives you a surprisingly rich toolbox for file operations, and the problem isn't a lack of options — it's knowing which tool is right for which job. Should you use File.ReadAllText or StreamReader? Should your read operation be synchronous or async? What happens when the file doesn't exist yet, or when two threads try to write to it at the same time? These are the questions that separate code that ships from code that apologizes.
By the end of this article you'll understand the full lifecycle of a file operation in C#, know exactly when to reach for each API in the toolbox, write async file code that doesn't deadlock, and handle the most common real-world edge cases with confidence. The code examples here are production-grade patterns, not toy demos.
The Three Layers of File I/O in C# — and Why They Exist
C# gives you three distinct levels of abstraction for file work, each built on top of the one below it. Understanding this layering is what stops you from grabbing the wrong tool.
At the lowest level you have FileStream — raw bytes, maximum control, maximum verbosity. Above that sit StreamReader and StreamWriter, which wrap a FileStream and add character encoding and line-by-line text handling. At the top sits the static File class, which wraps everything into single-line convenience methods like File.ReadAllText and File.WriteAllLines.
The File class is perfect for small files where simplicity matters — it opens the file, does the work, and closes it all in one call. But it reads the entire file into memory at once, which is a problem when that file is 2 GB of server logs. That's when you drop down to StreamReader and read line by line, keeping your memory footprint flat regardless of file size.
FileStream is the layer you reach for when you need binary data — images, PDFs, serialized objects — or when you need fine-grained control over file sharing modes and access permissions.
Most real-world apps live in the middle layer. Know that the File convenience methods are literally just wrappers around streams — there's no magic, just convenience.
using System; using System.IO; class FileLayersDemo { static void Main() { string filePath = "sample_log.txt"; // --- LAYER 3: File class (convenience, small files) --- // Writes all content in one shot. File is opened and closed automatically. File.WriteAllText(filePath, "Line one\nLine two\nLine three\n"); // Reads entire file into a single string — fine for small config files string entireContent = File.ReadAllText(filePath); Console.WriteLine("[File.ReadAllText output]"); Console.WriteLine(entireContent); // --- LAYER 2: StreamReader (line-by-line, memory-efficient) --- // 'using' ensures the stream is closed even if an exception is thrown Console.WriteLine("[StreamReader line-by-line output]"); using (StreamReader reader = new StreamReader(filePath)) { string? currentLine; int lineNumber = 1; // ReadLine returns null when there are no more lines while ((currentLine = reader.ReadLine()) != null) { Console.WriteLine($" Line {lineNumber++}: {currentLine}"); } } // stream is guaranteed closed here // --- LAYER 1: FileStream (raw bytes, binary data) --- Console.WriteLine("\n[FileStream byte count]"); using (FileStream rawStream = new FileStream(filePath, FileMode.Open, FileAccess.Read)) { // Length gives total byte count — useful for binary files Console.WriteLine($" File size in bytes: {rawStream.Length}"); } } }
Line one
Line two
Line three
[StreamReader line-by-line output]
Line 1: Line one
Line 2: Line two
Line 3: Line three
[FileStream byte count]
File size in bytes: 33
Async File I/O — Why Blocking a Thread on Disk Reads is a Hidden Performance Killer
Here's the thing most tutorials skip: disk I/O is slow. Not 'slightly slower than memory' slow — we're talking microseconds vs milliseconds. On a web server handling 500 concurrent requests, if each request reads a file synchronously, each one blocks a thread for that entire disk-wait time. Thread pool threads are a finite resource. Block enough of them and your server stops accepting new requests even though the CPU is sitting at 2% utilisation.
Async file I/O solves this by releasing the thread back to the pool while it waits for the disk. The thread goes off and serves other requests. When the disk responds, .NET picks up any available thread to continue the work.
File.ReadAllTextAsync and StreamReader.ReadLineAsync are the async counterparts you need. They return Task and Task respectively, meaning you await them without blocking.
One critical nuance: StreamReader does NOT automatically buffer async reads efficiently when you call ReadLineAsync repeatedly in a tight loop on .NET 5 and earlier. On .NET 6+ this was fixed. If you're on an older runtime, prefer ReadToEndAsync or use FileStream with useAsync: true directly.
Async file operations belong in any application that handles concurrent workloads — ASP.NET Core controllers, background workers, and queue processors absolutely should not use synchronous file APIs.
using System; using System.IO; using System.Threading.Tasks; class AsyncFileOperations { // Simulates writing an application log entry asynchronously static async Task WriteLogEntryAsync(string logFilePath, string message) { // File.AppendAllTextAsync opens, appends, and closes — no stream management needed // The thread is released back to the pool while the OS handles the disk write string timestampedEntry = $"[{DateTime.UtcNow:yyyy-MM-dd HH:mm:ss}] {message}{Environment.NewLine}"; await File.AppendAllTextAsync(logFilePath, timestampedEntry); } // Reads a potentially large report file line by line without blocking static async Task<int> CountMatchingLinesAsync(string reportFilePath, string searchTerm) { int matchCount = 0; // StreamReader with 'await using' disposes asynchronously — important for async code await using (StreamReader reader = new StreamReader(reportFilePath)) { string? line; while ((line = await reader.ReadLineAsync()) != null) { // Case-insensitive search — realistic for log analysis if (line.Contains(searchTerm, StringComparison.OrdinalIgnoreCase)) { matchCount++; } } } return matchCount; } static async Task Main() { string logPath = "application.log"; // Simulate writing several log entries await WriteLogEntryAsync(logPath, "Application started"); await WriteLogEntryAsync(logPath, "User login: alice@example.com"); await WriteLogEntryAsync(logPath, "ERROR: Database connection timeout"); await WriteLogEntryAsync(logPath, "User login: bob@example.com"); await WriteLogEntryAsync(logPath, "ERROR: Null reference in PaymentService"); Console.WriteLine($"Log file written to: {logPath}"); // Count how many ERROR lines are in the log int errorCount = await CountMatchingLinesAsync(logPath, "ERROR"); Console.WriteLine($"Total ERROR entries found: {errorCount}"); // Read and display the full log to confirm string fullLog = await File.ReadAllTextAsync(logPath); Console.WriteLine("\n--- Full Log Contents ---"); Console.WriteLine(fullLog); } }
Total ERROR entries found: 2
--- Full Log Contents ---
[2024-03-15 09:42:11] Application started
[2024-03-15 09:42:11] User login: alice@example.com
[2024-03-15 09:42:11] ERROR: Database connection timeout
[2024-03-15 09:42:11] User login: bob@example.com
[2024-03-15 09:42:11] ERROR: Null reference in PaymentService
Defensive File I/O — Handling Missing Files, Locked Resources and Directory Errors
Production file code fails in ways your dev machine never shows you. The config file doesn't exist on first run. The log directory hasn't been created yet. Another process has locked the file. The disk is full. A relative path resolves to a completely different location when deployed.
Defensive file I/O means anticipating these realities before they become 3am incident alerts.
The key exceptions to know are FileNotFoundException (file doesn't exist), DirectoryNotFoundException (parent directory missing), IOException (file locked, disk full, network drive disconnected), and UnauthorizedAccessException (permissions). Catching the base IOException catches most of them, but be specific when the recovery action differs.
For directories: always call Directory.CreateDirectory before writing — it's idempotent and won't throw if the directory already exists. This one pattern eliminates an entire class of deployment bugs.
For locked files: the right pattern is a retry loop with exponential back-off, not a bare try/catch that swallows the error. A locked file often means another process is actively writing to it and will be done in milliseconds.
For paths: use Path.Combine instead of string concatenation — it handles directory separators correctly across Windows, Linux, and macOS. Hardcoded backslashes are a cross-platform bug waiting to happen.
using System; using System.IO; using System.Threading; class DefensiveFileIO { // Uses Path.Combine — works on Windows (\) and Linux (/) without changes static string BuildReportPath(string baseDirectory, string reportName) { return Path.Combine(baseDirectory, "reports", $"{reportName}.txt"); } // Ensures the directory exists before writing — safe to call multiple times static void EnsureDirectoryExists(string filePath) { string? directory = Path.GetDirectoryName(filePath); if (!string.IsNullOrEmpty(directory)) { // CreateDirectory does nothing if directory already exists — no need to check first Directory.CreateDirectory(directory); } } // Retries on IOException (file lock) with exponential back-off static string ReadWithRetry(string filePath, int maxAttempts = 3) { for (int attempt = 1; attempt <= maxAttempts; attempt++) { try { return File.ReadAllText(filePath); } catch (FileNotFoundException) { // No point retrying — file genuinely doesn't exist throw; } catch (IOException ex) when (attempt < maxAttempts) { // File is locked by another process — wait and retry int delayMs = 100 * (int)Math.Pow(2, attempt); // 200ms, 400ms Console.WriteLine($" File locked (attempt {attempt}), retrying in {delayMs}ms: {ex.Message}"); Thread.Sleep(delayMs); } } throw new IOException($"Could not read '{filePath}' after {maxAttempts} attempts."); } static void Main() { string reportPath = BuildReportPath(AppDomain.CurrentDomain.BaseDirectory, "monthly_summary"); Console.WriteLine($"Target path: {reportPath}"); // Safe write — creates all missing directories automatically EnsureDirectoryExists(reportPath); File.WriteAllText(reportPath, "Monthly Revenue: $142,500\nNew Users: 3,421\n"); Console.WriteLine("Report written successfully."); // Safe read with retry try { string reportContent = ReadWithRetry(reportPath); Console.WriteLine("\n--- Report Contents ---"); Console.WriteLine(reportContent); } catch (FileNotFoundException) { Console.WriteLine("ERROR: Report file not found. Generate the report first."); } catch (UnauthorizedAccessException) { Console.WriteLine("ERROR: No permission to read report. Check file permissions."); } // Demonstrate safe check before delete if (File.Exists(reportPath)) { File.Delete(reportPath); Console.WriteLine("\nReport cleaned up."); } } }
Report written successfully.
--- Report Contents ---
Monthly Revenue: $142,500
New Users: 3,421
Report cleaned up.
Working with CSV and Structured Text Files — A Real-World End-to-End Pattern
Almost every business application eventually processes CSV files — imports, exports, data migrations. This is where all the concepts above converge into a pattern you'll actually use.
The key insight for large CSV processing is streaming: read one line at a time, process it, move on. Never ReadAllLines a CSV that users upload — you're handing users a memory exhaustion attack vector. A 100 MB CSV with ReadAllLines allocates all 100 MB at once. With StreamReader.ReadLine you hold one line in memory at a time.
Encoding also matters in the real world. CSVs from Windows systems often arrive in Windows-1252 encoding. CSVs from Excel often have a UTF-8 BOM. StreamReader can auto-detect the BOM if you pass detectEncodingFromByteOrderMarks: true, which saves you from mysterious £ characters replacing £ signs.
For writing, StreamWriter with AutoFlush = false is dramatically faster than flushing after every line — let the OS buffer accumulate and flush at natural boundaries. If the process dies mid-write you'll lose the buffer, so pair this with a write-to-temp-file-then-rename pattern for atomicity.
The temp-file-then-rename pattern is the professional's choice for any file that must not be corrupted if the process dies mid-write: write to report.tmp, then File.Move("report.tmp", "report.csv", overwrite: true). The OS rename is atomic on most filesystems.
using System; using System.IO; using System.Text; class CsvProcessor { record ProductRecord(string Name, string Category, decimal Price, int StockLevel); // Streams through a CSV file line by line — memory stays flat regardless of file size static System.Collections.Generic.IEnumerable<ProductRecord> ReadProductCsv(string csvFilePath) { // detectEncodingFromByteOrderMarks handles UTF-8 BOM from Excel exports automatically using StreamReader reader = new StreamReader(csvFilePath, detectEncodingFromByteOrderMarks: true); // Skip the header row string? headerLine = reader.ReadLine(); if (headerLine == null) yield break; string? dataLine; int rowNumber = 1; while ((dataLine = reader.ReadLine()) != null) { rowNumber++; string[] columns = dataLine.Split(','); // Guard against malformed rows — real CSVs have bad data if (columns.Length != 4) { Console.WriteLine($" Skipping malformed row {rowNumber}: '{dataLine}'"); continue; } if (!decimal.TryParse(columns[2], out decimal price) || !int.TryParse(columns[3], out int stock)) { Console.WriteLine($" Skipping row {rowNumber} — invalid numeric data"); continue; } yield return new ProductRecord(columns[0].Trim(), columns[1].Trim(), price, stock); } } // Writes filtered results using temp-file-then-rename for atomicity static void WriteLowStockReport(string outputCsvPath, System.Collections.Generic.IEnumerable<ProductRecord> products) { string tempPath = outputCsvPath + ".tmp"; // AutoFlush = false — buffers writes for performance, flushed on Dispose using (StreamWriter writer = new StreamWriter(tempPath, append: false, encoding: new UTF8Encoding(encoderShouldEmitUTF8Identifier: true))) { writer.AutoFlush = false; writer.WriteLine("ProductName,Category,Price,StockLevel,StockStatus"); foreach (ProductRecord product in products) { if (product.StockLevel < 10) { string status = product.StockLevel == 0 ? "OUT_OF_STOCK" : "LOW_STOCK"; writer.WriteLine($"{product.Name},{product.Category},{product.Price:F2},{product.StockLevel},{status}"); } } } // buffer flushed and file closed here // Atomic rename — if process dies during write, original file is untouched File.Move(tempPath, outputCsvPath, overwrite: true); } static void Main() { string inputPath = "inventory.csv"; string outputPath = "low_stock_report.csv"; // Create sample inventory CSV for demonstration File.WriteAllText(inputPath, "Name,Category,Price,Stock\n" + "Wireless Keyboard,Peripherals,49.99,23\n" + "USB-C Hub,Peripherals,34.95,3\n" + "Webcam HD,Video,89.00,0\n" + "Monitor Stand,Accessories,29.50,INVALID\n" + // bad row — intentional "Laptop Stand,Accessories,44.99,7\n" + "HDMI Cable,Cables,12.99,145\n"); Console.WriteLine("Processing inventory CSV..."); var allProducts = ReadProductCsv(inputPath); WriteLowStockReport(outputPath, allProducts); Console.WriteLine("\n--- Low Stock Report ---"); Console.WriteLine(File.ReadAllText(outputPath)); } }
Skipping row 5 — invalid numeric data
--- Low Stock Report ---
ProductName,Category,Price,StockLevel,StockStatus
USB-C Hub,Peripherals,34.95,3,LOW_STOCK
Webcam HD,Video,89.00,0,OUT_OF_STOCK
Laptop Stand,Accessories,44.99,7,LOW_STOCK
| Scenario | Best API Choice | Why |
|---|---|---|
| Reading a small config file (<1 MB) | File.ReadAllText / ReadAllTextAsync | One-liner, auto-closes, sufficient for small payloads |
| Reading a large log or CSV file | StreamReader.ReadLine / ReadLineAsync | Constant memory usage regardless of file size |
| Writing binary data (images, PDFs) | FileStream with BinaryWriter | Byte-level control, no charset encoding overhead |
| Appending to an existing log file | File.AppendAllText / AppendAllTextAsync | Concise, safe, handles open/close automatically |
| High-performance bulk writing | StreamWriter with AutoFlush = false | Buffers writes, orders of magnitude faster than line-by-line flush |
| Reading all lines into a collection | File.ReadAllLines | Returns string[] directly, clean for small files with line-level iteration |
| ASP.NET Core controller file reads | Any *Async variant + await | Releases thread pool threads during disk wait, scales under load |
| Writing a file that must not corrupt | Write to .tmp, then File.Move | OS rename is atomic — original untouched if process dies mid-write |
🎯 Key Takeaways
- The static File class, StreamReader/StreamWriter, and FileStream are three layers of abstraction — pick the layer that matches your file size and control requirements, not just the one you know.
- Synchronous file reads block a thread for the entire disk-wait duration. In any concurrent application (web APIs, queues, background workers), always use the async variants and await them.
- Directory.CreateDirectory is idempotent — calling it unconditionally before any file write eliminates an entire class of deployment errors where directories don't exist on first run.
- The temp-file-then-rename pattern makes file writes atomic at zero meaningful cost. Write to 'file.tmp', then File.Move to 'file.csv'. The OS rename is atomic; your output file is never partially written.
⚠ Common Mistakes to Avoid
- ✕Mistake 1: Not disposing StreamReader/StreamWriter — Symptom: file stays locked after your code finishes; other processes get IOException: 'file is being used by another process' — Fix: always wrap stream objects in a 'using' block or 'await using' for async. The 'using' statement calls Dispose() even if an exception is thrown, which flushes the buffer and releases the OS file handle.
- ✕Mistake 2: Using File.ReadAllLines on user-uploaded or unbounded files — Symptom: OutOfMemoryException under load, server memory spikes to GBs on large uploads, eventual process crash — Fix: switch to StreamReader.ReadLine() in a while loop. You hold one line in memory at a time. If you need IEnumerable
semantics, wrap it in a generator method with yield return. - ✕Mistake 3: Building file paths with string concatenation — Symptom: code works on Windows ('C:\reports\data.csv') but throws DirectoryNotFoundException on Linux because backslash is a literal character in Unix paths — Fix: always use Path.Combine('baseDir', 'reports', 'data.csv'). It picks the correct separator for the OS automatically and handles trailing slashes correctly.
Interview Questions on This Topic
- QWhat's the difference between File.ReadAllText and StreamReader, and when would you choose one over the other in a production application?
- QIf your ASP.NET Core endpoint reads a file synchronously and your app suddenly struggles under load with high thread-pool exhaustion, what's happening and how would you fix it?
- QHow would you safely write a file that's read by an external system, ensuring the external system never sees a partially-written or corrupted file — even if your process is killed mid-write?
Frequently Asked Questions
What is the difference between File.ReadAllText and StreamReader in C#?
File.ReadAllText reads the entire file into a single string in one operation — it's concise and great for small files. StreamReader reads the file incrementally, line by line or in chunks, which keeps memory usage constant regardless of file size. For any file whose size is user-controlled or unbounded, StreamReader is the safer and more scalable choice.
How do I read a file asynchronously in C# without blocking the thread?
Use await File.ReadAllTextAsync(filePath) for small files, or 'await using (StreamReader reader = new StreamReader(filePath))' with 'await reader.ReadLineAsync()' for large ones. Both release the calling thread back to the thread pool during the disk read. This is critical in ASP.NET Core where thread-pool starvation from synchronous file reads is a real scalability problem.
Why does my C# file code work on Windows but fail on Linux?
The most common cause is hardcoded backslash path separators. Windows accepts both '\' and '/' in paths, but Linux treats '\' as a literal character in filenames. Replace all string-concatenated paths with Path.Combine(), which automatically uses the correct separator for the current OS. Also check that your filenames are lowercase — Linux filesystems are case-sensitive, unlike Windows.
Written and reviewed by senior developers with real-world experience across enterprise, startup and open-source projects. Every article on TheCodeForge is written to be clear, accurate and genuinely useful — not just SEO filler.