C# and .NET Fundamentals

Boxing:

• Converting a value type to a reference type (object)
• The value is wrapped in an object and stored on the heap
• Implicit operation

Unboxing:

• Converting a reference type back to a value type
• Explicit operation (requires casting)
• Can throw InvalidCastException if types don't match

Example:

// BOXING - value type to reference type
int num = 123;
object obj = num;  // Boxing occurs - int copied to heap

// UNBOXING - reference type to value type
int num2 = (int)obj;  // Unboxing occurs - must cast explicitly

Performance Implications:

1. Memory Allocation: Boxing allocates memory on the heap (slower than stack)
2. Garbage Collection: Boxed objects need to be garbage collected
3. Type Safety: Unboxing requires explicit casting and runtime type checking
4. CPU Overhead: Both operations require CPU cycles

Common scenarios where boxing occurs:

// Adding value type to non-generic collection
ArrayList list = new ArrayList();
list.Add(1);  // Boxing occurs!

// String formatting
int age = 30;
string message = string.Format("Age: {0}", age);  // Boxing occurs!

// Using value types as object parameters
void PrintObject(object obj) { }
PrintObject(42);  // Boxing occurs!

How to avoid boxing:

// Use generic collections
List<int> numbers = new List<int>();
numbers.Add(1);  // No boxing!

// Use string interpolation or generic methods
string message = $"Age: {age}";  // No boxing in most cases

// Use generic constraints
void Print<T>(T value) { }
Print(42);  // No boxing!

Performance Impact:

• Boxing/unboxing in tight loops can significantly degrade performance
• Can cause increased garbage collection pressure
• Benchmark shows boxing can be 10-100x slower than working with value types directly

Extension Methods allow you to add new methods to existing types without modifying the original type, creating a new derived type, or recompiling.

Key Characteristics:

• Must be defined in a static class
• Must be static methods
• First parameter uses the "this" keyword to specify the type being extended
• Called as if they were instance methods

Syntax:

public static class StringExtensions
{
    public static bool IsValidEmail(this string str)
    {
        if (string.IsNullOrWhiteSpace(str))
            return false;
        
        return str.Contains("@") && str.Contains(".");
    }
    
    public static string Truncate(this string str, int maxLength)
    {
        if (string.IsNullOrEmpty(str) || str.Length <= maxLength)
            return str;
        
        return str.Substring(0, maxLength) + "...";
    }
}

// Usage
string email = "user@example.com";
bool isValid = email.IsValidEmail();  // Called like an instance method

string longText = "This is a very long text";
string shortened = longText.Truncate(10);  // "This is a ..."

LINQ is built on extension methods:

// These are all extension methods on IEnumerable
var result = numbers
    .Where(n => n > 5)
    .Select(n => n * 2)
    .OrderBy(n => n);

When to use Extension Methods:

1. Adding utility methods to framework types you can't modify
2. Improving code readability with fluent APIs
3. Adding domain-specific functionality to existing types
4. Creating LINQ-like query operations

When NOT to use:

1. When you can modify the original class
2. When it breaks encapsulation (accessing private members)
3. For core business logic (prefer regular methods)
4. When it might conflict with existing or future methods

Best Practices:

• Use clear, descriptive names
• Keep them simple and focused
• Group related extensions in appropriately named static classes
• Be careful with common types (string, int) to avoid naming conflicts
• Document them well

These are all collection interfaces with different capabilities and use cases.

IEnumerable<T>:

• Most basic interface for iteration
• Forward-only, read-only iteration
• Deferred execution (lazy evaluation)
• In-memory collections
• Methods: GetEnumerator()

IEnumerable<int> numbers = new List<int> { 1, 2, 3, 4, 5 };
foreach (var num in numbers)  // Can only iterate forward
{
    Console.WriteLine(num);
}
// Cannot: Add, Remove, Count, or Index access

ICollection<T>:

• Extends IEnumerable<T>
• Adds Count property
• Allows Add, Remove, Clear operations
• Still no index-based access
• Methods: Add(), Remove(), Clear(), Contains()
• Properties: Count, IsReadOnly

ICollection<int> numbers = new List<int>();
numbers.Add(1);
numbers.Remove(1);
int count = numbers.Count;  // Can get count
// Cannot: Index access like numbers[0]

IList<T>:

• Extends ICollection<T> (and IEnumerable<T>)
• Adds index-based access
• Allows insertion at specific positions
• Most feature-rich in-memory collection interface
• Methods: Insert(), RemoveAt(), IndexOf()
• Properties: Indexer [int index]

IList<int> numbers = new List<int> { 1, 2, 3 };
numbers[0] = 10;  // Index-based access
numbers.Insert(1, 5);  // Insert at position
int value = numbers[2];  // Read by index

IQueryable<T>:

• Extends IEnumerable<T>
• Designed for out-of-memory data sources (databases)
• Expression trees for query translation
• Deferred execution
• Queries translated to native query language (SQL, etc.)
• Used with LINQ to SQL, Entity Framework

// IQueryable - Query executed on DATABASE
IQueryable<User> query = dbContext.Users
    .Where(u => u.Age > 18)  // Translated to SQL WHERE clause
    .OrderBy(u => u.Name);   // Translated to SQL ORDER BY

// IEnumerable - Query executed in MEMORY
IEnumerable<User> query = dbContext.Users.ToList()  // Loads all data first!
    .Where(u => u.Age > 18)  // Filters in C# memory
    .OrderBy(u => u.Name);   // Sorts in C# memory

Comparison Table:

Performance Implications:

// BAD - Loads all users into memory, then filters
IEnumerable<User> users = dbContext.Users.ToList()
    .Where(u => u.Age > 18);

// GOOD - Filters in database, loads only matching records
IQueryable<User> users = dbContext.Users
    .Where(u => u.Age > 18);

Best Practices:

• Return IEnumerable<T> for simple read-only sequences
• Use ICollection<T> when you need Count and Add/Remove
• Use IList<T> when you need index-based access
• Use IQueryable<T> for database queries to leverage server-side filtering

Abstract Class:

• Can have implementation (concrete methods)
• Can have fields, properties, constructors
• Supports access modifiers (public, protected, private)
• Single inheritance only (a class can inherit from one abstract class)
• Can have static members
• Use "abstract" keyword

Interface:

