
## Introduction

Modern C# can remove boilerplate, but concise code is only useful when it remains clear and safe.

This post focuses on practical feature usage in production.

## 1) Records for immutable data

```csharp
public record OrderDto(int Id, string CustomerName, decimal Total);
public readonly record struct Money(decimal Amount, string Currency);
```

Use records for DTOs and value objects where immutability and value equality are beneficial.

## 2) Pattern matching for clearer branching

```csharp
public string GetStatusMessage(Order order) => order.Status switch
{
    OrderStatus.Pending => "Your order is being processed.",
    OrderStatus.Shipped => $"Shipped on {order.ShippedDate:d}.",
    OrderStatus.Delivered => "Delivered!",
    OrderStatus.Cancelled => "This order was cancelled.",
    _ => "Unknown status."
};
```

Compared to nested `if/else`, this is easier to scan and extend.

## 3) Collection expressions (C# 12)

```csharp
List<string> statuses = ["Active", "Inactive", "Pending"];
```

Prefer this syntax for concise collection initialization.

## 4) Raw string literals for SQL/JSON/templates

```csharp
string query = """
    SELECT Id, Name, Email
    FROM Customers
    WHERE IsActive = 1
    ORDER BY Name
    """;
```

Great for readability when strings contain quotes/newlines.

## 5) Primary constructors: when to use and avoid

Primary constructors reduce boilerplate, especially in DI-heavy services.

```csharp
public class OrderService(IOrderRepository repo, ILogger<OrderService> logger)
{
    public async Task<Order?> GetByIdAsync(int id, CancellationToken ct)
    {
        logger.LogInformation("Fetching order {OrderId}", id);
        return await repo.GetByIdAsync(id, ct);
    }
}
```

### Important tradeoff

Primary constructor parameters are captured and can be reassigned inside the class body.

If you need strict `readonly` guarantees, constructor validation, or overloads, prefer a traditional constructor with private `readonly` fields.

```csharp
public class PriceCalculator
{
    private readonly decimal _taxRate;

    public PriceCalculator(decimal taxRate)
    {
        ArgumentOutOfRangeException.ThrowIfNegativeOrZero(taxRate);
        _taxRate = taxRate;
    }
}
```

## Decision guide

Use **primary constructor** when:

- class is simple
- dependency injection is straightforward
- no complex initialization required

Use **traditional constructor** when:

- you need guard clauses and transformations
- you require `readonly` field safety
- you need multiple constructor overloads

## Summary

Modern C# features are powerful, but they are tools, not goals. Choose the feature that improves clarity and correctness for your specific class design.


Use modern C# features like records, pattern matching, collection expressions, and primary constructors without sacrificing maintainability.

Modern C# Features That Improve Code Readability — Clean Code


## Introduction

Testing is not separate from clean code. Code that is hard to test is usually tightly coupled or unclear.

## 1) Design for testability

### Inject dependencies

```csharp
public class TrialService(TimeProvider clock)
{
    public bool IsTrialExpired(User user)
        => clock.GetUtcNow() > user.TrialEndDate;
}
```

Avoid direct static/global dependencies such as `DateTime.Now` in business logic.

## 2) Follow AAA structure

- Arrange
- Act
- Assert

```csharp
[Fact]
public void CalculateTotal_WithDiscount_ReturnsDiscountedPrice()
{
    // Arrange
    var items = new List<OrderItem>
    {
        new("Widget", 100m, 2),
        new("Gadget", 50m, 1)
    };
    var calculator = new PriceCalculator(0.10m);

    // Act
    decimal total = calculator.CalculateTotal(items);

    // Assert
    total.Should().Be(225m);
}
```

## 3) Use descriptive test names

Pattern: `MethodName_Condition_ExpectedResult`

Examples:

- `GetByIdAsync_OrderNotFound_ReturnsNull`
- `Validate_EmptyCustomerId_ThrowsValidationException`
- `PlaceOrderAsync_ValidRequest_SavesAndNotifies`

## 4) Test behavior, not implementation details

Avoid brittle tests tied to internal method calls.

- Good: verify output, state change, emitted event, HTTP response
- Bad: over-verifying private interaction chains

## 5) Keep tests deterministic

Sources of flakiness:

- current time
- random values
- network dependencies
- shared mutable state

Use fakes/stubs/test containers and isolate external systems.

## 6) Fast feedback strategy

A practical test pyramid for C# backends:

- many unit tests (fast)
- fewer integration tests (database/API boundaries)
- minimal end-to-end tests (critical user flows)

## Summary

Testability is a design outcome. If dependencies are explicit and methods are cohesive, your tests become simpler, faster, and more valuable.


Write cleaner C# code by designing for testability and focusing tests on behavior using AAA and descriptive naming.

C# Testing and Testability for Maintainable Systems — Clean Code


## Introduction

Code smells are warning signs, not bugs by themselves. They indicate design debt that will slow future changes.

This post covers high-impact smells and corresponding refactors.

## 1) Long method -> Extract method

If a method exceeds one concern or one abstraction level, split it.

```csharp
public async Task PlaceOrderAsync(OrderRequest request, CancellationToken ct)
{
    ValidateRequest(request);
    var total = CalculateTotal(request.Items);
    var order = await PersistOrderAsync(request.CustomerId, total, ct);
    await SendConfirmationAsync(order, ct);
}
```

## 2) Data clumps -> Parameter object

Repeated parameter groups should become a type.

```csharp
public record Address(string Line1, string City, string ZipCode);
public record CreateUserRequest(string FirstName, string LastName, string Email, Address Address);
```

This improves consistency and reduces call-site errors.

## 3) Primitive obsession -> Value objects

Domain concepts should not always be `string`/`int`.

```csharp
public readonly record struct OrderId(int Value);
public readonly record struct CustomerId(int Value);
```

Compiler-checked types prevent ID mix-ups.

## 4) Magic numbers -> Named constants

```csharp
private const decimal BulkOrderThreshold = 500m;
private const decimal BulkDiscountRate = 0.10m;

if (order.Total > BulkOrderThreshold)
{
    order.Discount = order.Total * BulkDiscountRate;
}
```

Named constants explain intent and centralize change.

## 5) Duplicate code -> Extract shared function

```csharp
public static string FormatFullName(string? firstName, string? lastName)
    => string.IsNullOrWhiteSpace(firstName) && string.IsNullOrWhiteSpace(lastName)
        ? "Unknown"
        : $"{firstName} {lastName}".Trim();
```

Removing duplication lowers bug probability and maintenance cost.

## 6) Nested conditionals -> Guard clauses

```csharp
public decimal GetDiscount(Customer customer)
{
    if (customer is null) return 0m;
    if (!customer.IsActive) return 0m;

    return customer.OrderCount > 10 ? 0.15m : 0.05m;
}
```

Flat logic is easier to reason about and test.

## 7) Repeated type switch -> Polymorphism

If you repeatedly switch on type/enum to choose behavior, move behavior into subtype implementations.

```csharp
public abstract class PriceRule
{
    public abstract decimal Apply(decimal total);
}

public class StandardPriceRule : PriceRule
{
    public override decimal Apply(decimal total) => total;
}

public class PremiumPriceRule : PriceRule
{
    public override decimal Apply(decimal total) => total * 0.9m;
}
```

## Refactor safely checklist

- Add or update tests first
- Refactor in small commits
- Keep behavior unchanged
- Rename with intention
- Remove dead code after migration

