C# Intermediate

Namespaces organize types into logical groups and prevent naming conflicts when multiple libraries define types with the same name.

Declaration styles:

// Traditional block-scoped namespace
namespace MyCompany.MyApp.Services
{
    public class UserService { }
}

// File-scoped namespace (C# 10+) — applies to the entire file, no extra indentation
namespace MyCompany.MyApp.Services;

public class UserService { }

File-scoped namespaces (the single-line form) are preferred in modern C# projects because they reduce indentation.

Using directives:

using System;                          // imports namespace
using System.Collections.Generic;
using static System.Math;             // imports static members (e.g., use Sqrt() instead of Math.Sqrt())
using MyAlias = System.Collections.Generic.Dictionary; // alias

Global usings (C# 10+): declared once, apply to all files in the project:

// In GlobalUsings.cs or any .cs file
global using System;
global using Microsoft.Extensions.Logging;

.NET 6+ SDK projects auto-generate global using directives for common namespaces (System, System.Linq, System.Threading.Tasks, etc.) via the enable project property — enabled by default in new projects.

Nested namespaces are fully qualified with dots: MyApp.Data.Repositories. There's no requirement that the folder structure matches the namespace, though it's convention (and enforced by analyzers in many projects).

Common .NET namespaces to know:

• System — primitives, Console, Math, Environment
• System.Collections.Generic — List, Dictionary, HashSet
• System.Linq — LINQ extension methods
• System.Threading.Tasks — Task, Task
• System.Text.Json — JSON serialization (built-in since .NET Core 3.0)
• Microsoft.Extensions.DependencyInjection — DI container

Interviewers probe: using for namespace import vs using statement for resource management (IDisposable) — these are two completely different language features that share the keyword.

A class is a blueprint that defines the structure and behavior of objects. An object is an instance of that class — a concrete entity in memory with its own state.

Class anatomy:

public class BankAccount
{
    // Fields (private by convention)
    private decimal _balance;

    // Auto-property
    public string Owner { get; init; }  // init-only: settable at construction, then readonly

    // Constructor
    public BankAccount(string owner, decimal initialBalance)
    {
        Owner = owner;
        _balance = initialBalance;
    }

    // Method
    public void Deposit(decimal amount)
    {
        ArgumentOutOfRangeException.ThrowIfNegativeOrZero(amount);
        _balance += amount;
    }

    // Computed property
    public decimal Balance => _balance;
}

// Object creation
var account = new BankAccount("Alice", 1000m);
var account2 = new BankAccount { Owner = "Bob" }; // object initializer (requires public setter or init)

Modern alternatives to plain classes:

• Records (C# 9+) — immutable reference types with value-based equality and concise syntax: csharp record Person(string Name, int Age); var alice = new Person("Alice", 30); var alice2 = alice with { Age = 31 }; // non-destructive mutation
• Record structs (C# 10+) — same but value type: readonly record struct Point(double X, double Y);
• Target-typed new (C# 9+): BankAccount account = new("Alice", 1000m); — type inferred from variable.

Access modifiers for class members: public, private (default), protected, internal, protected internal, private protected.

Static members belong to the type, not instances: static int Count;, static void Helper().

Interviewers probe: when would you use a record instead of a class? Records are ideal for DTOs, value objects, and immutable data — they provide Equals, GetHashCode, ToString, and deconstruction for free.

Exception handling in C# uses try/catch/finally to respond to runtime errors without crashing the application.

Basic structure:

try
{
    var data = File.ReadAllText("config.json");
    // ... process data
}
catch (FileNotFoundException ex)
{
    Console.WriteLine($"File not found: {ex.FileName}");
}
catch (UnauthorizedAccessException ex)
{
    Console.WriteLine($"Permission denied: {ex.Message}");
    throw; // rethrow preserving original stack trace
}
catch (Exception ex) when (ex.Message.Contains("timeout")) // exception filter
{
    Logger.LogWarning("Timeout occurred");
}
finally
{
    // Always runs — cleanup code here
}

Key rules and gotchas:

• Catch most-specific first — FileNotFoundException before IOException before Exception.
• throw vs throw ex — bare throw preserves the original stack trace; throw ex resets it to the current line, losing valuable diagnostic information. Always use bare throw when rethrowing.
• Exception filters (when clause) — evaluate before the catch block runs; don't unwind the stack if the filter returns false; useful for conditional handling and logging.
• finally — always executes (even after return), ideal for cleanup. Prefer using / await using over finally for IDisposable cleanup.

Modern helpers (.NET 6+):

ArgumentNullException.ThrowIfNull(value);
ArgumentOutOfRangeException.ThrowIfNegative(amount);

Async exception handling: exceptions in async methods are captured in the returned Task and rethrown when awaited. For Task.WhenAll, exceptions are aggregated in AggregateException — use try/catch on the await to catch the first, or inspect ex.InnerExceptions for all.

Custom exceptions: inherit from Exception, add a constructor accepting string message and Exception? innerException:

public class OrderNotFoundException(int orderId)
    : Exception($"Order {orderId} not found") { }

Interviewers probe: what's wrong with catching Exception at every level? (Swallows unexpected errors, makes debugging harder.) When is it appropriate? (Top-level global handler for logging before graceful shutdown.)

Properties and indexers are member types that provide controlled access to an object's data while allowing logic to be added transparently.

Properties:

public class Person
{
    private int _age;

    // Full property with validation
    public int Age
    {
        get => _age;
        set
        {
            if (value < 0) throw new ArgumentOutOfRangeException(nameof(value));
            _age = value;
        }
    }

    // Auto-property
    public string Name { get; set; } = string.Empty;

    // Init-only (C# 9+) — settable in constructor/object initializer only
    public string Id { get; init; } = Guid.NewGuid().ToString();

    // Computed / expression-bodied
    public string DisplayName => $"{Name} (age {Age})";

    // Required (C# 11+) — must be set in object initializer
    public required string Email { get; set; }
}

Property gotcha: always prefer properties over public fields in public APIs. Properties are binary-compatible extension points — you can add logic (validation, notification) later without breaking callers. Public fields cannot.

Indexers allow a class to be accessed with array-like syntax using this:

public class WordDictionary
{
    private readonly Dictionary _data = new();

    public string this[string key]
    {
        get => _data.TryGetValue(key, out var val) ? val : string.Empty;
        set => _data[key] = value;
    }
}

var dict = new WordDictionary();
dict["hello"] = "bonjour";
Console.WriteLine(dict["hello"]); // bonjour

Indexers can have multiple parameters (this[int row, int col]) and multiple overloads. The .NET BCL uses indexers extensively (list[0], dict["key"], span[1..3]).

Interviewers probe: what is the difference between a property and a field? (Properties can have logic, are bindable in UI frameworks, support change notification, and are interface members — fields cannot be interface members.) What are init-only setters used for? (Immutable-after-construction objects that still allow object initializer syntax.)

File I/O in C# is handled primarily through types in the System.IO namespace. Modern .NET strongly favors async I/O in any environment where blocking a thread has cost (web servers, desktop apps).

High-level File class (simplest for small files):

// Read entire file async
string content = await File.ReadAllTextAsync("config.json");

// Write entire file async
await File.WriteAllTextAsync("output.txt", content);

// Read lines lazily (avoids loading entire file into memory)
foreach (string line in File.ReadLines("large.csv"))
{
    Process(line);
}

// Async lazy reading (C# 8+, IAsyncEnumerable)
// Use StreamReader for true async line-by-line

StreamReader / StreamWriter for streaming:

await using var reader = new StreamReader("data.txt");
string? line;
while ((line = await reader.ReadLineAsync()) != null)
{
    Console.WriteLine(line);
}

await using (C# 8+) calls DisposeAsync() — use it for async-disposable streams.

FileStream for binary data:

await using var fs = new FileStream("data.bin", FileMode.Open, FileAccess.Read,
    FileShare.Read, bufferSize: 4096, useAsync: true);
byte[] buffer = new byte[4096];
int bytesRead = await fs.ReadAsync(buffer);

Path handling:

string path = Path.Combine(Environment.GetFolderPath(
    Environment.SpecialFolder.MyDocuments), "file.txt");
string ext = Path.GetExtension(path);   // ".txt"
string dir = Path.GetDirectoryName(path)!;

Always use Path.Combine() — never string concatenation for paths.

JSON (built-in since .NET Core 3.0):

var options = new JsonSerializerOptions { PropertyNameCaseInsensitive = true };
var person = await JsonSerializer.DeserializeAsync(stream, options);

Interviewers probe: why use async file I/O in ASP.NET Core? — Synchronous file reads block a thread pool thread, reducing the number of concurrent requests the server can handle. Async I/O releases the thread while waiting for the OS to return data.

This is a frequent interview question because the answer has several layers:

For value types: Both == and .Equals() compare values by default (content equality). Structs inherit Equals() from System.ValueType which uses reflection-based field comparison (slow) — override it for custom structs.

For reference types:

• == by default compares references (same object in memory)
• .Equals() by default also compares references (inherited from System.Object)
• Unless overridden — string overrides both to compare content

string a = new string('h', 5); // "hhhhh"
string b = new string('h', 5);
Console.WriteLine(a == b);        // True — string overloads ==
Console.WriteLine(a.Equals(b));   // True — string overrides Equals
Console.WriteLine(ReferenceEquals(a, b)); // False — different objects

ReferenceEquals(a, b) always checks physical reference equality, regardless of overloads.

For custom classes: override both Equals(object?) and GetHashCode() together (they must be consistent — objects that are equal must have the same hash code). C# records do this automatically.

IEquatable: implement for type-safe, non-boxing equality comparison. Equals(T other) avoids boxing value types.

Gotcha — == with null:

string? s = null;
Console.WriteLine(s == null);    // True
Console.WriteLine(null == s);    // True (commutative for string)
s?.Equals(null);                 // null — safe call

Avoid s.Equals(null) when s might be null — throws NullReferenceException. Use string.Equals(s, null) or s is null (pattern matching, recommended in modern C#).