• Cannot have implementation (before C# 8.0)
• C# 8.0+: Can have default implementation
• Cannot have fields (can have properties)
• All members are public by default
• Multiple inheritance (a class can implement multiple interfaces)
• Cannot have constructors or static members (except C# 8.0+)
• Use "interface" keyword

Example:

// ABSTRACT CLASS
public abstract class Animal
{
    protected string name;  // Field
    
    public Animal(string name)  // Constructor
    {
        this.name = name;
    }
    
    public abstract void MakeSound();  // Abstract method - must be implemented
    
    public void Sleep()  // Concrete method - shared implementation
    {
        Console.WriteLine($"{name} is sleeping");
    }
}

public class Dog : Animal
{
    public Dog(string name) : base(name) { }
    
    public override void MakeSound()
    {
        Console.WriteLine("Woof!");
    }
}

// INTERFACE
public interface IFlyable
{
    void Fly();  // No implementation
    int MaxAltitude { get; set; }  // Property
}

public interface ISwimmable
{
    void Swim();
}

public class Duck : Animal, IFlyable, ISwimmable  // Multiple interfaces!
{
    public Duck(string name) : base(name) { }
    
    public override void MakeSound()
    {
        Console.WriteLine("Quack!");
    }
    
    public void Fly()
    {
        Console.WriteLine("Duck is flying");
    }
    
    public void Swim()
    {
        Console.WriteLine("Duck is swimming");
    }
    
    public int MaxAltitude { get; set; }
}

When to use Abstract Class:

1. You have shared code that multiple derived classes can use
2. You need to define constructors or fields
3. You need non-public members (protected, private)
4. You want to provide a common base with some default behavior
5. Related classes in an "is-a" relationship (Dog IS-A Animal)

When to use Interface:

1. You need multiple inheritance
2. You want to define a contract without implementation
3. Unrelated classes need to share behavior (Duck and Airplane both implement IFlyable)
4. You want to achieve loose coupling
5. You need to define capabilities ("can-do" relationship)

Real-world example:

// Abstract class for shared behavior
public abstract class Vehicle
{
    public string Make { get; set; }
    public string Model { get; set; }
    
    public abstract void Start();
    
    public void DisplayInfo()  // Shared implementation
    {
        Console.WriteLine($"{Make} {Model}");
    }
}

// Interfaces for capabilities
public interface IElectric
{
    void Charge();
    int BatteryLevel { get; }
}

public interface IAutonomous
{
    void EnableAutoPilot();
    void DisableAutoPilot();
}

// Tesla combines abstract class and multiple interfaces
public class Tesla : Vehicle, IElectric, IAutonomous
{
    public int BatteryLevel { get; private set; }
    
    public override void Start()
    {
        Console.WriteLine("Tesla started silently");
    }
    
    public void Charge()
    {
        BatteryLevel = 100;
    }
    
    public void EnableAutoPilot()
    {
        Console.WriteLine("AutoPilot enabled");
    }
    
    public void DisableAutoPilot()
    {
        Console.WriteLine("AutoPilot disabled");
    }
}

C# 8.0+ Default Interface Implementation:

public interface ILogger
{
    void Log(string message);
    
    // Default implementation (C# 8.0+)
    void LogError(string message)
    {
        Log($"ERROR: {message}");
    }
}

Key Decision Factors:

• Need shared state/fields? → Abstract Class
• Need multiple inheritance? → Interface
• Need constructors? → Abstract Class
• Defining a contract? → Interface
• Related types? → Abstract Class
• Capabilities/behaviors? → Interface

Covariance and Contravariance allow for implicit reference conversion for array types, delegate types, and generic type arguments.

Covariance (out keyword):

• Allows you to use a more derived type than originally specified
• Enables you to assign an instance of a type to a variable of its base type
• Used with return types
• "out" keyword in generic interfaces and delegates

Contravariance (in keyword):

• Allows you to use a less derived type than originally specified
• Used with input parameters
• "in" keyword in generic interfaces and delegates

Covariance Example:

// Class hierarchy
class Animal { }
class Dog : Animal { }
class Cat : Animal { }

// COVARIANCE with IEnumerable
IEnumerable<Dog> dogs = new List<Dog>();
IEnumerable<Animal> animals = dogs;  // OK! Covariance allows this
// You can read Dogs as Animals

// Custom covariant interface
public interface IProducer<out T>  // "out" keyword
{
    T Produce();  // T only in output position
}

class AnimalProducer : IProducer<Animal>
{
    public Animal Produce() => new Animal();
}

class DogProducer : IProducer<Dog>
{
    public Dog Produce() => new Dog();
}

// Usage
IProducer<Dog> dogProducer = new DogProducer();
IProducer<Animal> animalProducer = dogProducer;  // Covariance!
Animal animal = animalProducer.Produce();  // Returns Dog, treated as Animal

Contravariance Example:

// CONTRAVARIANCE with Action
Action<Animal> animalAction = (animal) => Console.WriteLine("Animal action");
Action<Dog> dogAction = animalAction;  // OK! Contravariance allows this
// You can handle Animals where Dogs are expected

// Custom contravariant interface
public interface IConsumer<in T>  // "in" keyword
{
    void Consume(T item);  // T only in input position
}

class AnimalConsumer : IConsumer<Animal>
{
    public void Consume(Animal animal)
    {
        Console.WriteLine("Consuming animal");
    }
}

// Usage
IConsumer<Animal> animalConsumer = new AnimalConsumer();
IConsumer<Dog> dogConsumer = animalConsumer;  // Contravariance!
dogConsumer.Consume(new Dog());  // Passes Dog to method expecting Animal

Why this works:

Covariance (out): If a method returns a Dog, it's always safe to treat it as an Animal (Dog IS-A Animal)

Contravariance (in): If a method can handle any Animal, it can definitely handle a Dog (Dog IS-A Animal)

Built-in .NET Examples:

// Covariant interfaces
IEnumerable<out T>
IEnumerator<out T>
IQueryable<out T>
IGrouping<out TKey, out TElement>
Func<out TResult>

// Contravariant interfaces
IComparable<in T>
IComparer<in T>
Action<in T>
Predicate<in T>

Real-world Example:

// Covariance - returning more specific types
public interface IAnimalRepository<out T> where T : Animal
{
    T GetById(int id);
    IEnumerable<T> GetAll();
}

class DogRepository : IAnimalRepository<Dog>
{
    public Dog GetById(int id) => new Dog();
    public IEnumerable<Dog> GetAll() => new List<Dog>();
}

IAnimalRepository<Dog> dogRepo = new DogRepository();
IAnimalRepository<Animal> animalRepo = dogRepo;  // Covariance allows this!

// Contravariance - accepting less specific types
public interface IAnimalValidator<in T> where T : Animal
{
    bool Validate(T animal);
}

class AnimalValidator : IAnimalValidator<Animal>
{
    public bool Validate(Animal animal)
    {
        return animal != null;
    }
}

IAnimalValidator<Animal> animalValidator = new AnimalValidator();
IAnimalValidator<Dog> dogValidator = animalValidator;  // Contravariance!
bool isValid = dogValidator.Validate(new Dog());

Restrictions:

// INVALID - Can't use 'out' parameter in input position
public interface IInvalid<out T>
{
    void Process(T item);  // ERROR! T is output-only
}

// INVALID - Can't use 'in' parameter in output position
public interface IInvalid<in T>
{
    T GetItem();  // ERROR! T is input-only
}

// VALID - Can use invariant (no in/out)
public interface IValid<T>
{
    T GetItem();
    void Process(T item);
}

Memory Tip:

• COvariance = COmes OUT (return types) → "out"
• CONTRAvariance = goes IN (parameters) → "in"

Delegates:

• Type-safe function pointers
• Reference type that holds references to methods
• Can point to any method with matching signature
• Supports multicast (calling multiple methods)
• Can be called directly by any code that has access

Events:

• Built on top of delegates
• Special kind of delegate with restrictions
• Provides publisher-subscriber pattern
• Can only be invoked from within the declaring class
• Add/remove methods only (cannot be assigned from outside)

Delegate Example:

// Define delegate type
public delegate void NotificationHandler(string message);

public class Example
{
    // Delegate field - can be called and assigned from anywhere
    public NotificationHandler OnNotification;
    
    public void SendNotification(string msg)
    {
        // Anyone can call this delegate
        OnNotification?.Invoke(msg);
    }
}

// Usage
Example example = new Example();

// Problem: Can be assigned from outside, replacing all subscribers!
example.OnNotification = (msg) => Console.WriteLine($"Handler 1: {msg}");

// Problem: Can be called from outside the class!
example.OnNotification?.Invoke("Direct call");

Event Example:

// Define delegate type
public delegate void NotificationHandler(string message);

public class Example
{
    // Event - restricted delegate
    public event NotificationHandler OnNotification;
    
    public void SendNotification(string msg)
    {
        // Only the class itself can invoke the event
        OnNotification?.Invoke(msg);
    }
}

// Usage
Example example = new Example();

// Can only add/remove handlers (+=, -=)
example.OnNotification += (msg) => Console.WriteLine($"Handler 1: {msg}");
example.OnNotification += (msg) => Console.WriteLine($"Handler 2: {msg}");

// ERROR: Cannot assign directly
// example.OnNotification = (msg) => Console.WriteLine("Test");

// ERROR: Cannot call from outside
// example.OnNotification?.Invoke("Test");

Built-in EventHandler:

public class Button
{
    // Using built-in EventHandler delegate
    public event EventHandler Click;
    
    // Using generic EventHandler with custom args
    public event EventHandler<MouseEventArgs> MouseMove;
    
    protected virtual void OnClick()
    {
        Click?.Invoke(this, EventArgs.Empty);
    }
    
    protected virtual void OnMouseMove(MouseEventArgs e)
    {
        MouseMove?.Invoke(this, e);
    }
}

// Custom EventArgs
public class MouseEventArgs : EventArgs
{
    public int X { get; set; }
    public int Y { get; set; }
}

// Usage
Button button = new Button();
button.Click += (sender, e) => Console.WriteLine("Button clicked!");
button.MouseMove += (sender, e) => Console.WriteLine($"Mouse at {e.X}, {e.Y}");

Multicast Delegates:

public delegate void LogHandler(string message);

public class Logger
{
    private LogHandler logHandler;
    
    public void AddLogMethod(LogHandler handler)
    {
        logHandler += handler;  // Add to invocation list
    }
    
    public void RemoveLogMethod(LogHandler handler)
    {
        logHandler -= handler;  // Remove from invocation list
    }
    
    public void Log(string message)
    {
        // Calls all methods in invocation list
        logHandler?.Invoke(message);
    }
}

// Usage
Logger logger = new Logger();
logger.AddLogMethod(msg => Console.WriteLine($"Console: {msg}"));
logger.AddLogMethod(msg => File.AppendAllText("log.txt", msg));
logger.AddLogMethod(msg => Debug.WriteLine(msg));

logger.Log("Error occurred");  // Calls all three methods

Key Differences:

Real-world Example - Stock Market:

public class Stock
{
    private decimal price;
    
    // Event with custom EventArgs
    public event EventHandler<PriceChangedEventArgs> PriceChanged;
    
    public decimal Price
    {
        get => price;
        set
        {
            if (price != value)
            {
                decimal oldPrice = price;
                price = value;
                OnPriceChanged(new PriceChangedEventArgs(oldPrice, value));
            }
        }
    }
    
    protected virtual void OnPriceChanged(PriceChangedEventArgs e)
    {
        PriceChanged?.Invoke(this, e);
    }
}

public class PriceChangedEventArgs : EventArgs
{
    public decimal OldPrice { get; }
    public decimal NewPrice { get; }
    public decimal Change => NewPrice - OldPrice;
    
    public PriceChangedEventArgs(decimal oldPrice, decimal newPrice)
    {
        OldPrice = oldPrice;
        NewPrice = newPrice;
    }
}

// Subscribers
public class StockAlert
{
    public StockAlert(Stock stock)
    {
        stock.PriceChanged += OnPriceChanged;
    }
    
    private void OnPriceChanged(object sender, PriceChangedEventArgs e)
    {
        if (e.Change > 10)
            Console.WriteLine($"Alert: Price jumped by {e.Change:C}");
    }
}

public class StockLogger
{
    public StockLogger(Stock stock)
    {
        stock.PriceChanged += OnPriceChanged;
    }
    
    private void OnPriceChanged(object sender, PriceChangedEventArgs e)
    {
        Console.WriteLine($"Price changed from {e.OldPrice:C} to {e.NewPrice:C}");
    }
}

// Usage
Stock appleStock = new Stock { Price = 150 };
StockAlert alert = new StockAlert(appleStock);
StockLogger logger = new StockLogger(appleStock);

appleStock.Price = 165;  // Both alert and logger are notified

Action and Func Delegates:

// Action - no return value
Action<string> logAction = msg => Console.WriteLine(msg);
Action<int, int> addAction = (x, y) => Console.WriteLine(x + y);

// Func - with return value (last type parameter is return type)
Func<int, int, int> add = (x, y) => x + y;
Func<string, bool> isValid = str => !string.IsNullOrEmpty(str);

// Usage
int result = add(5, 3);  // 8
bool valid = isValid("test");  // true

When to use what:

• Use delegates when you need direct method reference or callbacks
• Use events when implementing observer/publisher-subscriber pattern
• Use Action/Func for simple inline delegates (LINQ, callbacks)
• Use custom delegates when you need specific naming or complex signatures

const:

• Compile-time constant
• Value must be assigned at declaration
• Value is embedded in IL code
• Implicitly static
• Can only be primitive types, enums, or string
• Better performance (no runtime lookup)

readonly:

• Runtime constant
• Can be assigned in declaration or constructor
• Value stored in memory
• Can be instance or static
• Can be any type
• More flexible

Examples:

public class Configuration
{
    // CONST - Compile-time constant
    public const int MaxConnections = 100;
    public const string AppName = "MyApp";
    public const double Pi = 3.14159;
    
    // READONLY - Runtime constant
    public readonly string ConnectionString;
    public readonly DateTime StartTime;
    public static readonly int ProcessorCount;
    
    // Readonly can be assigned in constructor
    public Configuration(string connStr)
    {
        ConnectionString = connStr;
        StartTime = DateTime.Now;  // Runtime value!
    }
    
    // Static readonly can be assigned in static constructor
    static Configuration()
    {
        ProcessorCount = Environment.ProcessorCount;
    }
}

// Usage
// Const access (no instance needed)
int max = Configuration.MaxConnections;

// Readonly access (needs instance or static)
Configuration config = new Configuration("Server=localhost");
string connStr = config.ConnectionString;

Key Differences:

Versioning Issue with const:

// Assembly A (Library)
public class Constants
{
    public const int MaxValue = 100;
}

// Assembly B (Application) - uses Assembly A
public class Program
{
    public void Process()
    {
        // Value 100 is embedded in Assembly B's IL code!
        int max = Constants.MaxValue;
    }
}

// Problem: If you change MaxValue to 200 in Assembly A and recompile only A,
// Assembly B still uses 100 (old value) until B is also recompiled!

Solution with readonly:

// Assembly A (Library)
public class Constants
{
    public static readonly int MaxValue = 100;
}

// Assembly B (Application)
public class Program
{
    public void Process()
    {
        // Value is looked up from Assembly A at runtime
        int max = Constants.MaxValue;
    }
}

// If you change MaxValue to 200 and recompile only A,
// Assembly B automatically gets the new value without recompilation!

readonly with reference types:

public class Container
{
    // readonly reference - cannot reassign, but can modify contents
    private readonly List<string> items = new List<string>();
    
    public void AddItem(string item)
    {
        items.Add(item);  // OK - modifying contents
        
        // ERROR - cannot reassign
        // items = new List<string>();
    }
}

readonly struct (C# 7.2+):

// All fields must be readonly
public readonly struct Point
{
    public readonly int X;
    public readonly int Y;
    
    public Point(int x, int y)
    {
        X = x;
        Y = y;
    }
    
    // All properties must be read-only
    public int Sum => X + Y;
}

When to use:

• Use const for: True constants that never change (Pi, MaxInt), configuration values that are known at compile-time
• Use readonly for: Values initialized at runtime, dependency injection, values from configuration files, reference types, values that may change between versions

Best Practices:

public class Settings
{
    // Good - compile-time constant
    public const int DefaultTimeout = 30;
    
    // Good - runtime value from constructor
    public readonly string Environment;
    
    // Good - complex object
    public readonly ILogger Logger;
    
    // Bad - should be const (never changes)
    public readonly int MaxRetries = 3;
    
    public Settings(string environment, ILogger logger)
    {
        Environment = environment;
        Logger = logger;
    }
}

Reflection is the ability to inspect and interact with metadata of types, assemblies, methods, and properties at runtime.

What Reflection Allows:

• Inspect types, methods, properties, and fields at runtime
• Create instances of types dynamically
• Invoke methods and access properties dynamically
• Read attributes and metadata
• Generate code at runtime

Common Use Cases:

1. Serialization/Deserialization:

// JSON serialization uses reflection to read properties
public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}

Person person = new Person { Name = "John", Age = 30 };
string json = JsonSerializer.Serialize(person);  // Uses reflection internally

1. Dependency Injection:

// DI containers use reflection to create instances
services.AddTransient<IUserService, UserService>();
// Container uses reflection to find constructor and inject dependencies

1. Attribute-Based Programming:

[Route("api/users")]
public class UsersController : ControllerBase
{
    [HttpGet("{id}")]
    [Authorize(Roles = "Admin")]
    public IActionResult GetUser(int id)
    {
        // Framework uses reflection to read Route and Authorize attributes
    }
}

1. Plugin Systems:

// Load plugins dynamically
Assembly assembly = Assembly.LoadFrom("MyPlugin.dll");
Type pluginType = assembly.GetType("MyPlugin.PluginClass");
IPlugin plugin = (IPlugin)Activator.CreateInstance(pluginType);
plugin.Execute();

Reflection Examples:

Type Inspection:

Type type = typeof(Person);

// Get properties
PropertyInfo[] properties = type.GetProperties();
foreach (var prop in properties)
{
    Console.WriteLine($"{prop.Name}: {prop.PropertyType}");
}

// Get methods
MethodInfo[] methods = type.GetMethods();

// Check if type implements interface
bool implementsInterface = typeof(IDisposable).IsAssignableFrom(type);

// Get custom attributes
var attributes = type.GetCustomAttributes(typeof(ObsoleteAttribute), false);

Dynamic Instantiation:

// Create instance without new keyword
Type type = typeof(Person);
object instance = Activator.CreateInstance(type);

// With constructor parameters
object instance = Activator.CreateInstance(type, "John", 30);

// Set property value
PropertyInfo nameProp = type.GetProperty("Name");
nameProp.SetValue(instance, "Jane");

// Get property value
object value = nameProp.GetValue(instance);

Dynamic Method Invocation:

public class Calculator
{
    public int Add(int a, int b) => a + b;
    public int Multiply(int a, int b) => a * b;
}

// Invoke method dynamically
Calculator calc = new Calculator();
Type type = typeof(Calculator);
MethodInfo method = type.GetMethod("Add");

// Invoke with parameters
object result = method.Invoke(calc, new object[] { 5, 3 });
Console.WriteLine(result);  // 8

Reading Attributes:

[AttributeUsage(AttributeTargets.Property)]
public class ValidationAttribute : Attribute
{
    public int MaxLength { get; set; }
    public bool Required { get; set; }
}

public class User
{
    [Validation(MaxLength = 50, Required = true)]
    public string Name { get; set; }
    
    [Validation(MaxLength = 100)]
    public string Email { get; set; }
}

// Read attributes using reflection
Type type = typeof(User);
foreach (PropertyInfo prop in type.GetProperties())
{
    var attr = prop.GetCustomAttribute<ValidationAttribute>();
    if (attr != null)
    {
        Console.WriteLine($"{prop.Name}: MaxLength={attr.MaxLength}, Required={attr.Required}");
    }
}

Generic Type Creation:

// Create List<int> dynamically
Type listType = typeof(List<>);
Type genericListType = listType.MakeGenericType(typeof(int));
object listInstance = Activator.CreateInstance(genericListType);

MethodInfo addMethod = genericListType.GetMethod("Add");
addMethod.Invoke(listInstance, new object[] { 42 });

Drawbacks and Limitations:

1. Performance:

// Direct call
person.Name = "John";  // Fast

// Reflection call
PropertyInfo prop = typeof(Person).GetProperty("Name");
prop.SetValue(person, "John");  // 10-100x slower!

1. Type Safety:

// Compile-time error - caught immediately
// person.NonExistentProperty = "value";  // Won't compile

// Runtime error - only caught when executed
PropertyInfo prop = type.GetProperty("NonExistentProperty");  // Returns null
prop.SetValue(person, "value");  // NullReferenceException at runtime!

1. Security Risks:

// Can access private members!
Type type = typeof(Person);
FieldInfo privateField = type.GetField("secretKey", 
    BindingFlags.NonPublic | BindingFlags.Instance);
privateField.SetValue(person, "hacked");  // Breaks encapsulation!

1. Code Maintenance:

// Refactoring tools can't update string-based references
MethodInfo method = type.GetMethod("OldMethodName");
// If method is renamed, this code breaks at runtime, not compile-time

Performance Comparison:

// Benchmark results (approximate)
// Direct call: 1 ns
// Cached reflection: 10-50 ns
// Uncached reflection: 100-1000 ns
// Expression trees: 5-10 ns

Better Alternatives:

1. Expression Trees (faster than reflection):

// Compile expression once, reuse many times
public static class PropertyAccessor<T>
{
    private static readonly Dictionary<string, Func<T, object>> Getters = new();
    
    public static object GetValue(T obj, string propertyName)
    {
        if (!Getters.ContainsKey(propertyName))
        {
            var param = Expression.Parameter(typeof(T));
            var prop = Expression.Property(param, propertyName);
            var convert = Expression.Convert(prop, typeof(object));
            var lambda = Expression.Lambda<Func<T, object>>(convert, param);
            Getters[propertyName] = lambda.Compile();
        }
        
        return Getters[propertyName](obj);
    }
}

2. Source Generators (C# 9+):

// Generate code at compile-time instead of runtime reflection
[AutoMapper]
public partial class PersonDto
{
    public string Name { get; set; }
    // Source generator creates mapping code at compile-time
}

When to Use Reflection:

• Building frameworks or libraries (DI, ORM, serialization)
• Plugin architectures
• Unit testing tools
• Code generation tools
• When dynamic behavior is absolutely necessary

When NOT to Use Reflection:

• Performance-critical code paths
• When compile-time checking is important
• When simpler alternatives exist (interfaces, delegates, generics)
• Hot paths in loops

Best Practices:

// Cache reflection results
private static readonly PropertyInfo NameProperty = typeof(Person).GetProperty("Name");

// Use binding flags to be specific
type.GetMethod("MyMethod", BindingFlags.Public | BindingFlags.Instance);

// Check for null before using
PropertyInfo prop = type.GetProperty("Name");
if (prop != null)
{
    // Safe to use
}

// Use reflection only when necessary
// Prefer: interfaces, generics, delegates

Nullable Reference Types is a C# 8.0 feature that helps prevent null reference exceptions by making reference types non-nullable by default when enabled.

Before C# 8.0:

// Any reference type could be null
string name = null;  // Always allowed
Person person = null;  // Always allowed
// NullReferenceException was common at runtime

After C# 8.0 (when enabled):

// Non-nullable reference type (default)
string name = null;  // Compiler warning!

// Nullable reference type (explicit)
string? nullableName = null;  // OK

// Using nullable reference type
void ProcessName(string name)  // name should never be null
{
    Console.WriteLine(name.Length);  // Safe, no null check needed
}

void ProcessNullableName(string? name)  // name might be null
{
    // Compiler warns if you don't check for null
    Console.WriteLine(name.Length);  // Warning!
    
    // Proper null check
    if (name != null)
    {
        Console.WriteLine(name.Length);  // OK
    }
    
    // Or use null-conditional operator
    Console.WriteLine(name?.Length);  // OK
}

Enabling Nullable Reference Types:

Project-wide (in .csproj):

<PropertyGroup>
    <Nullable>enable</Nullable>
</PropertyGroup>

File-level:

#nullable enable
public class MyClass
{
    public string Name { get; set; }  // Non-nullable
}
#nullable restore

Nullable Annotations:

public class Person
{
    // Non-nullable - must be initialized
    public string FirstName { get; set; } = string.Empty;
    
    // Non-nullable - initialized in constructor
    public string LastName { get; set; }
    
    // Nullable - can be null
    public string? MiddleName { get; set; }
    
    // Nullable - optional parameter
    public string? Suffix { get; set; }
    
    public Person(string lastName)
    {
        LastName = lastName;
    }
}

// Usage
Person person = new Person("Doe")
{
    FirstName = "John",
    MiddleName = null  // OK, explicitly nullable
};

// Warning - FirstName is non-nullable
// Person invalid = new Person("Doe"); // Warning: FirstName not initialized

Null-Forgiving Operator (!):

public class UserService
{
    private string? _cachedData;
    
    public void Initialize()
    {
        _cachedData = "initialized";
    }
    
    public string GetData()
    {
        // You know it's not null, but compiler doesn't
        // Use ! to tell compiler "trust me, it's not null"
        return _cachedData!;  // Null-forgiving operator
    }
}

Nullable Attributes:

public class StringHelper
{
    // If string is not null/empty, return is not null
    public static bool IsNullOrEmpty([NotNullWhen(false)] string? value)
    {
        return string.IsNullOrEmpty(value);
    }
    
    // Method ensures parameter is not null after return
    public static void ThrowIfNull([NotNull] string? value, string paramName)
    {
        if (value == null)
            throw new ArgumentNullException(paramName);
    }
}

// Usage
string? input = GetUserInput();

if (!StringHelper.IsNullOrEmpty(input))
{
    // Compiler knows input is not null here
    Console.WriteLine(input.Length);  // No warning
}

Common Nullable Attributes:

// [NotNull] - Parameter won't be null when method returns
void EnsureInitialized([NotNull] ref string? value);

// [NotNullWhen(bool)] - Parameter is not null when method returns true/false
bool TryParse(string? input, [NotNullWhen(true)] out int result);

// [NotNullIfNotNull("parameter")] - Return is not null if parameter is not null
[return: NotNullIfNotNull("input")]
string? Process(string? input);

// [MaybeNull] - Return may be null even for non-nullable type
[return: MaybeNull]
T GetValueOrDefault<T>();

// [MemberNotNull("field")] - Ensures field is not null after method
[MemberNotNull(nameof(_cache))]
void Initialize();

Real-World Example:

#nullable enable

public class UserRepository
{
    private readonly DbContext _context;
    
    public UserRepository(DbContext context)
    {
        _context = context;  // Non-nullable, must be provided
    }
    
    // Returns nullable - user might not exist
    public User? FindById(int id)
    {
        return _context.Users.FirstOrDefault(u => u.Id == id);
    }
    
    // Returns non-nullable - throws if not found
    public User GetById(int id)
    {
        return _context.Users.First(u => u.Id == id);
    }
    
    // Parameter is non-nullable - user must not be null
    public void Save(User user)
    {
        ArgumentNullException.ThrowIfNull(user);  // C# 11+
        _context.Users.Add(user);
        _context.SaveChanges();
    }
    
    // Parameter is nullable - updates if exists
    public void UpdateIfExists(User? user)
    {
        if (user == null)
            return;
            
        _context.Users.Update(user);
        _context.SaveChanges();
    }
}

// Usage
var repo = new UserRepository(dbContext);

// Handle nullable return
User? user = repo.FindById(123);
if (user != null)
{
    Console.WriteLine(user.Name);  // Safe
}

// Or use null-conditional
Console.WriteLine(user?.Name ?? "Not found");

// Non-nullable return
User existingUser = repo.GetById(123);  // Throws if not found
Console.WriteLine(existingUser.Name);  // No null check needed

Migration Strategy:

// Step 1: Enable for new files only
#nullable enable
// Your code here
#nullable restore

// Step 2: Gradually enable per project/assembly
// <Nullable>enable</Nullable>

// Step 3: Fix warnings incrementally
// Use nullable annotations where appropriate
// Add null checks where needed
// Use ! operator sparingly for legacy code

Generic Constraints:

// T can be null
public class Container<T>
{
    private T? _value;  // Nullable for any T
}

// T must be non-nullable reference type
public class NonNullContainer<T> where T : notnull
{
    private T _value = default!;  // Must be initialized
}

// T is nullable reference type
public T? GetOrDefault<T>() where T : class
{
    return default;  // Returns null
}

Benefits:

1. Catch null reference bugs at compile-time
2. Self-documenting code (intent is clear)
3. Better IDE support and intellisense
4. Reduced NullReferenceException at runtime
5. More confident refactoring

Common Warnings:

// CS8600: Converting null literal or possible null value to non-nullable type
string name = null;  // Warning

// CS8602: Dereference of a possibly null reference
string? nullable = null;
int length = nullable.Length;  // Warning

// CS8603: Possible null reference return
public string GetName()
{
    return null;  // Warning
}

// CS8618: Non-nullable field must contain a non-null value when exiting constructor
public class Person
{
    public string Name { get; set; }  // Warning
}

Best Practices:

• Enable nullable reference types for new projects
• Use ? for truly optional values
• Avoid using ! (null-forgiving operator) unless necessary
• Add appropriate null checks
• Use nullable attributes to provide hints to compiler
• Make intent explicit in APIs

Both methods are related to resource cleanup, but they serve different purposes and are called at different times.

Dispose():

• Part of IDisposable interface
• Called explicitly by developer
• Deterministic cleanup (you control when)
• Used for managed and unmanaged resources
• Should be called as soon as resource is no longer needed
• Can be called multiple times (should be idempotent)

Finalize():

• Also called destructor (~ClassName)
• Called by Garbage Collector
• Non-deterministic cleanup (GC decides when)
• Used primarily for unmanaged resources
• Called when object is being collected
• Cannot be called explicitly
• Delays garbage collection (performance impact)

Basic Example:

public class ResourceHolder : IDisposable
{
    private IntPtr unmanagedResource;
    private FileStream managedResource;
    private bool disposed = false;
    
    public ResourceHolder()
    {
        unmanagedResource = // Allocate unmanaged resource
        managedResource = new FileStream("file.txt", FileMode.Open);
    }
    
    // IDisposable implementation - called explicitly
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);  // Tell GC not to call finalizer
    }
    
    // Finalizer - called by GC
    ~ResourceHolder()
    {
        Dispose(false);
    }
    
    // Protected dispose method - actual cleanup logic
    protected virtual void Dispose(bool disposing)
    {
        if (!disposed)
        {
            if (disposing)
            {
                // Dispose managed resources
                managedResource?.Dispose();
            }
            
            // Free unmanaged resources
            if (unmanagedResource != IntPtr.Zero)
            {
                // Free unmanaged resource
                unmanagedResource = IntPtr.Zero;
            }
            
            disposed = true;
        }
    }
}

Key Differences:

Using Dispose() - Recommended Pattern:

// Manual disposal
ResourceHolder resource = new ResourceHolder();
try
{
    // Use resource
}
finally
{
    resource.Dispose();
}

// Better - using statement
using (ResourceHolder resource = new ResourceHolder())
{
    // Use resource
}  // Dispose() called automatically

// C# 8+ - using declaration
using ResourceHolder resource = new ResourceHolder();
// Use resource
// Dispose() called at end of scope

Full Dispose Pattern (IDisposable):

public class DatabaseConnection : IDisposable
{
    private SqlConnection connection;
    private SqlCommand command;
    private bool disposed = false;
    
    public DatabaseConnection(string connectionString)
    {
        connection = new SqlConnection(connectionString);
        command = connection.CreateCommand();
    }
    
    // Public dispose method
    public void Dispose()
    {
        Dispose(disposing: true);
        
        // Tell GC not to call finalizer
        // Improves performance by avoiding finalization queue
        GC.SuppressFinalize(this);
    }
    
    // Protected virtual dispose method
    protected virtual void Dispose(bool disposing)
    {
        if (!disposed)
        {
            if (disposing)
            {
                // Dispose managed resources
                command?.Dispose();
                connection?.Dispose();
            }
            
            // Free unmanaged resources here (if any)
            // Note: Most .NET types handle their own unmanaged resources
            
            disposed = true;
        }
    }
    
    // Optional: Finalizer (only if holding unmanaged resources directly)
    ~DatabaseConnection()
    {
        Dispose(disposing: false);
    }
    
    // Helper method to prevent use after disposal
    private void ThrowIfDisposed()
    {
        if (disposed)
            throw new ObjectDisposedException(GetType().Name);
    }
    
    public void ExecuteQuery(string query)
    {
        ThrowIfDisposed();
        command.CommandText = query;
        command.ExecuteNonQuery();
    }
}

Why Finalize() is Slow:

// Object lifecycle WITHOUT finalizer:
// 1. Object created in Gen0
// 2. GC collects Gen0
// 3. Object memory reclaimed immediately

// Object lifecycle WITH finalizer:
// 1. Object created in Gen0
// 2. GC collects Gen0
// 3. Object moved to finalization queue
// 4. Object promoted to Gen1
// 5. Finalizer thread runs ~ClassName()
// 6. GC collects Gen1
// 7. Object memory finally reclaimed

// Finalizers cause objects to survive at least one GC cycle!

When to Use Each:

Use Dispose() when:

• Working with files, database connections, network connections
• Using any IDisposable resource
• You need immediate cleanup
• Most common scenario

Use Finalize() when:

• Directly managing unmanaged resources (rare in modern C#)
• P/Invoke scenarios with unmanaged memory
• Safety net for forgotten Dispose() calls

Modern Approach - Usually No Finalizer Needed:

public class ModernResourceHolder : IDisposable
{
    private readonly FileStream _file;
    private bool _disposed;
    
    public ModernResourceHolder(string path)
    {
        _file = new FileStream(path, FileMode.Open);
    }
    
    public void Dispose()
    {
        if (_disposed)
            return;
            
        _file?.Dispose();  // FileStream handles its own finalization
        _disposed = true;
    }
    
    // No finalizer needed!
    // FileStream already has its own finalizer
}

SafeHandle - Better than Finalizer:

using System.Runtime.InteropServices;
using Microsoft.Win32.SafeHandles;

public class UnmanagedResource : IDisposable
{
    // SafeHandle provides reliable finalization
    private SafeFileHandle _handle;
    private bool _disposed;
    
    public UnmanagedResource(string path)
    {
        _handle = // Create safe handle
    }
    
    public void Dispose()
    {
        if (_disposed)
            return;
            
        _handle?.Dispose();  // SafeHandle handles finalization
        _disposed = true;
    }
    
    // No finalizer needed!
    // SafeHandle has reliable finalization built-in
}

Common Mistakes:

// WRONG - Accessing managed objects in finalizer
~BadClass()
{
    // Dangerous! Managed objects might already be finalized
    managedResource.Dispose();  // Could throw exception!
}

// WRONG - Not checking if already disposed
public void Dispose()
{
    resource.Dispose();  // Might throw if called twice
}

// WRONG - Forgetting to suppress finalization
public void Dispose()
{
    // Clean up
    // Missing: GC.SuppressFinalize(this);
}

// WRONG - Throwing exceptions in Dispose
public void Dispose()
{
    throw new Exception();  // Never throw from Dispose!
}

Best Practices:

1. Always implement IDisposable for types that hold disposable resources
2. Make Dispose() safe to call multiple times
3. Call GC.SuppressFinalize(this) in Dispose()
4. Only use finalizers when directly managing unmanaged resources
5. Prefer SafeHandle over manual finalization
6. Never throw exceptions from Dispose() or finalizers
7. Use using statements for automatic disposal
8. Document disposal requirements clearly

Exception Handling is a mechanism in C# that allows you to handle runtime errors gracefully, preventing your application from crashing and providing meaningful error messages to users.

How Exception Handling Works:

• When an error occurs, an exception object is created
• The runtime searches for an appropriate exception handler
• If found, the handler executes and the program continues
• If not found, the program terminates with an unhandled exception

Basic Exception Handling Structure:

try
{
    // Code that might throw an exception
    int result = Divide(10, 0);
}
catch (DivideByZeroException ex)
{
    // Handle specific exception
    Console.WriteLine($"Error: {ex.Message}");
}
catch (Exception ex)
{
    // Handle any other exception
    Console.WriteLine($"Unexpected error: {ex.Message}");
}
finally
{
    // Always executes (cleanup code)
    Console.WriteLine("Cleanup code here");
}

Exception Hierarchy:

System.Object
└── System.Exception
    ├── System.SystemException
    │   ├── ArgumentException
    │   ├── NullReferenceException
    │   ├── IndexOutOfRangeException
    │   └── DivideByZeroException
    └── System.ApplicationException
        └── Custom exceptions

Key Differences: throw vs throw ex vs throw new

1. throw (rethrow):

try
{
    // Some operation
}
catch (Exception ex)
{
    // Log the exception
    LogError(ex);
    
    // Rethrow the original exception (preserves stack trace)
    throw;  // GOOD - keeps original stack trace
}

2. throw ex (lose stack trace):

try
{
    // Some operation
}
catch (Exception ex)
{
    // Log the exception
    LogError(ex);
    
    // Rethrow but lose original stack trace
    throw ex;  // BAD - loses original stack trace
}

3. throw new (new exception):

try
{
    // Some operation
}
catch (Exception ex)
{
    // Create new exception with original as inner exception
    throw new CustomException("Something went wrong", ex);  // GOOD
}

When to Use Each:

• try-catch: Handle exceptions you can recover from
• try-finally: Ensure cleanup code always runs
• try-catch-finally: Handle exceptions AND ensure cleanup

Custom Exceptions:

// Custom exception class
public class InsufficientFundsException : Exception
{
    public decimal CurrentBalance { get; }
    public decimal RequiredAmount { get; }
    
    public InsufficientFundsException(decimal currentBalance, decimal requiredAmount)
        : base($"Insufficient funds. Current: {currentBalance:C}, Required: {requiredAmount:C}")
    {
        CurrentBalance = currentBalance;
        RequiredAmount = requiredAmount;
    }
    
    public InsufficientFundsException(string message, Exception innerException)
        : base(message, innerException)
    {
    }
}

// Usage
public void Withdraw(decimal amount)
{
    if (amount > Balance)
    {
        throw new InsufficientFundsException(Balance, amount);
    }
    
    Balance -= amount;
}

Best Practices:

1. Catch specific exceptions when possible
2. Don't catch and ignore exceptions silently
3. Use throw instead of throw ex to preserve stack trace
4. Include inner exceptions when creating new exceptions
5. Log exceptions before rethrowing
6. Use finally blocks for cleanup code
7. Don't throw exceptions for normal program flow

Properties are members that provide a flexible mechanism to read, write, or compute the values of private fields. They act as intermediaries between the outside world and the internal state of a class.

Basic Property Syntax:

public class Person
{
    private string _name;
    private int _age;
    
    // Traditional property with backing field
    public string Name
    {
        get { return _name; }
        set { _name = value; }
    }
    
    // Auto-property (C# 3.0+)
    public int Age { get; set; }
    
    // Read-only auto-property
    public DateTime CreatedAt { get; } = DateTime.Now;
    
    // Property with validation
    public string Email
    {
        get => _email;
        set
        {
            if (string.IsNullOrEmpty(value) || !value.Contains("@"))
                throw new ArgumentException("Invalid email format");
            _email = value;
        }
    }
    private string _email;
}

Property Types:

1. Auto-Properties:

public class Product
{
    // Auto-property with getter and setter
    public string Name { get; set; }
    
    // Read-only auto-property
    public int Id { get; }
    
    // Auto-property with initializer
    public decimal Price { get; set; } = 0m;
    
    // Auto-property with different access modifiers
    public string Description { get; private set; }
}

2. Expression-Bodied Properties (C# 6.0+):

public class Rectangle
{
    public double Width { get; set; }
    public double Height { get; set; }
    
    // Expression-bodied property
    public double Area => Width * Height;
    
    // Expression-bodied property with getter/setter
    public double Perimeter
    {
        get => 2 * (Width + Height);
        set => Width = Height = value / 4; // Square
    }
}

3. Init-Only Properties (C# 9.0+):

public class User
{
    // Can only be set during object initialization
    public string FirstName { get; init; }
    public string LastName { get; init; }
    
    // Computed property
    public string FullName => $"{FirstName} {LastName}";
}

// Usage
var user = new User
{
    FirstName = "John",
    LastName = "Doe"
    // Cannot set FirstName after initialization
    // user.FirstName = "Jane"; // Compile error
};

Indexers: Indexers allow objects to be indexed like arrays, providing a way to access elements using square bracket notation.

Basic Indexer:

public class StringCollection
{
    private string[] _items = new string[10];
    
    // Indexer
    public string this[int index]
    {
        get
        {
            if (index < 0 || index >= _items.Length)
                throw new IndexOutOfRangeException();
            return _items[index];
        }
        set
        {
            if (index < 0 || index >= _items.Length)
                throw new IndexOutOfRangeException();
            _items[index] = value;
        }
    }
}

// Usage
StringCollection collection = new StringCollection();
collection[0] = "Hello";
collection[1] = "World";
Console.WriteLine(collection[0]); // "Hello"

Multi-dimensional Indexers:

public class Matrix
{
    private int[,] _matrix;
    
    public Matrix(int rows, int columns)
    {
        _matrix = new int[rows, columns];
    }
    
    // Multi-dimensional indexer
    public int this[int row, int column]
    {
        get => _matrix[row, column];
        set => _matrix[row, column] = value;
    }
}

// Usage
Matrix matrix = new Matrix(3, 3);
matrix[0, 0] = 1;
matrix[1, 1] = 2;

String-based Indexers:

public class Dictionary
{
    private Dictionary<string, string> _items = new();
    
    // String-based indexer
    public string this[string key]
    {
        get => _items.TryGetValue(key, out string value) ? value : null;
        set => _items[key] = value;
    }
}

// Usage
Dictionary dict = new Dictionary();
dict["name"] = "John";
dict["age"] = "30";
Console.WriteLine(dict["name"]); // "John"

Properties vs Fields:

public class Example
{
    // Field - direct access to memory
    public string FieldName;
    
    // Property - controlled access with logic
    private string _propertyName;
    public string PropertyName
    {
        get => _propertyName;
        set => _propertyName = value?.Trim();
    }
}

Key Differences:

• Fields: Direct memory access, no validation, no side effects
• Properties: Controlled access, validation, side effects, encapsulation

Best Practices:

1. Use properties for public data access
2. Use fields only for private implementation details
3. Use auto-properties when no validation is needed
4. Use expression-bodied properties for simple computations
5. Use init-only properties for immutable data
6. Validate input in property setters
7. Use indexers when your class represents a collection

The .NET ecosystem has evolved significantly, with different versions serving different purposes and platforms.

Historical Timeline:

• .NET Framework (2002): Original .NET platform for Windows
• .NET Core (2016): Cross-platform, open-source rewrite
• .NET 5+ (2020): Unified platform combining Framework and Core

Key Differences:

.NET Framework:

// .NET Framework - Windows only
// Uses System.Web for web applications
// Requires .NET Framework runtime installed
// Larger package size
// Limited cross-platform support

// Example: ASP.NET Web Forms (Framework only)
public partial class Default : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        // Framework-specific code
    }
}

.NET Core:

// .NET Core - Cross-platform
// Modern, lightweight, fast
// Self-contained deployments
// Better performance
// Docker-friendly

// Example: ASP.NET Core Web API
[ApiController]
[Route("api/[controller]")]
public class WeatherController : ControllerBase
{
    [HttpGet]
    public IEnumerable<WeatherForecast> Get()
    {
        // Core-specific code
        return Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            Date = DateTime.Now.AddDays(index),
            TemperatureC = Random.Shared.Next(-20, 55)
        });
    }
}