## Summary

Refactoring is continuous, not a one-time event. Focus on smells that block change speed: long methods, duplication, primitive obsession, and nested conditionals.


Identify common C# code smells and apply practical refactoring patterns to improve readability, safety, and maintainability.

C# Code Smells and Refactoring Patterns That Matter — Clean Code


## Introduction

Clean methods help locally; clean class design helps globally.

When classes are too large or tightly coupled, every change becomes risky. This post shows practical class design rules based on SOLID.

## 1) Single Responsibility Principle (SRP)

A class should have one reason to change.

### Bad: one class does everything

```csharp
public class OrderService
{
    public void PlaceOrder(Order order)
    {
        Validate(order);
        Save(order);
        SendNotification(order);
    }
}
```

### Better: split by responsibility

```csharp
public class OrderValidator
{
    public void Validate(Order order) { /* ... */ }
}

public class OrderRepository
{
    public Task SaveAsync(Order order, CancellationToken ct) => Task.CompletedTask;
}

public class OrderNotifier
{
    public Task NotifyAsync(Order order, CancellationToken ct) => Task.CompletedTask;
}

public class OrderService(
    OrderValidator validator,
    OrderRepository repository,
    OrderNotifier notifier)
{
    public async Task PlaceOrderAsync(Order order, CancellationToken ct)
    {
        validator.Validate(order);
        await repository.SaveAsync(order, ct);
        await notifier.NotifyAsync(order, ct);
    }
}
```

## 2) Depend on abstractions, not concretions

High-level classes should not instantiate low-level dependencies directly.

```csharp
// BAD
public class SqlReportRepository
{
    public async Task<ReportData> GetDataAsync(int id, CancellationToken ct)
    {
        return new ReportData("Monthly Sales");
    }
}

public class ReportGenerator
{
    private readonly SqlReportRepository _repository;

    public ReportGenerator()
    {
        _repository = new SqlReportRepository();
    }

    public async Task<Report> GenerateAsync(int id, CancellationToken ct)
    {
        var data = await _repository.GetDataAsync(id, ct);
        return BuildReport(data);
    }

    private static Report BuildReport(ReportData data) => new(data.Title);
}

// GOOD
public interface IReportRepository
{
    Task<ReportData> GetDataAsync(int id, CancellationToken ct);
}

public class ReportGenerator(IReportRepository repository)
{
    public async Task<Report> GenerateAsync(int id, CancellationToken ct)
    {
        var data = await repository.GetDataAsync(id, ct);
        return BuildReport(data);
    }

    private static Report BuildReport(ReportData data) => new(data.Title);
}
```

This makes the class easier to test and swap implementations.

## 3) Prefer composition over inheritance

Inheritance can create brittle hierarchies.

```csharp
// BAD
public class FlyMovement
{
    public void Move() => Console.WriteLine("Flying");
}

public class WalkMovement
{
    public void Move() => Console.WriteLine("Walking");
}

public class Animal
{
    private readonly FlyMovement _flyMovement;
    private readonly WalkMovement _walkMovement;
    private readonly string _type;

    public Animal(string type)
    {
        _type = type;
        _flyMovement = new FlyMovement();
        _walkMovement = new WalkMovement();
    }

    public void Move()
    {
        if (_type == "Bird")
        {
            _flyMovement.Move();
        }
        else if (_type == "Dog")
        {
            _walkMovement.Move();
        }
    }
}


// GOOD
public interface IMovementStrategy
{
    void Move();
}

public class FlyMovement : IMovementStrategy
{
    public void Move() => Console.WriteLine("Flying");
}

public class WalkMovement : IMovementStrategy
{
    public void Move() => Console.WriteLine("Walking");
}

public class Animal(IMovementStrategy movement)
{
    public void Move() => movement.Move();
}
```

You can change behavior by changing strategy, not by rewriting class trees.

## 4) Keep classes cohesive

A cohesive class has members that all support one purpose.

Warning signs:

- class has multiple groups of unrelated fields
- methods only use a small subset of fields
- class keeps growing with `#region` blocks

When these appear, extract classes.

## 5) Open/Closed principle in practice

Avoid repeated `if/switch` chains that must be edited for each new type.

```csharp
public abstract class Shape
{
    public abstract double CalculateArea();
}

public class Circle(double radius) : Shape
{
    public override double CalculateArea() => Math.PI * radius * radius;
}

public class Rectangle(double width, double height) : Shape
{
    public override double CalculateArea() => width * height;
}
```

New behavior is added by extension, not by changing old code.

## Summary

Strong class design reduces coupling and change risk. Start with SRP and dependency inversion; these two practices usually deliver immediate maintainability gains.


Learn how to apply SRP, dependency inversion, and composition in C# to build maintainable, extensible production services.

C# Class Design and SOLID Principles in Real Projects — Clean Code


## Introduction

Most readability issues in C# code come from two places:

1. weak naming
2. methods doing too many things

If you improve only these two areas, your code quality rises quickly.

## 1) Naming conventions that scale

### Use `intention-revealing` names

A good name explains purpose without comments.

```csharp
// BAD
int d; // elapsed days

// GOOD
int elapsedTimeInDays;
```

### Follow C# casing conventions

- `PascalCase`: classes, methods, properties, constants
- `camelCase`: local variables, method parameters
- `_camelCase`: private fields

```csharp
public class OrderService
{
    private readonly IOrderRepository _orderRepository;

    public async Task<Order?> GetOrderByIdAsync(int orderId, CancellationToken ct)
    {
        var order = await _orderRepository.GetByIdAsync(orderId, ct);
        return order;
    }
}
```

### Prefer domain words over abbreviations

```csharp
// BAD
var custMgr = new CM();

// GOOD
var customerManager = new CustomerManager();
```

### Boolean names should read like questions

Good booleans: `isActive`, `hasPermission`, `canExecute`.

## 2) Method design principles

### Keep methods small and single-purpose

If a method validates input, calculates data, writes to database, and sends email, it has multiple responsibilities.

```csharp
public async Task ProcessOrderAsync(OrderRequest request, CancellationToken ct)
{
    Validate(request);
    decimal total = CalculateTotal(request.Items);
    var order = await SaveOrderAsync(request.CustomerId, total, ct);
    await NotifyCustomerAsync(order, ct);
}
```

### Keep parameter count low

When a method needs many primitives, introduce a request object.

```csharp
public record CreateUserRequest(
    string FirstName,
    string LastName,
    string Email,
    string Phone,
    Address Address);

public Task CreateUserAsync(CreateUserRequest request, CancellationToken ct);
```

### Avoid boolean flag arguments

```csharp
// BAD
RenderPage(page, true);

// GOOD
RenderPageForPrinting(page);
RenderPageForScreen(page);
```

### Use guard clauses to reduce nesting

```csharp
// BAD
public decimal GetDiscount(Customer customer)
{
    decimal discount = 0m;

    if (customer != null)
    {
        if (customer.IsActive)
        {
            if (customer.OrderCount > 10)
            {
                discount = 0.15m;
            }
            else
            {
                discount = 0.05m;
            }
        }
    }

    return discount;
}

// GOOD
public decimal GetDiscount(Customer customer)
{
    if (customer is null) return 0m;
    if (!customer.IsActive) return 0m;

    return customer.OrderCount > 10 ? 0.15m : 0.05m;
}
```

### Avoid hidden side effects

Method names must match behavior.

```csharp
// BAD
public bool CheckPassword(string password)
{
    if (Encrypt(password) == _storedHash)
    {
        Session.Initialize(); // hidden side effect
        return true;
    }
    return false;
}

// BETTER
public bool IsPasswordValid(string password) => Encrypt(password) == _storedHash;
public void InitializeSession() => Session.Initialize();
```

## Common review questions

Before merging, ask:

- Can a new developer understand each name in 5 seconds?
- Does each method do one thing at one abstraction level?
- Are there flag arguments or too many parameters?
- Are there side effects not reflected by method names?

## Summary

Clear naming and focused methods are the highest-ROI clean-code improvements in C#. Start there, then move to class design and architecture.


Practical C# naming conventions and method design rules that improve readability and reduce bugs in production code.

C# Naming Conventions and Method Design — Clean Code


## Why this series?

Writing code that "works" is not enough in production systems. Clean code makes your C# codebase easier to:

- maintain
- debug
- onboard new developers
- change safely as business rules evolve

This series breaks clean-code practices into small, practical topics with examples you can apply immediately.

## Series index

1. **Naming and Method Design**  
   Focus: naming conventions, small methods, guard clauses, parameter objects, avoiding side effects.

2. **Class Design and SOLID in Real Projects**  
   Focus: SRP, dependency inversion, composition over inheritance, and cohesive classes.

3. **Error Handling and Defensive Coding in ASP.NET Core**  
   Focus: specific exceptions, logging, `ProblemDetails`, request validation, and immutability.

4. **Code Smells and Refactoring Patterns**  
   Focus: long methods, primitive obsession, data clumps, duplicated code, magic numbers.

5. **Testing for Maintainability**  
   Focus: testable architecture, AAA, naming conventions for tests, behavior-first testing.

6. **Modern C# Features for Cleaner Code**  
   Focus: records, pattern matching, collection expressions, raw string literals, and primary constructors.

## Quick checklist

Use this list during code reviews:

- Are names intention-revealing?
- Are methods doing one thing?
- Are classes cohesive with one reason to change?
- Are expected failures handled without exceptions-for-flow?
- Are API errors returned with a consistent structure?
- Are business concepts modeled as types instead of plain `string`/`int`?
- Is logic tested through behavior, not implementation details?

## Suggested reading order

- Newer developers: 1 -> 2 -> 3 -> 5 -> 4 -> 6
- Experienced developers modernizing legacy code: 4 -> 2 -> 3 -> 5 -> 6 -> 1

## Final note

You do not need to apply everything at once. Improve code incrementally: one method, one class, one refactor at a time.


Start here for a practical C# clean code series focused on naming, methods, SOLID, error handling, testing, and modern C# features.

C# Clean Code Roadmap: A Practical Guide to Production-Quality Code


## Table of Contents