.NET 5+ (Unified):

// .NET 5+ - Best of both worlds
// Single platform for all scenarios
// Improved performance
// Modern language features
// Long-term support versions

// Example: Modern .NET 6+ Web API
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");
app.Run();

Migration Path:

// .NET Framework → .NET Core → .NET 5+
// 1. Update project file format
// 2. Replace Framework-specific APIs
// 3. Update dependencies
// 4. Test cross-platform compatibility

// Old .NET Framework project file
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <TargetFrameworkVersion>v4.8</TargetFrameworkVersion>
  </PropertyGroup>
</Project>

// New .NET 5+ project file
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>
</Project>

When to Use Each:

.NET Framework:

• Legacy Windows applications
• When you need Windows-specific features
• Existing applications that are difficult to migrate
• When you need specific Framework-only libraries

.NET Core:

• New cross-platform applications
• Microservices and containers
• High-performance scenarios
• Cloud-native applications

.NET 5+:

• All new development (recommended)
• Modern applications
• When you want the latest features
• Long-term support and updates

Performance Comparison:

// Benchmark results (approximate)
// .NET Framework: Baseline
// .NET Core: 2-3x faster
// .NET 5+: 3-4x faster
// .NET 6+: 4-5x faster

// Example: JSON serialization performance
var data = new { Name = "John", Age = 30 };
var json = JsonSerializer.Serialize(data); // Much faster in .NET 5+