1. [Why This Matters](#why-this-matters)
2. [Task vs ValueTask in One Minute](#task-vs-valuetask-in-one-minute)
3. [Three-Tier API Rule of Thumb](#three-tier-api-rule-of-thumb)
4. [Scenario 1: Cache-First Read (Use ValueTask in Service)](#scenario-1-cache-first-read-use-valuetask-in-service)
5. [Scenario 2: Always Network I/O (Use Task)](#scenario-2-always-network-io-use-task)
6. [Scenario 3: Fan-Out Aggregation (Use Task for Combinators)](#scenario-3-fan-out-aggregation-use-task-for-combinators)
7. [Common Mistakes and Fixes](#common-mistakes-and-fixes)
8. [Decision Checklist](#decision-checklist)
9. [Summary](#summary)

---

## Why This Matters

In C#, `Task<T>` is the default async return type. It is simple, flexible, and safe for most app code.

`ValueTask<T>` exists for performance-sensitive paths where methods complete synchronously very often (for example, cache hits or buffered reads). It can avoid per-call `Task` allocations on the fast path.

The key point: `ValueTask<T>` is not a replacement for `Task<T>`.

## Task vs ValueTask in One Minute

- `Task<T>`:

  - Reference type
  - Easy to compose (`Task.WhenAll`, `Task.WhenAny`)
  - Safe to await multiple times
  - Usually the best default

- `ValueTask<T>`:
  - Value type (`struct`)
  - Can avoid allocation when result is immediately available
  - Single-consumption by design (do not await the same instance twice)
  - Better for hot paths with frequent synchronous completion

## Three-Tier API

In a typical API tiering:

- Controller/API layer
- Service/business layer
- Data/repository layer

Use this mental model:

| Layer           | Default Choice              | Why                                                 |
| --------------- | --------------------------- | --------------------------------------------------- |
| Controller/API  | `Task<T>`                   | One call per request, simplicity is more important  |
| Service         | `Task<T>` or `ValueTask<T>` | Use `ValueTask<T>` only if sync fast path is common |
| Repository/Data | Usually `Task<T>`           | DB/HTTP/file I/O is usually truly async             |

## Scenario 1: Cache-First Read (Use ValueTask in Service)

This is the best case for `ValueTask<T>` in a three-tier API.

- Most reads are cache hits (synchronous)
- Cache miss falls back to repository async I/O
- Service can return `ValueTask<T>` to avoid allocations on hot cache hits

### Controller (API Layer)

```csharp
[ApiController]
[Route("api/products")]
public class ProductsController : ControllerBase
{
    private readonly ProductService _service;

    public ProductsController(ProductService service) => _service = service;

    [HttpGet("{id:int}")]
    public async Task<ActionResult<ProductDto>> GetById(int id, CancellationToken ct)
    {
        var product = await _service.GetByIdAsync(id, ct);
        return product is null ? NotFound() : Ok(product);
    }
}
```

Controller still returns `Task<ActionResult<T>>` for readability and consistency.

### Service (Business Layer)

```csharp
public sealed class ProductService
{
    private readonly IMemoryCache _cache;
    private readonly IProductRepository _repo;

    public ProductService(IMemoryCache cache, IProductRepository repo)
    {
        _cache = cache;
        _repo = repo;
    }

    // Good ValueTask use: high cache hit ratio means frequent sync completion.
    public async ValueTask<ProductDto?> GetByIdAsync(int id, CancellationToken ct)
    {
        string cacheKey = $"product:{id}";

        if (_cache.TryGetValue(cacheKey, out ProductDto? cached))
            return cached; // synchronous fast path, no Task allocation

        var product = await _repo.GetByIdAsync(id, ct);
        if (product is not null)
            _cache.Set(cacheKey, product, TimeSpan.FromMinutes(10));

        return product;
    }
}
```

### Repository (Data Layer)

```csharp
public interface IProductRepository
{
    Task<ProductDto?> GetByIdAsync(int id, CancellationToken ct);
}

public sealed class ProductRepository(AppDbContext db) : IProductRepository
{
    public async Task<ProductDto?> GetByIdAsync(int id, CancellationToken ct)
    {
        return await db.Products
            .Where(p => p.Id == id)
            .Select(p => new ProductDto(p.Id, p.Name, p.Price))
            .FirstOrDefaultAsync(ct);
    }
}
```

Repository stays `Task<T>` because database queries are real async I/O.

## Scenario 2: Always Network I/O (Use Task)

If every call goes to external HTTP/database/file I/O, `ValueTask<T>` usually provides no measurable benefit.

### Controller

```csharp
[HttpGet("{id:int}/shipping")]
public async Task<ActionResult<ShippingQuoteDto>> GetShippingQuote(int id, CancellationToken ct)
{
    var quote = await _service.GetShippingQuoteAsync(id, ct);
    return Ok(quote);
}
```

### Service

```csharp
public sealed class ShippingService(IShippingClient client)
{
    // Always network call -> Task<T> is the better default.
    public async Task<ShippingQuoteDto> GetShippingQuoteAsync(int orderId, CancellationToken ct)
    {
        return await client.GetQuoteAsync(orderId, ct);
    }
}
```

### Data/Client

```csharp
public interface IShippingClient
{
    Task<ShippingQuoteDto> GetQuoteAsync(int orderId, CancellationToken ct);
}

public sealed class ShippingClient(HttpClient http) : IShippingClient
{
    public async Task<ShippingQuoteDto> GetQuoteAsync(int orderId, CancellationToken ct)
    {
        using var response = await http.GetAsync($"/quotes/{orderId}", ct);
        response.EnsureSuccessStatusCode();

        var result = await response.Content.ReadFromJsonAsync<ShippingQuoteDto>(cancellationToken: ct);
        return result ?? throw new InvalidOperationException("Empty quote response");
    }
}
```

No synchronous fast path means no real `ValueTask<T>` advantage.

## Scenario 3: Fan-Out Aggregation (Use Task for Combinators)

If you need `Task.WhenAll`/`Task.WhenAny`, `Task<T>` is usually the cleanest choice.

### Controller

```csharp
[HttpGet("dashboard/{customerId:int}")]
public async Task<ActionResult<DashboardDto>> GetDashboard(int customerId, CancellationToken ct)
{
    var dashboard = await _service.BuildDashboardAsync(customerId, ct);
    return Ok(dashboard);
}
```

### Service

```csharp
public sealed class DashboardService(
    IOrderRepository orders,
    IInvoiceRepository invoices,
    IRecommendationClient recommendations)
{
    public async Task<DashboardDto> BuildDashboardAsync(int customerId, CancellationToken ct)
    {
        Task<IReadOnlyList<OrderDto>> ordersTask = orders.GetRecentAsync(customerId, ct);
        Task<IReadOnlyList<InvoiceDto>> invoicesTask = invoices.GetOpenAsync(customerId, ct);
        Task<IReadOnlyList<ProductDto>> recTask = recommendations.GetTopAsync(customerId, ct);

        await Task.WhenAll(ordersTask, invoicesTask, recTask);

        return new DashboardDto(
            await ordersTask,
            await invoicesTask,
            await recTask);
    }
}
```

### Repository/Client

```csharp
public interface IOrderRepository
{
    Task<IReadOnlyList<OrderDto>> GetRecentAsync(int customerId, CancellationToken ct);
}

public interface IInvoiceRepository
{
    Task<IReadOnlyList<InvoiceDto>> GetOpenAsync(int customerId, CancellationToken ct);
}

public interface IRecommendationClient
{
    Task<IReadOnlyList<ProductDto>> GetTopAsync(int customerId, CancellationToken ct);
}
```

You can convert `ValueTask<T>` using `.AsTask()`, but if combinators are central, returning `Task<T>` keeps code straightforward.

## Common Mistakes and Fixes

### Mistake 1: Replacing all `Task<T>` with `ValueTask<T>`

Wrong because methods that always suspend gain little and become harder to reason about. Also, below reasons are also can't just replace `Task<T>` to `ValutTask<T>`, for example cannot await it concurrently.

Fix: keep `Task<T>` as default; optimize only proven hot paths.

### Mistake 2: Awaiting the same `ValueTask<T>` twice

```csharp
ValueTask<int> vt = service.GetCountAsync(ct);
int a = await vt;
int b = await vt; // wrong
```

Fix:

```csharp
Task<int> t = service.GetCountAsync(ct).AsTask();
int a = await t;
int b = await t; // safe
```

### Mistake 3: Forcing `ValueTask<T>` in controllers

Controller actions are not usually hot loops; one task allocation per request is negligible compared to pipeline cost.

Fix: prefer `Task<ActionResult<T>>` for controller actions.

## Decision Checklist

Use `ValueTask<T>` only when all are true:

- Method frequently completes synchronously
- It is in a hot path (high call frequency)
- You measured allocation/GC pressure worth optimizing
- Callers can consume result immediately (single-await pattern)

Use `Task<T>` when any of these are true:

- Operation is almost always real async I/O
- You need `Task.WhenAll`/`Task.WhenAny` composition
- You need to await multiple times or pass work around
- Simplicity and maintainability are higher priority

## Summary

`Task<T>` is the right default for most three-tier API code.

`ValueTask<T>` is a targeted optimization tool for hot paths with frequent synchronous completion, especially in service-layer cache-aside flows.

Start with `Task<T>`, measure with profiling, then introduce `ValueTask<T>` only where it removes meaningful allocation overhead.


Understand when to use Task vs ValueTask in ASP.NET Core three-tier APIs, with practical examples for cache-heavy, always-I/O, and batch aggregation scenarios.

C# ValueTask vs Task in Three-Tier APIs — When to Use Each


# C# Primary Constructor vs Legacy Constructor for Dependency Injection

C# 12 introduced primary constructors for classes, making dependency injection (DI) more concise. This post compares the new pattern with the traditional constructor approach, and explains when to use each.

## Primary Constructor Syntax (C# 12+)

```csharp
public class OrderService(IOrderRepository repo, ILogger<OrderService> logger, IEmailSender emailSender)
{
	public void ProcessOrder()
	{
		logger.LogInformation("Processing order...");
		// ...
	}
}
```

**Pros:**
- Less boilerplate: parameters are available as properties.
- Cleaner for simple services.
- Great for record types and DTOs too.

**Cons:**
- Only available in C# 12+ (.NET 8+).
- No support for additional constructor logic (validation, field assignment, etc.).
- Not as familiar to all teams yet.

## Legacy Constructor DI Pattern

```csharp
public class OrderService
{
	private readonly IOrderRepository _repo;
	private readonly ILogger<OrderService> _logger;
	private readonly IEmailSender _emailSender;

	public OrderService(IOrderRepository repo, ILogger<OrderService> logger, IEmailSender emailSender)
	{
		_repo = repo;
		_logger = logger;
		_emailSender = emailSender;
		// Additional logic (validation, etc.)
	}

	public void ProcessOrder()
	{
		_logger.LogInformation("Processing order...");
		// ...
	}
}
```

**Pros:**
- Works in all C# versions.
- Allows custom logic in the constructor.
- Explicit field naming and assignment.

**Cons:**
- More boilerplate code.
- Slightly more verbose for simple cases.

## When to Use Each

| Use Primary Constructor | Use Legacy Constructor |
|------------------------|-----------------------|
| Simple services         | Need extra constructor logic |
| No custom validation    | Need compatibility with older C# |
| C# 12+ codebase         | Prefer explicit field naming |

**Tip:** For most enterprise projects, the legacy pattern is still more common, but primary constructors are great for new, simple services in modern codebases.

---
**References:**
- [Microsoft Docs: Primary Constructors](https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-12#primary-constructors)


Compare the new C# primary constructor syntax with the traditional constructor-based dependency injection pattern. Learn when to use each, with practical code examples.

C# Primary Constructor vs Legacy Constructor for Dependency Injection


# C# Testing with MSTest In-Depth

---

## MSTest — Test Framework

- **[TestMethod] — a test with no parameters**

  ```csharp
  [TestClass]
  public class CalculatorTests
  {
      [TestMethod]
      public void Add_TwoPositiveNumbers_ReturnsSum()
      {
          // Arrange
          var calculator = new Calculator();

          // Act
          int result = calculator.Add(3, 4);

          // Assert
          Assert.AreEqual(7, result);
      }
  }
  ```

- **[DataTestMethod] + [DataRow] — parameterized tests**

  ```csharp
  [TestClass]
  public class CalculatorTests
  {
      [DataTestMethod]
      [DataRow(1, 2, 3)]
      [DataRow(0, 0, 0)]
      [DataRow(-1, 1, 0)]
      [DataRow(int.MaxValue, 0, int.MaxValue)]
      public void Add_VariousInputs_ReturnsExpectedSum(int a, int b, int expected)
      {
          var calculator = new Calculator();
          int result = calculator.Add(a, b);
          Assert.AreEqual(expected, result);
      }
  }
  ```

- **[DynamicData] — complex or external test data**

  ```csharp
  public static IEnumerable<object[]> DiscountTestData =>
      new List<object[]>
      {
          new object[] { new Customer { OrderCount = 0, IsActive = true }, 0.00m },
          new object[] { new Customer { OrderCount = 5, IsActive = true }, 0.05m },
          new object[] { new Customer { OrderCount = 15, IsActive = true }, 0.15m },
          new object[] { new Customer { OrderCount = 15, IsActive = false }, 0.00m },
      };

  [TestClass]
  public class DiscountCalculatorTests
  {
      [DataTestMethod]
      [DynamicData(nameof(DiscountTestData), DynamicDataSourceType.Property)]
      public void GetDiscount_VariousCustomers_ReturnsExpectedRate(Customer customer, decimal expectedDiscount)
      {
          var calculator = new DiscountCalculator();
          decimal discount = calculator.GetDiscount(customer);
          Assert.AreEqual(expectedDiscount, discount);
      }
  }
  ```

- **[TestCategory] — organize tests by category**

  ```csharp
  [TestClass]
  public class EmailValidatorTests
  {
      [DataTestMethod]
      [DataRow("user@example.com", true)]
      [DataRow("user@sub.domain.com", true)]
      [DataRow("invalid", false)]
      [DataRow("@no-local.com", false)]
      [DataRow("", false)]
      [TestCategory("Validation")]
      public void IsValidEmail_VariousInputs_ReturnsExpected(string email, bool expected)
      {
          bool result = EmailValidator.IsValid(email);
          Assert.AreEqual(expected, result);
      }
  }
  ```

---

## MSTest Best Practices

- Always decorate test classes with `[TestClass]`.
- Use `[TestInitialize]` and `[TestCleanup]` for setup/teardown logic.
- Prefer `[DataTestMethod]` and `[DataRow]` for parameterized tests.
- Use `[ExpectedException]` for exception testing.
- Organize tests with `[TestCategory]` for filtering.

---

**References:**
- [Microsoft Docs: MSTest](https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-with-mstest)


Learn MSTest fundamentals, attributes, and patterns for robust unit testing in C# applications. Includes practical examples and best practices.

C# Testing with MSTest In-Depth


# C# Testing In-Depth

---

## xUnit — Test Framework

- **`[Fact]` — a test with no parameters**

  - ```csharp
    [Fact]
    public void Add_TwoPositiveNumbers_ReturnsSum()
    {
        // Arrange
        var calculator = new Calculator();

        // Act
        int result = calculator.Add(3, 4);

        // Assert
        Assert.Equal(7, result);
    }
    ```

- **`[Theory]` + `[InlineData]` — parameterized tests**

  - ```csharp
    [Theory]
    [InlineData(1, 2, 3)]
    [InlineData(0, 0, 0)]
    [InlineData(-1, 1, 0)]
    [InlineData(int.MaxValue, 0, int.MaxValue)]
    public void Add_VariousInputs_ReturnsExpectedSum(int a, int b, int expected)
    {
        var calculator = new Calculator();

        int result = calculator.Add(a, b);

        Assert.Equal(expected, result);
    }
    ```

- **`[Theory]` + `[MemberData]` — complex test data**

  - ```csharp
    public class DiscountCalculatorTests
    {
        public static IEnumerable<object[]> DiscountTestData =>
        [
            [new Customer { OrderCount = 0, IsActive = true }, 0.00m],
            [new Customer { OrderCount = 5, IsActive = true }, 0.05m],
            [new Customer { OrderCount = 15, IsActive = true }, 0.15m],
            [new Customer { OrderCount = 15, IsActive = false }, 0.00m],
        ];

        [Theory]
        [MemberData(nameof(DiscountTestData))]
        public void GetDiscount_VariousCustomers_ReturnsExpectedRate(
            Customer customer, decimal expectedDiscount)
        {
            var calculator = new DiscountCalculator();

            decimal discount = calculator.GetDiscount(customer);

            Assert.Equal(expectedDiscount, discount);
        }
    }
    ```

- **`[Theory]` + `[ClassData]` — reusable test data across test classes**

  - ```csharp
    public class ValidEmailTestData : IEnumerable<object[]>
    {
        public IEnumerator<object[]> GetEnumerator()
        {
            yield return ["user@example.com", true];
            yield return ["user@sub.domain.com", true];
            yield return ["invalid", false];
            yield return ["@no-local.com", false];
            yield return ["", false];
        }

        IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();
    }

    [Theory]
    [ClassData(typeof(ValidEmailTestData))]
    public void IsValidEmail_VariousInputs_ReturnsExpected(string email, bool expected)
    {
        bool result = EmailValidator.IsValid(email);
        Assert.Equal(expected, result);
    }
    ```

---

## AAA Pattern — Arrange, Act, Assert

- Every test should follow this structure — it makes tests readable and consistent
- ```csharp
  [Fact]
  public async Task PlaceOrderAsync_ValidRequest_CreatesOrderAndNotifies()
  {
      // Arrange — set up dependencies, inputs, and expected values
      var request = new CreateOrderRequest("cust-1", [new OrderItemRequest("SKU-1", 2, 50m)]);
      var mockRepo = new Mock<IOrderRepository>();
      var mockNotifier = new Mock<IOrderNotifier>();
      var service = new OrderService(mockRepo.Object, mockNotifier.Object);

      // Act — call the method under test
      var result = await service.PlaceOrderAsync(request, CancellationToken.None);

      // Assert — verify the outcome
      result.Should().NotBeNull();
      result.Total.Should().Be(100m);
      mockRepo.Verify(r => r.SaveAsync(It.IsAny<Order>(), It.IsAny<CancellationToken>()), Times.Once);
      mockNotifier.Verify(n => n.NotifyAsync(It.IsAny<Order>(), It.IsAny<CancellationToken>()), Times.Once);
  }
  ```

---

## Test Naming Convention

- **Pattern:** `MethodName_Condition_ExpectedResult`
- ```csharp
  // ✓ Clear and descriptive
  GetByIdAsync_OrderExists_ReturnsOrder()
  GetByIdAsync_OrderNotFound_ReturnsNull()
  GetByIdAsync_NegativeId_ThrowsArgumentException()
  PlaceOrderAsync_EmptyItems_ThrowsValidationException()
  CalculateDiscount_PremiumCustomer_Returns15Percent()
  IsValid_EmptyEmail_ReturnsFalse()

  // ✗ Bad names — unclear what's being tested
  Test1()
  TestOrder()
  ShouldWork()
  OrderServiceTest()
  ```

---

## Mocking with Moq

- **Setup return values**

  - ```csharp
    var mockRepo = new Mock<IOrderRepository>();

    // Setup a specific return value
    mockRepo
        .Setup(r => r.GetByIdAsync(1, It.IsAny<CancellationToken>()))
        .ReturnsAsync(new Order { Id = 1, Total = 99.99m });

    // Setup for any argument
    mockRepo
        .Setup(r => r.GetByIdAsync(It.IsAny<int>(), It.IsAny<CancellationToken>()))
        .ReturnsAsync((Order?)null);

    // Setup with argument matching
    mockRepo
        .Setup(r => r.GetByIdAsync(It.Is<int>(id => id > 0), It.IsAny<CancellationToken>()))
        .ReturnsAsync(new Order { Id = 1 });
    ```

- **Setup to throw exceptions**

  - ```csharp
    mockRepo
        .Setup(r => r.GetByIdAsync(-1, It.IsAny<CancellationToken>()))
        .ThrowsAsync(new ArgumentException("Invalid ID"));
    ```

- **Verify method calls**

  - ```csharp
    // Verify a method was called exactly once
    mockRepo.Verify(
        r => r.SaveAsync(It.IsAny<Order>(), It.IsAny<CancellationToken>()),
        Times.Once);

    // Verify never called
    mockNotifier.Verify(
        n => n.NotifyAsync(It.IsAny<Order>(), It.IsAny<CancellationToken>()),
        Times.Never);

    // Verify with specific argument
    mockRepo.Verify(
        r => r.SaveAsync(
            It.Is<Order>(o => o.Total == 100m),
            It.IsAny<CancellationToken>()),
        Times.Once);
    ```

- **Callback — capture arguments for inspection**

  - ```csharp
    Order? savedOrder = null;
    mockRepo
        .Setup(r => r.SaveAsync(It.IsAny<Order>(), It.IsAny<CancellationToken>()))
        .Callback<Order, CancellationToken>((order, ct) => savedOrder = order)
        .Returns(Task.CompletedTask);

    await service.PlaceOrderAsync(request, CancellationToken.None);

    savedOrder.Should().NotBeNull();
    savedOrder!.CustomerName.Should().Be("Alice");
    ```

- **`Mock.Of<T>()` — quick mock with no setup needed**
  - ```csharp
    // When you just need a mock that does nothing
    var service = new OrderService(
        mockRepo.Object,
        Mock.Of<ILogger<OrderService>>());
    ```

---

## Mocking with NSubstitute (Alternative)

- ```csharp
  // Create a substitute
  var repo = Substitute.For<IOrderRepository>();

  // Setup return value
  repo.GetByIdAsync(1, Arg.Any<CancellationToken>())
      .Returns(new Order { Id = 1, Total = 99.99m });

  // Use in tests
  var service = new OrderService(repo);
  var result = await service.GetByIdAsync(1, CancellationToken.None);

  // Verify
  await repo.Received(1).SaveAsync(Arg.Any<Order>(), Arg.Any<CancellationToken>());
  await repo.DidNotReceive().DeleteAsync(Arg.Any<Order>(), Arg.Any<CancellationToken>());
  ```

---

## FluentAssertions — Readable Assertions

- ```csharp
  // Basic assertions
  result.Should().NotBeNull();
  result.Should().Be(42);
  result.Should().BeGreaterThan(0);
  result.Should().BeInRange(1, 100);

  // String assertions
  name.Should().StartWith("John");
  name.Should().Contain("Doe");
  name.Should().NotBeNullOrWhiteSpace();
  name.Should().MatchRegex(@"^\w+@\w+\.\w+$");

  // Collection assertions
  orders.Should().HaveCount(3);
  orders.Should().ContainSingle(o => o.Id == 1);
  orders.Should().BeInAscendingOrder(o => o.CreatedAt);
  orders.Should().AllSatisfy(o => o.Total.Should().BePositive());
  orders.Should().NotContainNulls();

  // Object assertions
  result.Should().BeEquivalentTo(expected); // deep comparison
  result.Should().BeOfType<Order>();
  result.Should().BeAssignableTo<IEntity>();

  // Exception assertions
  var act = () => service.GetByIdAsync(-1, CancellationToken.None);
  await act.Should().ThrowAsync<ArgumentException>()
      .WithMessage("*Invalid*");

  // DateTime assertions
  order.CreatedAt.Should().BeCloseTo(DateTime.UtcNow, TimeSpan.FromSeconds(5));
  order.CreatedAt.Should().BeBefore(DateTime.UtcNow);

  // Execution time assertions
  var act = () => SlowOperation();
  act.ExecutionTime().Should().BeLessThan(TimeSpan.FromSeconds(2));
  ```

---

## Testing Async Code

- ```csharp
  [Fact]
  public async Task GetByIdAsync_OrderExists_ReturnsOrder()
  {
      // Arrange
      var mockRepo = new Mock<IOrderRepository>();
      mockRepo
          .Setup(r => r.GetByIdAsync(1, It.IsAny<CancellationToken>()))
          .ReturnsAsync(new Order { Id = 1, Total = 99.99m });

      var service = new OrderService(mockRepo.Object);

      // Act
      var result = await service.GetByIdAsync(1, CancellationToken.None);

      // Assert
      result.Should().NotBeNull();
      result!.Id.Should().Be(1);
  }

  // Testing that an async method throws
  [Fact]
  public async Task GetByIdAsync_NegativeId_ThrowsArgumentException()
  {
      var service = new OrderService(Mock.Of<IOrderRepository>());

      var act = () => service.GetByIdAsync(-1, CancellationToken.None);

      await act.Should().ThrowAsync<ArgumentOutOfRangeException>();
  }

  // Testing cancellation
  [Fact]
  public async Task ProcessAsync_CancellationRequested_ThrowsOperationCancelled()
  {
      var service = new OrderService(Mock.Of<IOrderRepository>());
      using var cts = new CancellationTokenSource();
      cts.Cancel();

      var act = () => service.ProcessAsync(cts.Token);

      await act.Should().ThrowAsync<OperationCanceledException>();
  }
  ```

---

## Integration Testing — `WebApplicationFactory`

- **Test the real HTTP pipeline with a real DI container — swap only what you need**
- ```csharp
  public class OrderApiTests : IClassFixture<WebApplicationFactory<Program>>
  {
      private readonly WebApplicationFactory<Program> _factory;

      public OrderApiTests(WebApplicationFactory<Program> factory)
      {
          _factory = factory.WithWebHostBuilder(builder =>
          {
              builder.ConfigureServices(services =>
              {
                  // Remove real database
                  var descriptor = services.SingleOrDefault(
                      d => d.ServiceType == typeof(DbContextOptions<AppDbContext>));
                  if (descriptor is not null)
                      services.Remove(descriptor);

                  // Add in-memory database
                  services.AddDbContext<AppDbContext>(options =>
                      options.UseInMemoryDatabase("TestDb"));
              });
          });
      }

      [Fact]
      public async Task GetById_OrderExists_ReturnsOkWithOrder()
      {
          // Seed test data
          using var scope = _factory.Services.CreateScope();
          var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
          db.Orders.Add(new Order { Id = 1, CustomerName = "Alice", Total = 99.99m });
          await db.SaveChangesAsync();

          // Act
          var client = _factory.CreateClient();
          var response = await client.GetAsync("/api/orders/1");

          // Assert
          response.StatusCode.Should().Be(HttpStatusCode.OK);
          var order = await response.Content.ReadFromJsonAsync<OrderDto>();
          order.Should().NotBeNull();
          order!.CustomerName.Should().Be("Alice");
      }

      [Fact]
      public async Task GetById_OrderNotFound_ReturnsNotFound()
      {
          var client = _factory.CreateClient();

          var response = await client.GetAsync("/api/orders/99999");

          response.StatusCode.Should().Be(HttpStatusCode.NotFound);
      }
  }
  ```

---

## Test Fixtures & Shared Context

- **`IClassFixture<T>` — shared context for all tests in a class**

  - ```csharp
    public class DatabaseFixture : IAsyncLifetime
    {
        public AppDbContext Db { get; private set; } = null!;

        public async Task InitializeAsync()
        {
            var options = new DbContextOptionsBuilder<AppDbContext>()
                .UseInMemoryDatabase(Guid.NewGuid().ToString())
                .Options;
            Db = new AppDbContext(options);
            await SeedTestDataAsync();
        }

        public async Task DisposeAsync() => await Db.DisposeAsync();

        private async Task SeedTestDataAsync()
        {
            Db.Orders.AddRange(
                new Order { Id = 1, CustomerName = "Alice", Total = 100m },
                new Order { Id = 2, CustomerName = "Bob", Total = 200m });
            await Db.SaveChangesAsync();
        }
    }

    public class OrderRepositoryTests(DatabaseFixture fixture)
        : IClassFixture<DatabaseFixture>
    {
        [Fact]
        public async Task GetByIdAsync_ExistingOrder_ReturnsOrder()
        {
            var repo = new OrderRepository(fixture.Db);

            var order = await repo.GetByIdAsync(1, CancellationToken.None);

            order.Should().NotBeNull();
            order!.CustomerName.Should().Be("Alice");
        }
    }
    ```

- **`ICollectionFixture<T>` — shared context across multiple test classes**

  - ```csharp
    [CollectionDefinition("Database")]
    public class DatabaseCollection : ICollectionFixture<DatabaseFixture> { }

    [Collection("Database")]
    public class OrderServiceTests(DatabaseFixture fixture)
    {
        // shares the same DatabaseFixture instance with other classes in this collection
    }
    ```

---

## Test Organization & Best Practices

| Practice                                         | Why                                                               |
| ------------------------------------------------ | ----------------------------------------------------------------- |
| **One assert per test** (ideally)                | Each test verifies one behavior — clear failure messages          |
| **Test behavior, not implementation**            | Tests survive refactoring; don't verify internal method calls     |
| **Don't test private methods**                   | Test via public API; if private logic is complex, extract a class |
| **No test interdependence**                      | Each test must pass in isolation; no shared mutable state         |
| **Use `CancellationToken.None`**                 | Explicit; tests don't rely on cancellation unless testing it      |
| **Name: `MethodName_Condition_Expected`**        | Self-documenting; tells you what failed without reading the test  |
| **Avoid `Thread.Sleep` in tests**                | Flaky; use `TaskCompletionSource` or fake time providers          |
| **Use `TimeProvider` instead of `DateTime.Now`** | Deterministic; test any point in time                             |

- **Testing time-dependent code**

  - ```csharp
    // Production code — uses injectable TimeProvider
    public class TrialService(TimeProvider clock)
    {
        public bool IsTrialExpired(User user)
            => clock.GetUtcNow() > user.TrialEndDate;
    }

    // Test — control the clock
    [Fact]
    public void IsTrialExpired_TrialEndsInFuture_ReturnsFalse()
    {
        var fakeTime = new FakeTimeProvider(
            new DateTimeOffset(2024, 6, 1, 0, 0, 0, TimeSpan.Zero));
        var service = new TrialService(fakeTime);
        var user = new User { TrialEndDate = new DateTimeOffset(2024, 12, 31, 0, 0, 0, TimeSpan.Zero) };

        bool result = service.IsTrialExpired(user);

        result.Should().BeFalse();
    }
    ```

---

## What to Test vs What Not to Test

| ✓ Test                         | ✗ Don't Test                                      |
| ------------------------------ | ------------------------------------------------- |
| Business logic and rules       | Framework code (ASP.NET Core, EF Core)            |
| Validation logic               | Getters/setters with no logic                     |
| Edge cases and boundary values | Third-party library internals                     |
| Error handling paths           | Configuration wiring (test via integration tests) |
| Complex algorithms             | Trivial code (constructors, simple mappings)      |
| Public API contracts           | Private implementation details                    |
| Custom middleware behavior     | Auto-generated code                               |

---

## Summary — Testing Checklist

| Topic                 | Key Takeaway                                                                  |
| --------------------- | ----------------------------------------------------------------------------- |
| **Framework**         | xUnit for tests, Moq/NSubstitute for mocking, FluentAssertions for assertions |
| **AAA Pattern**       | Arrange → Act → Assert in every test                                          |
| **Naming**            | `MethodName_Condition_ExpectedResult`                                         |
| **`[Fact]`**          | Single test case, no parameters                                               |
| **`[Theory]`**        | Parameterized tests with `[InlineData]`, `[MemberData]`, `[ClassData]`        |
| **Mocking**           | Mock interfaces; setup returns, verify calls, capture arguments               |
| **FluentAssertions**  | Readable assertions: `.Should().Be()`, `.HaveCount()`, `.ThrowAsync()`        |
| **Async testing**     | `async Task` test methods; `await act.Should().ThrowAsync<T>()`               |
| **Integration tests** | `WebApplicationFactory<Program>` with service overrides                       |
| **Fixtures**          | `IClassFixture<T>` for class-level shared context                             |
| **Time**              | Use `TimeProvider` / `FakeTimeProvider` instead of `DateTime.Now`             |
| **Coverage goal**     | Minimum 80% line coverage                                                     |


Master xUnit, Moq, FluentAssertions, and integration testing patterns for building robust, maintainable C# applications with comprehensive test coverage.

C# Testing In-Depth


## Table of Contents

1. [Introduction](#introduction)
2. [Define Enum with Power of Two](#define-enum-with-power-of-two)
3. [Define Enum with Bit Shift](#define-enum-with-bit-shift)
4. [Using the Enum Flags](#using-the-enum-flags)
5. [Conclusion](#conclusion)

## Introduction

A quick code snippet to show how to use enum flags by using the power of two. You
can define your enum and set the values as follows. This will make the
combined flag values unique.

## Define Enum with Power of Two

```
public enum MyType : uint {
		Undefined = 0,
		Type1 = 1,
		Type2 = 2,
		Type3 = 4,
		Type4 = 8,
		Type5 = 16
	}
```

## Define Enum with Bit Shift

Or you can use the bit shift if you don't want to count the numbers.

```
public enum MyType2 : uint {
		Undefined = 0,
		Type1 = 1,
		Type2 = 2 << 0,
		Type3 = 2 << 1,
		Type4 = 2 << 2,
		Type5 = 2 << 3
	}
```

## Using the Enum Flags

Following are a few ways to use this enum.

```
// set value
		var myvalue = MyType.Type1 | MyType.Type2;
		Console.WriteLine(myvalue);

		var myvalue2 = MyType2.Type1 | MyType2.Type2;
		Console.WriteLine(myvalue2);

		// check value
		if ((myvalue2 & MyType2.Type1) == MyType2.Type1) {
			Console.WriteLine("myvalue2 has Type1");
		}

		// check value
		if ((myvalue2 & MyType2.Type4) != MyType2.Type4) {
			Console.WriteLine("myvalue2 doesn't have type4");
		}
```

The above code result will be the following:

3
3
myvalue2 has Type1
myvalue2 doesn't have type4
myvalue2 has type4? False

## Conclusion

Using the `[Flags]` attribute and the power of two for enum values allows you to combine multiple enum values into a single variable and check for specific flags using bitwise operations.


A quick code snippet showing how to use C# enum flags with the power of two for defining combinable flag values.

How to Use C# Enum Flag


## Table of Contents

1. [Introduction](#introduction)
2. [Errors](#errors)
3. [Compilers](#compilers)
4. [Roslyn](#roslyn)
5. [NuGet Packages](#nuget-packages)
6. [WebConfig](#webconfig)
7. [Conclusion](#conclusion)
8. [References](#references)

## Introduction

You might have seen something like the following: your ASP.NET MVC solution builds fine but you get a compiler error when deploying to a local IIS site or a cloud web server. You know you have C# 6 or higher in your application, but you're not sure why it causes a compile error during runtime. I had to spend some time figuring out what was happening in my case, so I've documented what I found here to hopefully help someone else.

## Errors

```
Microsoft (R) Visual C# Compiler version 4.7.2556.0
for C# 5
Copyright (C) Microsoft Corporation. All rights reserved.

This compiler is provided as part of the Microsoft (R) .NET Framework, but only supports language versions up to C# 5, which is no longer the latest version. For compilers that support newer versions of the C# programming language, see http://go.microsoft.com/fwlink/?LinkID=533240

warning CS2008: No source files specified
error CS1541: Invalid reference option: 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET
        Files\root\442dd867\' -- cannot reference directories
error CS1562: Outputs without source must have the /out option specified
```

## Compilers

It is confusing, but .NET development has several different .NET compilers. The compiler is `csc.exe`, but there are different versions:

  - .NET Framework's `csc.exe`

    - For example, .NET 4.6 is located here:
`C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe`

  - Visual Studio's `csc.exe`

    - Visual Studio 2013 is located here:
`C:\Program Files (x86)\MSBuild\12.0\Bin\csc.exe`

    - Visual Studio 2015 is located here:
`C:\Program Files (x86)\MSBuild\14.0\Bin\csc.exe`

  - Roslyn's `csc.exe` (example below uses version 1.0.0)

    - Roslyn inside application bin folder, for example:
`/bin/roslyn/csc.exe`

So there are multiple compilers in different locations, and unfortunately, the versions of `csc.exe` are different. If they were all the same version, I don't think I would see the error of compiling C# 6 code using a C# 5 compiler.

In summary, the following are the different versions when I checked:

  - .NET Framework's csc.exe - version 4.7.2556.0

  - Visual Studio 2013 - version 12.0.21005.1

  - Visual Studio 2015 - version 1.3.1.60616

  - Roslyn (1.0.0) - version 1.0.0.50618

```
C:\>"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe"
Microsoft (R) Visual C# Compiler version 4.7.2556.0
for C# 5
Copyright (C) Microsoft Corporation. All rights reserved.

This compiler is provided as part of the Microsoft (R) .NET Framework, but only supports language versions up to C# 5, which is no longer the latest version. For compilers that support newer versions of the C# programming language, see http://go.microsoft.com/fwlink/?LinkID=533240

warning CS2008: No source files specified
error CS1562: Outputs without source must have the /out option specified

C:\>"C:\Program Files (x86)\MSBuild\12.0\Bin\csc.exe"
Microsoft (R) Visual C# Compiler version 12.0.21005.1
for C# 5
Copyright (C) Microsoft Corporation. All rights reserved.

warning CS2008: No source files specified
error CS1562: Outputs without source must have the /out option specified

C:\>"C:\Program Files (x86)\MSBuild\14.0\Bin\csc.exe"
Microsoft (R) Visual C# Compiler version 1.3.1.60616
Copyright (C) Microsoft Corporation. All rights reserved.

warning CS2008: No source files specified.
error CS1562: Outputs without source must have the /out option specified

C:\>"C:\projects\WebApplication1\WebApplication1\bin\roslyn\csc.exe"
Microsoft (R) Visual C# Compiler version 1.0.0.50618
Copyright (C) Microsoft Corporation. All rights reserved.

warning CS2008: No source files specified.
error CS1562: Outputs without source must have the /out option specified
```

That's why when I build the solution with Visual Studio 2015, it works fine because it uses a different `csc.exe`, but errors sometimes appear when deploying to local IIS or the cloud. Also, ASP.NET MVC Razor uses a different compiler than C#. For example, if you have the following code, with a target framework of 4.6 and you're not using Roslyn, it will build fine but you'll see a compiler error when deploying locally.

```
@model WebApplication1.Models.MyModel
@if (string.IsNullOrWhiteSpace(Model.Test?.ToLower()))
{

}
```

## Roslyn

It looks like things are moving toward using `Roslyn`, so make sure these two NuGet packages are available in your solution: `Microsoft.CodeDom.Providers.DotNetCompilerPlatform` and `Microsoft.Net.Compilers`. Also, make sure the web.config changes are applied. Roslyn should be able to determine what version is appropriate for your solution.

It should be simple — just add the following NuGet packages. But make sure the web.config is updated. Sometimes I've had the issue where the web.config is updated locally but the IIS site's web.config is not updated, so it ends up not using Roslyn and instead using the .NET Framework's `csc.exe` compiler.

### NuGet Packages

1. Microsoft.CodeDom.Providers.DotNetCompilerPlatform

2. Microsoft.Net.Compilers

### WebConfig

```






```

## Conclusion

When deploying ASP.NET MVC applications that use C# 6 or later features, you may encounter compiler errors because the default .NET Framework `csc.exe` only supports up to C# 5. The solution is to install the Roslyn NuGet packages (`Microsoft.CodeDom.Providers.DotNetCompilerPlatform` and `Microsoft.Net.Compilers`) and ensure the web.config is properly updated to use Roslyn as the compiler.

## References

  - Command-line build with csc.exe

  - How to add dynamic compilation to your C# projects?

  - Github - roslyn

  - Removing roslyn from ASP.NET 4.5.2 project template

  - Publish website without roslyn


.NET Compiler Roslyn


## Table of Contents

1. [Introduction](#introduction)
2. [RSS Feeds](#rss-feeds)
3. [Forums](#forums)
4. [Other Resources](#other-resources)
5. [Conclusion](#conclusion)

## Introduction

The following are a few resources you can use to learn .NET.

## RSS Feeds

1. http://www.asp.net

2. https://blogs.msdn.microsoft.com

3. http://sxp.microsoft.com

4. https://channel9.msdn.com

## Forums

- http://forums.dotnetfoundation.org

## Other Resources

- channel9.msdn.com

- gitter.im

- dotnet.github.io

- blogs.msdn.microsoft.com

## Conclusion

These resources provide a solid starting point for learning .NET. From official Microsoft blogs and RSS feeds to community forums, you'll find plenty of material to deepen your understanding of the .NET ecosystem.


A curated list of resources to learn .NET, including RSS feeds, forums, and other useful links.

.NET

Subscribe for Updates