Package Size Comparison:

.NET Framework: ~50MB (runtime)
.NET Core: ~30MB (runtime)
.NET 5+: ~25MB (runtime)
Self-contained: ~100MB+ (includes runtime)

API Differences:

// .NET Framework
using System.Web;
using System.Web.Mvc;

// .NET Core/5+
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.DependencyInjection;

// Configuration differences
// Framework: web.config, app.config
// Core/5+: appsettings.json, environment variables

Best Practices:

1. Use .NET 5+ for all new development
2. Migrate gradually from Framework to .NET 5+
3. Test thoroughly when migrating
4. Use self-contained deployments for containers
5. Leverage cross-platform benefits when possible
6. Keep dependencies updated for security and performance

Assemblies are the fundamental unit of deployment and versioning in .NET. They contain compiled code, metadata, and resources that make up a .NET application.

Namespaces are logical groupings of related types that help organize code and avoid naming conflicts.

Assemblies:

What is an Assembly:

• A compiled unit of code (usually a .dll or .exe file)
• Contains Intermediate Language (IL) code, metadata, and resources
• The smallest unit of deployment in .NET
• Has a unique identity (name, version, culture, public key)

Assembly Structure:

MyAssembly.dll
├── Assembly Manifest (metadata)
├── Type Metadata
├── IL Code
├── Resources (images, strings, etc.)
└── Security Information

Types of Assemblies:

// 1. Executable Assembly (.exe)
// Contains an entry point (Main method)
// Can be run directly

// 2. Library Assembly (.dll)
// Contains reusable code
// Cannot be run directly
// Referenced by other assemblies

// Example: Creating a library assembly
namespace MyLibrary
{
    public class Calculator
    {
        public int Add(int a, int b) => a + b;
        public int Multiply(int a, int b) => a * b;
    }
}

// Compile to: MyLibrary.dll

Assembly Manifest:

// Assembly information (in AssemblyInfo.cs or project file)
[assembly: AssemblyTitle("MyApplication")]
[assembly: AssemblyDescription("A sample application")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
[assembly: AssemblyCompany("MyCompany")]
[assembly: AssemblyProduct("MyProduct")]
[assembly: AssemblyCopyright("Copyright © 2024")]

Global Assembly Cache (GAC):

// GAC is a machine-wide cache for shared assemblies
// Only available in .NET Framework (not in .NET Core/5+)
// Used for system assemblies and shared libraries

// Installing to GAC (Framework only)
gacutil -i MyAssembly.dll

// Strong-named assemblies can be installed in GAC
[assembly: AssemblyKeyFile("MyKey.snk")]

Namespaces:

What is a Namespace:

• A logical grouping of related types
• Helps avoid naming conflicts
• Provides a hierarchical organization
• Similar to folders in a file system

Namespace Declaration:

// Single namespace
namespace MyCompany.MyProject
{
    public class User { }
    public class Product { }
}

// Multiple namespaces in same file
namespace MyCompany.MyProject.Data
{
    public class UserRepository { }
}

namespace MyCompany.MyProject.Services
{
    public class UserService { }
}

// Nested namespaces
namespace MyCompany
{
    namespace MyProject
    {
        namespace Data
        {
            public class UserRepository { }
        }
    }
}

Using Namespaces:

// Fully qualified name
MyCompany.MyProject.User user = new MyCompany.MyProject.User();

// Using directive
using MyCompany.MyProject;
User user = new User();

// Using alias
using Data = MyCompany.MyProject.Data;
Data.UserRepository repo = new Data.UserRepository();

// Global using (C# 10+)
global using System;
global using System.Collections.Generic;

Assembly vs Namespace Relationship:

// One assembly can contain multiple namespaces
// MyLibrary.dll contains:
namespace MyCompany.Data
{
    public class UserRepository { }
}

namespace MyCompany.Services
{
    public class UserService { }
}

// Multiple assemblies can contain the same namespace
// MyLibrary1.dll and MyLibrary2.dll both contain:
namespace MyCompany.Common
{
    // Different types in each assembly
}

Assembly Loading:

// Load assembly dynamically
Assembly assembly = Assembly.LoadFrom("MyLibrary.dll");
Type type = assembly.GetType("MyCompany.MyClass");
object instance = Activator.CreateInstance(type);

// Get all types in assembly
Assembly currentAssembly = Assembly.GetExecutingAssembly();
Type[] types = currentAssembly.GetTypes();

// Get assembly from type
Assembly userAssembly = typeof(User).Assembly;

Best Practices:

Assemblies:

1. Keep assemblies focused - one responsibility per assembly
2. Use strong naming for shared libraries
3. Version your assemblies properly
4. Minimize assembly dependencies to reduce complexity
5. Use assembly attributes for metadata

Namespaces:

1. Follow naming conventions - Company.Project.Feature
2. Keep namespaces shallow - avoid deep nesting
3. Use meaningful names that describe the purpose
4. Group related types together
5. Avoid namespace conflicts with well-known libraries

Example Project Structure:

MyProject/
├── MyProject.Core/           (Assembly)
│   ├── Models/              (Namespace)
│   │   ├── User.cs
│   │   └── Product.cs
│   └── Interfaces/          (Namespace)
│       └── IRepository.cs
├── MyProject.Data/          (Assembly)
│   └── Repositories/        (Namespace)
│       └── UserRepository.cs
└── MyProject.Web/           (Assembly)
    └── Controllers/         (Namespace)
        └── UserController.cs

Lambda Expressions are anonymous functions that allow you to write inline code blocks that can be passed as arguments to methods or assigned to variables. They provide a concise way to represent delegates or expression trees.

Basic Lambda Syntax:

// Lambda expression syntax: (parameters) => expression
// Simple lambda
Func<int, int> square = x => x * x;
int result = square(5); // 25

// Lambda with multiple parameters
Func<int, int, int> add = (x, y) => x + y;
int sum = add(3, 4); // 7

// Lambda with no parameters
Func<string> getMessage = () => "Hello World";
string message = getMessage(); // "Hello World"

Lambda vs Anonymous Methods:

// Anonymous method (C# 2.0)
Func<int, int> oldWay = delegate(int x) { return x * x; };

// Lambda expression (C# 3.0+) - more concise
Func<int, int> newWay = x => x * x;

// Both do the same thing, but lambda is cleaner

Lambda with LINQ:

List<int> numbers = new List<int> { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

// Using lambda with LINQ methods
var evenNumbers = numbers.Where(x => x % 2 == 0);
var doubled = numbers.Select(x => x * 2);
var sum = numbers.Aggregate((x, y) => x + y);

// Lambda with complex expressions
var result = numbers
    .Where(x => x > 5)
    .Select(x => x * x)
    .OrderByDescending(x => x);

Lambda with Events:

public class Button
{
    public event EventHandler Click;
    
    protected virtual void OnClick()
    {
        Click?.Invoke(this, EventArgs.Empty);
    }
}

// Using lambda with events
Button button = new Button();
button.Click += (sender, e) => Console.WriteLine("Button clicked!");
button.Click += (sender, e) => MessageBox.Show("Hello!");

Lambda with Action and Func:

// Action - no return value
Action<string> printMessage = message => Console.WriteLine(message);
printMessage("Hello"); // Prints "Hello"

// Action with multiple parameters
Action<string, int> printMessageWithCount = (msg, count) => 
    Console.WriteLine($"{msg} (Count: {count})");

// Func - with return value
Func<int, int, int> multiply = (x, y) => x * y;
int product = multiply(3, 4); // 12

// Func with different return types
Func<string, int> getLength = str => str.Length;
int length = getLength("Hello"); // 5

Lambda with Complex Logic:

// Lambda with multiple statements (use braces)
Func<int, int> complexOperation = x =>
{
    int temp = x * 2;
    if (temp > 10)
        return temp + 5;
    else
        return temp - 2;
};

// Lambda with local variables
Func<int, int> factorial = n =>
{
    int result = 1;
    for (int i = 1; i <= n; i++)
        result *= i;
    return result;
};

Lambda with Predicates:

// Predicate<T> - returns bool
Predicate<int> isEven = x => x % 2 == 0;
bool result = isEven(4); // true

// Using with List<T>.FindAll
List<int> numbers = new List<int> { 1, 2, 3, 4, 5, 6 };
var evenNumbers = numbers.FindAll(x => x % 2 == 0); // [2, 4, 6]

Lambda with Custom Delegates:

// Custom delegate
public delegate int MathOperation(int x, int y);

// Using lambda with custom delegate
MathOperation add = (x, y) => x + y;
MathOperation multiply = (x, y) => x * y;

int sum = add(5, 3); // 8
int product = multiply(5, 3); // 15

Lambda with Expression Trees:

using System.Linq.Expressions;

// Expression tree - represents code as data
Expression<Func<int, int, int>> expression = (x, y) => x + y;

// Can be compiled to executable code
Func<int, int, int> compiled = expression.Compile();
int result = compiled(3, 4); // 7

// Can be analyzed and modified
BinaryExpression body = (BinaryExpression)expression.Body;
ParameterExpression left = (ParameterExpression)body.Left;
ParameterExpression right = (ParameterExpression)body.Right;

Lambda with Closures:

// Lambda captures variables from outer scope
int multiplier = 10;
Func<int, int> multiplyByTen = x => x * multiplier;

int result = multiplyByTen(5); // 50

// Changing the captured variable affects the lambda
multiplier = 20;
int newResult = multiplyByTen(5); // 100

Lambda with Async/Await:

// Async lambda
Func<Task<string>> asyncLambda = async () =>
{
    await Task.Delay(1000);
    return "Async result";
};

// Using async lambda
string result = await asyncLambda();

When to Use Lambda Expressions:

1. LINQ operations - Where, Select, OrderBy, etc.
2. Event handlers - Simple event handling
3. Callback functions - Passing behavior as parameters
4. Functional programming - Map, filter, reduce operations
5. Short, simple operations - One-liner functions

When NOT to Use Lambda Expressions:

1. Complex logic - Use regular methods instead
2. Reusable code - Create named methods
3. Performance-critical code - Regular methods might be faster
4. Debugging - Harder to debug than named methods

Best Practices:

1. Keep lambdas simple - avoid complex logic
2. Use meaningful parameter names when possible
3. Consider readability - don't sacrifice clarity for brevity
4. Use parentheses for multiple parameters: (x, y) => x + y
5. Use braces for multiple statements: x => { /* multiple statements */ }

Threading allows your application to perform multiple operations concurrently, improving responsiveness and utilizing multiple CPU cores effectively.

Basic Threading Concepts:

Thread vs Process:

// Process: Complete application with its own memory space
// Thread: Unit of execution within a process
// A process can have multiple threads

// Creating a new thread
Thread newThread = new Thread(() =>
{
    Console.WriteLine("Running on background thread");
    Thread.Sleep(2000);
    Console.WriteLine("Background thread completed");
});

newThread.Start();
Console.WriteLine("Main thread continues...");

Thread Class:

public class ThreadExample
{
    public static void Main()
    {
        // Create and start a thread
        Thread workerThread = new Thread(DoWork);
        workerThread.Start();
        
        // Main thread continues
        for (int i = 0; i < 5; i++)
        {
            Console.WriteLine($"Main thread: {i}");
            Thread.Sleep(500);
        }
        
        // Wait for worker thread to complete
        workerThread.Join();
        Console.WriteLine("All threads completed");
    }
    
    static void DoWork()
    {
        for (int i = 0; i < 5; i++)
        {
            Console.WriteLine($"Worker thread: {i}");
            Thread.Sleep(300);
        }
    }
}

ThreadPool:

// ThreadPool manages a pool of worker threads
// More efficient than creating new threads manually
// Automatically manages thread lifecycle

public class ThreadPoolExample
{
    public static void Main()
    {
        // Queue work to ThreadPool
        ThreadPool.QueueUserWorkItem(DoWork, "Task 1");
        ThreadPool.QueueUserWorkItem(DoWork, "Task 2");
        ThreadPool.QueueUserWorkItem(DoWork, "Task 3");
        
        Console.WriteLine("Main thread continues...");
        Thread.Sleep(3000); // Wait for tasks to complete
    }
    
    static void DoWork(object state)
    {
        string taskName = (string)state;
        Console.WriteLine($"ThreadPool thread executing: {taskName}");
        Thread.Sleep(1000);
        Console.WriteLine($"Completed: {taskName}");
    }
}

Race Conditions:

// Race condition example
public class RaceConditionExample
{
    private static int counter = 0;
    
    public static void Main()
    {
        // Start multiple threads that modify shared data
        Thread[] threads = new Thread[5];
        
        for (int i = 0; i < 5; i++)
        {
            threads[i] = new Thread(IncrementCounter);
            threads[i].Start();
        }
        
        // Wait for all threads
        foreach (Thread thread in threads)
        {
            thread.Join();
        }
        
        Console.WriteLine($"Final counter value: {counter}");
        // Expected: 5000, Actual: varies due to race condition
    }
    
    static void IncrementCounter()
    {
        for (int i = 0; i < 1000; i++)
        {
            counter++; // Race condition here!
        }
    }
}

Thread Synchronization:

1. Lock Statement:

public class SynchronizedExample
{
    private static int counter = 0;
    private static readonly object lockObject = new object();
    
    public static void Main()
    {
        Thread[] threads = new Thread[5];
        
        for (int i = 0; i < 5; i++)
        {
            threads[i] = new Thread(IncrementCounterSafely);
            threads[i].Start();
        }
        
        foreach (Thread thread in threads)
        {
            thread.Join();
        }
        
        Console.WriteLine($"Final counter value: {counter}"); // Always 5000
    }
    
    static void IncrementCounterSafely()
    {
        for (int i = 0; i < 1000; i++)
        {
            lock (lockObject) // Thread-safe increment
            {
                counter++;
            }
        }
    }
}

2. Monitor Class:

public class MonitorExample
{
    private static readonly object lockObject = new object();
    
    public static void Main()
    {
        Thread thread1 = new Thread(DoWorkWithMonitor);
        Thread thread2 = new Thread(DoWorkWithMonitor);
        
        thread1.Start();
        thread2.Start();
        
        thread1.Join();
        thread2.Join();
    }
    
    static void DoWorkWithMonitor()
    {
        Monitor.Enter(lockObject);
        try
        {
            Console.WriteLine($"Thread {Thread.CurrentThread.ManagedThreadId} acquired lock");
            Thread.Sleep(2000);
        }
        finally
        {
            Monitor.Exit(lockObject);
            Console.WriteLine($"Thread {Thread.CurrentThread.ManagedThreadId} released lock");
        }
    }
}

3. Mutex:

public class MutexExample
{
    private static Mutex mutex = new Mutex();
    
    public static void Main()
    {
        Thread[] threads = new Thread[3];
        
        for (int i = 0; i < 3; i++)
        {
            threads[i] = new Thread(DoWorkWithMutex);
            threads[i].Start();
        }
        
        foreach (Thread thread in threads)
        {
            thread.Join();
        }
    }
    
    static void DoWorkWithMutex()
    {
        mutex.WaitOne(); // Acquire mutex
        try
        {
            Console.WriteLine($"Thread {Thread.CurrentThread.ManagedThreadId} in critical section");
            Thread.Sleep(1000);
        }
        finally
        {
            mutex.ReleaseMutex(); // Release mutex
        }
    }
}

Thread vs Task:

// Thread - lower level, more control
Thread thread = new Thread(() =>
{
    Console.WriteLine("Thread-based work");
});
thread.Start();

// Task - higher level, better for most scenarios
Task task = Task.Run(() =>
{
    Console.WriteLine("Task-based work");
});

// Task with return value
Task<int> taskWithResult = Task.Run(() =>
{
    Thread.Sleep(1000);
    return 42;
});

int result = await taskWithResult;
Console.WriteLine($"Result: {result}");

Thread Safety:

public class ThreadSafeCounter
{
    private int _count = 0;
    private readonly object _lock = new object();
    
    public int Count
    {
        get
        {
            lock (_lock)
            {
                return _count;
            }
        }
    }
    
    public void Increment()
    {
        lock (_lock)
        {
            _count++;
        }
    }
    
    public void Decrement()
    {
        lock (_lock)
        {
            _count--;
        }
    }
}

Best Practices:

1. Use Task instead of Thread for most scenarios
2. Avoid shared mutable state when possible
3. Use appropriate synchronization mechanisms
4. Don't lock on public objects or types
5. Keep critical sections short to avoid blocking
6. Use thread-safe collections when available
7. Avoid Thread.Sleep in production code
8. Use async/await for I/O operations

Common Threading Issues:

1. Race conditions - multiple threads accessing shared data
2. Deadlocks - threads waiting for each other indefinitely
3. Starvation - some threads never get CPU time
4. Context switching overhead - too many threads can hurt performance