DEV Community: Morteza Jangjoo

Building Resilient .NET Applications with Polly

Morteza Jangjoo — Sat, 27 Dec 2025 04:31:00 +0000

Retry and Circuit Breaker Patterns Explained with Practical Examples

Modern applications rarely live in isolation. They constantly communicate with databases, third-party APIs, microservices, and cloud resources.
Because of this, failure is not an exception — it is an expectation.

Transient network issues, temporary service outages, or brief timeouts can easily break an otherwise well-designed system if resilience is not considered.

In this article, we will explore:

What resilience means in software systems
Common resilience patterns
How to implement Retry and Circuit Breaker patterns using Polly in .NET

What Is Resilience in Software Systems?

Resilience is the ability of an application to:

Handle failures gracefully
Recover automatically from transient issues
Maintain availability and responsiveness

Instead of crashing or blocking users when something goes wrong, a resilient system adapts and continues operating.

Think of resilience mechanisms as safety nets — they catch your application when things inevitably fail.

Understanding Transient Failures

A transient failure is a temporary issue that usually resolves itself after a short period of time.

Common examples include:

Temporary network glitches
API timeouts
Short-lived database connection failures
Cloud service throttling

These failures should not be treated as permanent errors.
Retrying the operation after a short delay often succeeds.

The Retry Pattern

What Is the Retry Pattern?

The Retry Pattern automatically re-executes a failed operation a limited number of times before giving up.

When Should You Use Retry?

Network calls
External APIs
Message queues
Cloud resources

When NOT to Use Retry?

Validation errors
Authentication failures
Business rule violations

Retry Example with Polly

var retryPolicy = Policy
    .Handle<HttpRequestException>()
    .WaitAndRetryAsync(
        retryCount: 3,
        sleepDurationProvider: attempt => TimeSpan.FromSeconds(2),
        onRetry: (exception, timeSpan, retryCount, context) =>
        {
            Console.WriteLine($"Retry {retryCount} after {timeSpan.TotalSeconds}s");
        });

What this does:

Retries the request up to 3 times
Waits 2 seconds between retries
Only retries when a HttpRequestException occurs

This approach significantly increases success rates for transient failures without impacting user experience.

The Circuit Breaker Pattern

The Problem Circuit Breaker Solves

Imagine calling a third-party service that is completely down:

Requests keep failing
Threads remain blocked
System resources are exhausted
The failure cascades through your system

This is how small failures turn into system-wide outages.

What Is a Circuit Breaker?

A Circuit Breaker prevents an application from executing operations that are likely to fail.

It works similarly to an electrical circuit breaker:

Detects repeated failures
Stops sending requests temporarily
Allows the system to recover

Circuit Breaker States

Closed
Requests flow normally.
Open
Requests are immediately rejected (fail-fast).
Half-Open
A limited number of test requests are allowed to check recovery.

Circuit Breaker Example with Polly

var circuitBreakerPolicy = Policy
    .Handle<HttpRequestException>()
    .CircuitBreakerAsync(
        exceptionsAllowedBeforeBreaking: 5,
        durationOfBreak: TimeSpan.FromSeconds(30),
        onBreak: (exception, duration) =>
        {
            Console.WriteLine("Circuit opened");
        },
        onReset: () =>
        {
            Console.WriteLine("Circuit closed");
        },
        onHalfOpen: () =>
        {
            Console.WriteLine("Circuit half-open");
        });

What this does:

Opens the circuit after 5 consecutive failures
Blocks requests for 30 seconds
Automatically attempts recovery

Combining Retry and Circuit Breaker

Using Retry alone can overload a failing service.
Using Circuit Breaker alone can be overly aggressive.

The real power comes from combining them.

var resiliencePolicy = Policy.WrapAsync(
    retryPolicy,
    circuitBreakerPolicy
);

Execution Example

await resiliencePolicy.ExecuteAsync(async () =>
{
    var response = await httpClient.GetAsync("https://external-api.com/data");
    response.EnsureSuccessStatusCode();
});

This setup ensures:

Transient failures are retried
Persistent failures trigger circuit breaking
System stability is preserved

Why Polly?

Polly is the de-facto resilience library in the .NET ecosystem because:

Fluent and expressive API
Supports async and sync operations
Easily integrates with HttpClientFactory
Widely used in production systems

Supported patterns include:

Retry
Circuit Breaker
Timeout
Fallback
Bulkhead Isolation

Real-World Use Cases

Polly is especially useful for:

Microservices communication
Financial and trading systems
Cloud-native applications
API gateways
SignalR and real-time systems

Any place where IO or remote calls exist, resilience should be a first-class concern.

Key Takeaways

Failures are inevitable in distributed systems
Resilience prevents small issues from becoming outages
Retry handles transient faults
Circuit Breaker protects system stability
Polly makes resilience practical and production-ready in .NET

Final Thoughts

Resilience is not an optional feature — it is a design requirement for modern applications.

By leveraging proven patterns and libraries like Polly, you can build systems that are:

Stable
Scalable
Fault-tolerant
User-friendly

If your application talks to the outside world, it must be resilient.

I’m Morteza Jangjoo and “Explaining things I wish someone had explained to me”

Why ILogger File Logging Fails in Production (and How to Fix It)

Morteza Jangjoo — Fri, 26 Dec 2025 05:38:16 +0000

Why ILogger File Logging Fails in Production (and How to Fix It)

Many .NET developers face a confusing issue:

Logging to file works perfectly in Development,
but no log file is created in Production.

This problem appears so often that it’s easy to think it’s a bug in .NET or ILogger.
In reality, it’s a misunderstanding of how logging works in ASP.NET Core.

In this article, we’ll explain:

Why this happens
What ILogger actually does (and doesn’t)
The most common production pitfalls
A correct, production-ready file logging setup

1. `ILogger` Does NOT Support File Logging

The first and most important fact:

Microsoft.Extensions.Logging has no built-in file logger

ILogger is just an abstraction.
It forwards logs to providers, such as:

Console
Debug
EventSource
Third-party providers (Serilog, NLog, etc.)

So this will never create a file by itself:

ILogger<MyService> logger;
logger.LogInformation("Hello World");

If file logging “worked” in Development, it was because:

You added a provider indirectly
Or your IDE showed Debug output
Or configuration was loaded only in Development

2. Why It Works in Development but Fails in Production

Here are the real reasons behind the issue.

Reason 1: Logging configured only in `appsettings.Development.json`

ASP.NET loads configuration in this order:

appsettings.json
appsettings.{Environment}.json
Environment variables

If file logging is configured only in:

appsettings.Development.json

Then in Production:

That config is never loaded
File logging simply doesn’t exist

Reason 2: Log directory does not exist

ASP.NET does not create directories automatically.

If you configure:

"path": "Logs/app.log"

But /Logs does not exist → no file is created

No exception. No warning. Just silence.

Reason 3: Missing write permissions (MOST COMMON)

In Production, your app usually runs as:

IIS App Pool identity
Docker container user
Linux service account

That user often cannot write to disk.

So file creation fails silently.

3. The Correct Way: Use a Real File Logger (Serilog)

Let’s fix everything properly.

4. Install Required Packages

dotnet add package Serilog.AspNetCore
dotnet add package Serilog.Sinks.File

5. Configure Serilog in `Program.cs`

using Serilog;

var builder = WebApplication.CreateBuilder(args);

builder.Host.UseSerilog((context, services, configuration) =>
{
    configuration
        .ReadFrom.Configuration(context.Configuration)
        .Enrich.FromLogContext();
});

var app = builder.Build();

app.MapGet("/", (ILogger<Program> logger) =>
{
    logger.LogInformation("Application started successfully");
    return "Hello World";
});

app.Run();

6. Configure Logging in `appsettings.json` (NOT Development-only)

{
  "Serilog": {
    "Using": [ "Serilog.Sinks.File" ],
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Microsoft": "Warning",
        "System": "Warning"
      }
    },
    "WriteTo": [
      {
        "Name": "File",
        "Args": {
          "path": "Logs/app-.log",
          "rollingInterval": "Day",
          "shared": true
        }
      }
    ]
  }
}

This configuration works in Development AND Production

7. Ensure the Log Folder Exists

Create it manually:

/Logs

Or programmatically:

Directory.CreateDirectory("Logs");

Best practice: create it before logging starts

8. Fix Production Permissions

IIS

Grant write access to:

IIS AppPool\YourAppPoolName

Linux

chmod -R 755 Logs
chown -R appuser:appuser Logs

Docker

Mount a writable volume:

volumes:
  - ./Logs:/app/Logs

9. Final Checklist (Production Safe)

Before blaming .NET, check this list:

Using Serilog / NLog
Logging config in appsettings.json
Log directory exists
App has write permissions
Not relying on Debug output

Conclusion

ILogger is not broken in Production.
It simply does exactly what it’s designed to do — nothing more.

File logging failures are almost always caused by:

Missing providers
Wrong configuration scope
File system permissions

Once you understand this, logging becomes predictable, stable, and production-safe.

I’m Morteza Jangjoo and “Explaining things I wish someone had explained to me”

Focus and Productivity for Developers

Morteza Jangjoo — Wed, 19 Nov 2025 11:30:00 +0000

Focus and Productivity for Developers: Practical Tips for 2025

Software development is mentally demanding. Distractions, long debugging sessions, and context switching can kill productivity.

Here’s a practical guide for developers to improve focus, efficiency, and overall output.

Master Deep Work

Deep Work (Cal Newport) = uninterrupted, focused sessions on cognitively demanding tasks.

How to implement:

Schedule 2–3 deep work blocks/day (60–90 min each)
Silence notifications: Slack, Teams, email
Create a quiet workspace
Use Pomodoro technique to sustain focus

Example: Allocate 90 minutes to implement a new feature or debug a complex issue without interruption.

Batch Tasks & Reduce Context Switching

Switching tasks constantly is a productivity killer.

Group similar tasks (emails, code reviews, testing)
Use task managers (Jira, Trello, ClickUp)
Prioritize high-impact coding early in the day

Tip: Check emails only twice a day instead of every 15 minutes.

Optimize Your Dev Environment

Minimalistic IDE setup (disable unused plugins)
Dual monitors: code + documentation
Dark mode to reduce eye strain
Keyboard shortcuts & code snippets for repetitive tasks

Example: VS Code with auto-formatting and linting reduces cognitive load.

Mindful Breaks & Pomodoro

Breaks prevent burnout. Example Pomodoro cycle:

25 min work → 5 min break
Every 4 cycles → 15–30 min long break

During breaks: stretch, meditate, or walk (avoid social media).

Reduce Cognitive Load

Write todos, notes, and bug fixes
Diagram architecture or logic flows
Break large tasks into smaller micro-tasks

Example: Before a new feature, draw a simple flowchart of function calls and data flow.

Automate Repetitive Tasks

Automation saves mental bandwidth:

Scripts for deployment & builds
Automated unit tests & CI/CD pipelines
Code generation tools where applicable

Example: Run tests automatically on commit instead of manually.

Maintain Physical & Mental Health

Focus = energy:

Sleep 7–8 hours/night
Exercise 20–30 min/day
Stay hydrated & eat healthily
Short mindfulness sessions

A 5-min walk between sessions boosts creativity and focus.

Avoid Multitasking

Multitasking kills productivity:

Single-task whenever possible
Pause notifications during deep work
Close unrelated browser tabs
Use ambient music tools like Focus@Will

Keep only IDE + documentation open during coding.

Track Productivity Metrics

Measure & improve workflow:

Tools: RescueTime, Toggl, Clockify
Track coding hours vs. context switching
Reflect weekly on high-energy tasks and distractions

Example: Schedule deep work when you naturally focus best.

Organize Knowledge

A knowledge base saves time:

Maintain code snippets & templates
Document solutions, design patterns, and architecture
Tools: Notion, Obsidian, OneNote

Weekly 30 min investment reduces hours spent searching later.

Final Thoughts

Productivity is about working smarter, not longer. Protect your focus.

Implement even a few strategies (deep work, task batching, mindful breaks, clean dev environment) to boost efficiency and reduce burnout.

“Your brain is your most valuable tool. Guard it like treasure.”

Domain-Driven Design (DDD)

Morteza Jangjoo — Tue, 18 Nov 2025 11:30:00 +0000

Domain-Driven Design (DDD): A Practical Guide for Real-World .NET Developers

Domain-Driven Design (DDD) remains one of the most effective approaches for building complex, long-living software systems. While frameworks and technologies change, business complexity never goes away — and DDD is exactly designed to manage that complexity.

This article gives you a clear, practical, modern introduction to DDD, focusing on how real teams use it today, especially with .NET, Clean Architecture, and Microservices.

What Is Domain-Driven Design?

DDD is an approach to software development that focuses on:

Understanding the core business domain
Building a shared language between developers and domain experts
Structuring the system around domain models, not frameworks
Managing complexity by breaking the system into Bounded Contexts

DDD is not a framework. It is a way of thinking.

Why DDD Still Matters in 2025

1. Business complexity is growing

Systems today involve automation, real-time interactions, regulations, analytics, multi-team development — and DDD helps model this complexity.

2. Perfect fit for Microservices & Event-Driven Systems

Modern architectures such as:

Microservices
Clean Architecture
Event Sourcing
Message-driven workflows

… all originate from DDD principles.

3. Helps avoid “Big Ball of Mud”

Without DDD:

Entities become fat
Business rules distribute everywhere
Services depend heavily on each other
The domain becomes unmaintainable

DDD prevents this.

Key Building Blocks of DDD

Entities

Objects with identity, such as:
Order, User, Trade, Portfolio

public class Order
{
    public Guid Id { get; private set; }
    public decimal Amount { get; private set; }

    public void UpdateAmount(decimal amount)
    {
        if (amount <= 0) throw new Exception("Invalid amount");
        Amount = amount;
    }
}

Value Objects

Immutable objects defined only by value, not identity:
Money, Email, Range, Price

public record Money(decimal Value, string Currency);

Aggregates

Transactional consistency boundaries.
Example: Order aggregate contains items, payment rules, and domain logic.

Repositories

Abstract persistence layer:

public interface IOrderRepository
{
    Task<Order?> GetByIdAsync(Guid id);
    Task AddAsync(Order order);
}

Domain Events

Explicit events describing something meaningful in the domain:

public record OrderCreated(Guid OrderId) : IDomainEvent;

Bounded Contexts

Each sub-domain has its own model, logic, database, and language.

Examples:

Billing Context
Trading Context
Inventory Context

Bounded Contexts = the backbone of microservices.

When Should You Use DDD?

Use DDD if your project has:

✔ Complex business rules
✔ Multiple teams
✔ Long-term maintenance
✔ Highly dynamic domain
✔ Need for scalability and separation

Typical domains:

Finance & Trading
Banking
Insurance
Logistics
Healthcare
ERP systems

When NOT to Use DDD

If your app is:

Simple CRUD
A small website
A blog/CMS
Prototype or MVP
A simple admin panel

Then DDD adds unnecessary complexity.

DDD + Clean Architecture in .NET (Modern Approach)

Most .NET teams today apply DDD inside Clean Architecture:

/Domain
  Entities
  ValueObjects
  Events
/Application
  UseCases
  DTOs
  Interfaces
/Infrastructure
  EF Repositories
  DbContext
/API
  Controllers

Benefits:

Independent domain logic
Infrastructure replaceable
Testable business rules
Clear boundaries

Real-World Sample Project (Download)

The following ZIP is a complete DDD sample with:

Aggregates
Value Objects
Domain Events
Repositories
Clean Architecture structure
EF Core implementation

Download the sample project
ddd_sample.zip

You can open it directly in Rider/Visual Studio.

Final Thoughts

DDD is not about building “perfect layered code.”
It’s about:

Understanding the business
Modeling the domain
Creating clarity and boundaries
Keeping complexity under control

DDD is still one of the best ways to design enterprise-grade software — particularly in .NET systems that live for years and evolve with new features.

Python Inside .NET

Morteza Jangjoo — Mon, 17 Nov 2025 19:29:54 +0000

Running Python Inside .NET 9 — A Complete Guide Using Python.NET

Integrating Python with .NET unlocks a powerful hybrid environment where you can leverage Python’s rich ecosystem (AI, ML, data processing) directly inside a .NET application.
In this guide, you'll learn how to run Python code, import Python modules, and call Python functions inside a .NET 9 application using Python.NET — with full source code.

Why Use Python Inside .NET?

Reuse existing Python scripts or ML models
Access libraries such as NumPy, Pandas, Scikit-learn, etc.
Extend .NET applications with data science capabilities
No need for IPC or microservices — run Python inline

Prerequisites

Before starting:

1. Install Python

Python 3.10 or 3.11 recommended.

2. Install dependencies

pip install numpy

3. Create a .NET 9 Console Project

dotnet new console -n PyNetIntegration
cd PyNetIntegration

4. Install Python.NET package

dotnet add package Python.Runtime

How Python.NET Works

Python.NET embeds the CPython runtime directly inside your .NET application.

This means:

You can call Python code from C#
Import Python modules (even third-party)
Exchange objects between .NET ↔ Python
Run Python functions line-by-line or execute entire scripts

Example 1: Run Python Inline Code

`Program.cs`

using Python.Runtime;

class Program
{
    static void Main()
    {
        PythonEngine.Initialize();

        using (Py.GIL())
        {
            dynamic math = Py.Import("math");
            double result = math.sqrt(144);

            Console.WriteLine($"Python sqrt(144) = {result}");
        }

        PythonEngine.Shutdown();
    }
}

✔ Works instantly
✔ No Python files needed
✔ Calls CPython directly

Example 2: Import a Python Module (Custom .py File)

Create file: `/scripts/utils.py`

def add(a, b):
    return a + b

def multiply(a, b):
    return a * b

Updated `Program.cs`

using Python.Runtime;

class Program
{
    static void Main()
    {
        PythonEngine.Initialize();
        using (Py.GIL())
        {
            dynamic sys = Py.Import("sys");
            sys.path.append("scripts");

            dynamic utils = Py.Import("utils");
            Console.WriteLine(utils.add(10, 20));
            Console.WriteLine(utils.multiply(5, 4));
        }
        PythonEngine.Shutdown();
    }
}

Example 3: Using NumPy Inside .NET

using Python.Runtime;

class Program
{
    static void Main()
    {
        PythonEngine.Initialize();

        using (Py.GIL())
        {
            dynamic np = Py.Import("numpy");
            dynamic arr = np.array(new int[] { 1, 2, 3, 4 });
            dynamic squared = np.square(arr);

            Console.WriteLine(squared);
        }

        PythonEngine.Shutdown();
    }
}

Data Exchange: Python ↔ .NET

Passing .NET data to Python

var list = new List<int> { 1, 2, 3 };
dynamic npList = new PyList(list.Select(i => new PyInt(i)).ToArray());

Returning Python values to .NET

int x = (int)pyValue.As<int>();

Folder Structure (recommended)

PyNetIntegration/
│── Program.cs
│── PyNetIntegration.csproj
└── scripts/
    └── utils.py

When Should You Use Python.NET?

Use Python.NET when:

✓ You want to call Python inline
✓ You need NumPy/Pandas in your .NET app
✓ You need maximum speed (direct CPython runtime)

Avoid Python.NET when:

✗ You want full cross-platform runtime isolation
✗ You need Python and .NET to run separately → Use gRPC
✗ You're deploying to serverless (Azure Functions, AWS Lambda)

Full Source Code (Copy-paste ready)

Here is the full minimal project:

`PyNetIntegration.csproj`

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Python.Runtime" Version="3.0.1" />
  </ItemGroup>
</Project>

`Program.cs`

using Python.Runtime;

class Program
{
    static void Main()
    {
        PythonEngine.Initialize();
        using (Py.GIL())
        {
            dynamic math = Py.Import("math");
            Console.WriteLine(math.sqrt(169));
        }
        PythonEngine.Shutdown();
    }
}

Conclusion

Python.NET provides a powerful and direct way to run Python inside .NET applications.
With just a few lines of code, you can:

Embed Python
Run scripts
Load modules
Exchange data
Use scientific libraries

This hybrid approach is perfect for AI, ML, automation, financial analysis, or any system where both ecosystems shine together.

Real-Time Data Updates with .NET Core and Angular using SignalR

Morteza Jangjoo — Mon, 10 Nov 2025 07:30:00 +0000

Real-Time Data Updates with .NET Core and Angular using SignalR

Introduction

Modern web applications require real-time updates — whether it’s live dashboards, trading platforms, chat apps, or notifications.

Traditionally, HTTP polling was used to check for changes, but it’s inefficient and slow.

In this article, you’ll learn how to implement a real-time data update system using .NET Core (SignalR) and Angular, giving users a smooth, responsive experience.

What is SignalR?

SignalR is a real-time communication library for ASP.NET Core that enables bi-directional communication between server and client.

Key features:

Real-time communication (instant updates)
Automatic connection management
Fallback to older protocols if WebSockets are unavailable
Strongly-typed hubs with .NET Core

Architecture Overview


Client (Angular)
⬇️ ⬆️
SignalR Hub (.NET Core)
⬇
Database / API / External Data Source

The server listens for data updates.
When data changes, the server broadcasts messages to all connected clients.
The Angular client receives updates in real-time and updates the UI.

⚙️ Step 1: Create the .NET Core Backend

1.1 Create a new Web API project

dotnet new webapi -n RealtimeDemo
cd RealtimeDemo

1.2 Install SignalR

dotnet add package Microsoft.AspNetCore.SignalR

1.3 Create a SignalR Hub

Hubs/PriceHub.cs

using Microsoft.AspNetCore.SignalR;

namespace RealtimeDemo.Hubs
{
    public class PriceHub : Hub
    {
        public async Task SendPriceUpdate(string symbol, decimal price)
        {
            await Clients.All.SendAsync("ReceivePriceUpdate", symbol, price);
        }
    }
}

1.4 Register SignalR in Program.cs

using RealtimeDemo.Hubs;
using RealtimeDemo.Services;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddSignalR();
builder.Services.AddHostedService<PriceSimulator>();

var app = builder.Build();
app.MapControllers();
app.MapHub<PriceHub>("/priceHub");

app.Run();

Step 2: Simulate Real-Time Data

Services/PriceSimulator.cs

using Microsoft.AspNetCore.SignalR;
using RealtimeDemo.Hubs;
using System.Timers;

namespace RealtimeDemo.Services
{
    public class PriceSimulator : IHostedService
    {
        private readonly IHubContext<PriceHub> _hubContext;
        private System.Timers.Timer _timer = new(2000);
        private readonly Random _random = new();

        public PriceSimulator(IHubContext<PriceHub> hubContext)
        {
            _hubContext = hubContext;
        }

        public Task StartAsync(CancellationToken cancellationToken)
        {
            _timer.Elapsed += async (sender, args) =>
            {
                var price = Math.Round((decimal)(_random.NextDouble() * 100), 2);
                await _hubContext.Clients.All.SendAsync("ReceivePriceUpdate", "EUR/USD", price);
            };
            _timer.Start();
            return Task.CompletedTask;
        }

        public Task StopAsync(CancellationToken cancellationToken)
        {
            _timer.Stop();
            return Task.CompletedTask;
        }
    }
}

Step 3: Setup Angular Frontend

3.1 Install SignalR client

npm install @microsoft/signalr

3.2 Create a SignalR service

src/app/services/signalr.service.ts

import { Injectable } from '@angular/core';
import * as signalR from '@microsoft/signalr';

@Injectable({ providedIn: 'root' })
export class SignalRService {
  private hubConnection!: signalR.HubConnection;
  public latestPrice: number = 0;

  startConnection(): void {
    this.hubConnection = new signalR.HubConnectionBuilder()
      .withUrl('https://localhost:5001/priceHub')
      .build();

    this.hubConnection
      .start()
      .then(() => console.log('SignalR connection started'))
      .catch(err => console.error('Error connecting to SignalR', err));

    this.hubConnection.on('ReceivePriceUpdate', (symbol, price) => {
      this.latestPrice = price;
      console.log(`${symbol} => ${price}`);
    });
  }
}

3.3 Display real-time data in component

src/app/app.component.ts

import { Component, OnInit } from '@angular/core';
import { SignalRService } from './services/signalr.service';

@Component({
  selector: 'app-root',
  template: `
    <div class="container">
      <h1> Real-Time Price Updates</h1>
      <h2>EUR/USD: {{ signalRService.latestPrice | number:'1.2-2' }}</h2>
    </div>
  `,
  styles: [`
    .container { text-align: center; padding: 50px; font-family: Arial; }
  `]
})
export class AppComponent implements OnInit {
  constructor(public signalRService: SignalRService) {}

  ngOnInit(): void {
    this.signalRService.startConnection();
  }
}

Step 4: Run the Application

Start both backend and frontend:

dotnet run  # Backend
ng serve    # Frontend

Open the Angular app in your browser — prices update every 2 seconds in real-time.

Summary

Using SignalR with .NET Core and Angular, you can easily build real-time applications like:

Live trading dashboards
Collaborative apps (whiteboards, docs)
Notification systems
IoT monitoring dashboards

SignalR abstracts the complexity of real-time communication while Angular efficiently handles UI updates.

#dotnet #angular #signalr #realtime #webdev #csharp #frontend #backend

download sample code from github

I’m Morteza Jangjoo and “Explaining things I wish someone had explained to me”

Mastering the Options Pattern in .NET — Strongly Typed Configuration Made Simple

Morteza Jangjoo — Sun, 09 Nov 2025 19:13:12 +0000

When building modern applications with .NET, configuration management is one of the most critical design aspects.

Instead of spreading configuration keys like API URLs or SMTP credentials across your codebase, .NET provides a clean, strongly typed, and dependency-injection-friendly solution: the Options Pattern.

Let’s explore this pattern in detail and see how to use it properly in real-world applications.

What Is the Options Pattern?

The Options Pattern allows you to represent configuration settings as strongly typed classes that can be easily injected and validated.

Instead of calling Configuration["SomeKey"], you can map a JSON configuration section directly to a C# class.

Example Scenario — SMTP Settings

Here’s an example appsettings.json configuration:

{
  "SmtpSettings": {
    "Server": "smtp.gmail.com",
    "Port": 587,
    "Username": "myemail@gmail.com",
    "Password": "mypassword"
  }
}

Step 1 — Define a Strongly Typed Configuration Class

public class SmtpSettings
{
    public string Server { get; set; } = string.Empty;
    public int Port { get; set; }
    public string Username { get; set; } = string.Empty;
    public string Password { get; set; } = string.Empty;
}

Step 2 — Register Configuration in `Program.cs`

In .NET 6+:

var builder = WebApplication.CreateBuilder(args);

builder.Services.Configure<SmtpSettings>(
    builder.Configuration.GetSection("SmtpSettings")
);

var app = builder.Build();

Now your configuration is available through the DI system.

Step 3 — Access Configuration via Dependency Injection

There are three interfaces to access Options in .NET:

IOptions<T> — static, read once at startup
IOptionsSnapshot<T> — reloads per request (scoped)
IOptionsMonitor<T> — observes live changes (singleton)

Let’s break them down

`IOptions<T>` — Static Configuration

using Microsoft.Extensions.Options;

public class EmailService
{
    private readonly SmtpSettings _settings;

    public EmailService(IOptions<SmtpSettings> options)
    {
        _settings = options.Value;
    }

    public void SendEmail()
    {
        Console.WriteLine($"Using SMTP server: {_settings.Server}:{_settings.Port}");
    }
}

Best for static configuration that never changes during the app’s lifetime.

`IOptionsSnapshot<T>` — Per Request Reload

IOptionsSnapshot reloads values automatically for each web request, making it ideal for ASP.NET Core applications.

public class EmailController : ControllerBase
{
    private readonly SmtpSettings _settings;

    public EmailController(IOptionsSnapshot<SmtpSettings> options)
    {
        _settings = options.Value;
    }

    [HttpGet("send")]
    public IActionResult SendEmail()
    {
        return Ok($"SMTP Server: {_settings.Server}");
    }
}

Use this in web apps where configuration might change between requests.

`IOptionsMonitor<T>` — Real-time Change Notifications

IOptionsMonitor provides live reload and change notification support.

public class EmailBackgroundService
{
    private readonly IOptionsMonitor<SmtpSettings> _monitor;

    public EmailBackgroundService(IOptionsMonitor<SmtpSettings> monitor)
    {
        _monitor = monitor;

        _monitor.OnChange(settings =>
        {
            Console.WriteLine($"SMTP settings changed! New server: {settings.Server}");
        });
    }

    public void SendEmail()
    {
        var settings = _monitor.CurrentValue;
        Console.WriteLine($"Sending email via {settings.Server}");
    }
}

Best for background services or long-running processes that must react immediately to configuration updates.

Options Interface Comparison

Interface	Lifetime	Auto Reload	Ideal Use Case
`IOptions<T>`	Singleton	❌ No	Static configuration
`IOptionsSnapshot<T>`	Scoped	✅ Per Request	ASP.NET Core apps
`IOptionsMonitor<T>`	Singleton	✅ Real-time	Background jobs, daemons

Named Options — Multiple Configurations

You can manage multiple sets of configurations (for example, Gmail and Outlook) using named options:

builder.Services.Configure<SmtpSettings>("Gmail", builder.Configuration.GetSection("SmtpGmail"));
builder.Services.Configure<SmtpSettings>("Outlook", builder.Configuration.GetSection("SmtpOutlook"));

Then:

public class EmailService
{
    private readonly IOptionsSnapshot<SmtpSettings> _options;

    public EmailService(IOptionsSnapshot<SmtpSettings> options)
    {
        _options = options;
    }

    public void SendViaGmail()
    {
        var gmail = _options.Get("Gmail");
        Console.WriteLine($"Sending via Gmail: {gmail.Server}");
    }
}

Validating Options

It’s good practice to validate configuration values during startup.

builder.Services
    .AddOptions<SmtpSettings>()
    .Bind(builder.Configuration.GetSection("SmtpSettings"))
    .Validate(settings => settings.Port > 0, "Port must be greater than 0")
    .ValidateDataAnnotations()
    .ValidateOnStart();

This ensures invalid configuration will throw an exception at startup, not at runtime.

Benefits of Using the Options Pattern

Benefit	Description
Strongly Typed	Compile-time safety for configuration keys
DI Integration	Works naturally with .NET’s dependency injection
Supports Reload	`IOptionsMonitor` and `IOptionsSnapshot` can refresh automatically
Separation of Concerns	Keeps configuration separate from business logic
Testable	Easy to mock in unit tests

Best Practices

Prefer strongly typed options classes over raw Configuration access.
Use IOptionsSnapshot for web requests and IOptionsMonitor for background services.
Add validation using ValidateOnStart() and data annotations.
Don’t store secrets in appsettings.json — use User Secrets, Azure Key Vault, or environment variables.
Organize your configuration sections logically (one class per section).

Final Thoughts

The Options Pattern in .NET provides a robust, clean, and scalable approach to configuration management.
It simplifies how you handle settings, supports automatic reloads, and integrates perfectly with .NET’s dependency injection system.

Once you adopt it, configuration management becomes safer, more maintainable, and more professional.

download sample code from github

I’m Morteza Jangjoo and “Explaining things I wish someone had explained to me”

Mastering ILogger in .NET Core — Complete Logging Guide for Developers

Morteza Jangjoo — Sat, 08 Nov 2025 20:29:58 +0000

Understanding `ILogger` in .NET Core — A Complete Guide

Logging is an essential part of every modern application. It helps you understand what’s happening inside your system, debug problems faster, and monitor production environments effectively.

In .NET Core, logging is built-in through the ILogger interface, part of the Microsoft.Extensions.Logging namespace.

This powerful abstraction allows developers to log messages to multiple providers like Console, File, Seq, Elasticsearch, and more — all using a consistent API.

What is `ILogger`?

ILogger is the core logging interface in .NET Core that provides a unified way to write log messages.

It abstracts away the underlying implementation, so you can change the logging provider without touching your application logic.

public interface ILogger
{
    IDisposable BeginScope<TState>(TState state);
    bool IsEnabled(LogLevel logLevel);
    void Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception exception, Func<TState, Exception, string> formatter);
}

However, developers typically use extension methods like LogInformation(), LogWarning(), and LogError() instead of calling these methods directly.

🔹 Basic Usage in .NET Core

Logging in .NET Core is automatically registered in the Dependency Injection (DI) container.
When you create a new Web API project, it’s already wired up.

Here’s how to use it inside a controller:

using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Logging;

namespace LoggingDemo.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class WeatherController : ControllerBase
    {
        private readonly ILogger<WeatherController> _logger;

        public WeatherController(ILogger<WeatherController> logger)
        {
            _logger = logger;
        }

        [HttpGet]
        public IActionResult Get()
        {
            _logger.LogInformation("Weather forecast requested at {Time}", DateTime.UtcNow);

            try
            {
                var data = new[] { "Sunny", "Cloudy", "Rainy" };
                return Ok(data);
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "Error while fetching weather data");
                return StatusCode(500, "Internal Server Error");
            }
        }
    }
}

✅ Here we:

Inject ILogger<WeatherController> using DI.
Log an information message and an error message.
Use structured logging (with placeholders like {Time}).

Log Levels in .NET Core

Log Level	Description
`Critical`	Application crash or serious failure
`Error`	Recoverable runtime error
`Warning`	Unexpected or abnormal events
`Information`	General application flow messages
`Debug`	Detailed debug info (used during development)
`Trace`	Very detailed, low-level diagnostic info

You can control what gets logged using appsettings.json.

Configure Logging in `appsettings.json`

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  }
}

This configuration:

Logs all messages from Information level and higher for your app.
Limits Microsoft framework logs to Warning and higher.

Setting up Logging in `Program.cs`

using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

var builder = WebApplication.CreateBuilder(args);

// Configure logging
builder.Logging.ClearProviders();
builder.Logging.AddConsole();
builder.Logging.AddDebug();

builder.Services.AddControllers();

var app = builder.Build();
app.MapControllers();
app.Run();

Structured Logging

Structured logging helps you avoid messy string concatenation.
Instead of writing:

_logger.LogInformation("User " + userId + " logged in at " + DateTime.UtcNow);

Write this instead:

_logger.LogInformation("User {UserId} logged in at {LoginTime}", userId, DateTime.UtcNow);

This logs data in a structured, queryable format (like JSON) — great for tools like Seq, Serilog, or Elastic Stack.

Using Scopes for Contextual Logs

Scopes allow you to associate related log entries with shared context (e.g., request ID, transaction ID).

using (_logger.BeginScope("TransactionId: {TransactionId}", Guid.NewGuid()))
{
    _logger.LogInformation("Transaction started");
    _logger.LogInformation("Transaction completed");
}

All log entries inside the scope will include the same TransactionId, which helps with tracing.

Adding Third-Party Providers (Serilog Example)

Want to store logs in files or send them to a log server?
Integrate Serilog with just a few lines.

Install packages:

dotnet add package Serilog.AspNetCore
dotnet add package Serilog.Sinks.File

Then update your Program.cs:

using Serilog;

Log.Logger = new LoggerConfiguration()
    .WriteTo.Console()
    .WriteTo.File("logs/log.txt", rollingInterval: RollingInterval.Day)
    .CreateLogger();

var builder = WebApplication.CreateBuilder(args);
builder.Host.UseSerilog();

builder.Services.AddControllers();

var app = builder.Build();
app.MapControllers();
app.Run();

Example Project

You can download a full working example here:
👉 Github

This includes:

Program.cs
WeatherController.cs
appsettings.json
.csproj file

Summary

ILogger is the foundation of logging in .NET Core.
It’s framework-independent, provider-based, and fully configurable.
Supports structured logging, log levels, and scopes.
Easily integrates with Serilog, NLog, Seq, or Elastic Stack.

With a good logging strategy, you can understand user behavior, detect issues early, and monitor your application health in production.

I’m Morteza Jangjoo and “Explaining things I wish someone had explained to me”

Secret Management in .NET: Tools, Best Practices, and Practical Examples

Morteza Jangjoo — Thu, 06 Nov 2025 10:00:00 +0000

Secret Management in .NET: Tools, Best Practices, and Practical Examples

Managing secrets like API keys, database connection strings, and certificates is critical for building secure .NET applications. Exposing secrets in source code or configuration files can lead to severe security risks. In this guide, we’ll cover secret management tools for .NET, when to use them, and practical examples.

Secret Management Tools Overview

Local Development

dotnet user-secrets: Stores sensitive data outside source code for local development. Not suitable for production.

Managed Cloud Services

Azure Key Vault: Securely stores secrets, keys, and certificates. Integrates with Managed Identity for credential-less access.
AWS Secrets Manager / Parameter Store: Equivalent solutions for AWS-hosted applications.

Enterprise / Vault Solutions

HashiCorp Vault: Offers advanced features like dynamic secrets, secret leasing, RBAC, and auditing. Libraries like VaultSharp make integration with .NET easy.

Containers & Orchestration

Kubernetes Secrets and Docker Secrets: Suitable for containerized applications. Combine with Vault or Key Vault for extra security.

CI/CD Secret Stores

GitHub Actions Secrets, GitLab CI variables, Azure DevOps Pipeline variables: Use these to inject secrets during deployment without hardcoding them.

When to Use Which Tool

Scenario	Recommended Tool
Local development	`dotnet user-secrets`
Staging / Production	Azure Key Vault or HashiCorp Vault
Containers / Kubernetes	Vault or Key Vault with CSI driver
CI/CD	CI/CD secrets store or inject from a central vault

Best Practices

Never store secrets in source code or repository.
Use least privilege (RBAC): services should access only the secrets they need.
Enable short-lived credentials and automatic rotation.
Secure CI/CD pipelines: filter logs, avoid printing secrets.
Encrypt secrets in transit and at rest.
Enable audit and monitoring for all secret access.

Practical .NET Examples

Using `dotnet user-secrets` (Local Development)

# Initialize user-secrets for the project
dotnet user-secrets init

# Set a secret
dotnet user-secrets set "ConnectionStrings:Default" "Server=...;User Id=...;Password=..."

ASP.NET Core automatically loads these secrets in the Development environment.

Using Azure Key Vault

// Program.cs (Minimal API / .NET 6+)
var builder = WebApplication.CreateBuilder(args);

// Add Azure Key Vault as a configuration source
builder.Configuration.AddAzureKeyVault(
    new Uri("https://<YourVaultName>.vault.azure.net/"),
    new DefaultAzureCredential()); // Uses Managed Identity for auth

var app = builder.Build();

Tip: Always use Managed Identity to avoid storing credentials in code.

Using HashiCorp Vault

// Using VaultSharp library
using VaultSharp;
using VaultSharp.V1.AuthMethods.Token;
using VaultSharp.V1.Commons;

var authMethod = new TokenAuthMethodInfo("your-vault-token");
var vaultClientSettings = new VaultClientSettings("https://vault-server:8200", authMethod);
var client = new VaultClient(vaultClientSettings);

Secret<SecretData> secret = await client.V1.Secrets.KeyValue.V2.ReadSecretAsync("myapp/secrets");
string dbPassword = secret.Data.Data["DbPassword"].ToString();

Optionally use Vault Agent for automatic secret caching and refresh.

Pros and Cons

Tool	Pros	Cons
user-secrets	Easy, fast for dev	Not for production
Azure Key Vault	Managed, easy integration, encryption built-in	Azure dependency
HashiCorp Vault	Feature-rich, multi-cloud, dynamic secrets	Operational complexity

Practical Tips for .NET Teams

Development: user-secrets + local environment variables.
Staging/Production: Centralized secret store (Azure Key Vault or HashiCorp Vault). Use Managed Identity or short-lived credentials.
CI/CD: Inject secrets from vault or CI/CD secrets store. Never log secrets.
Test rotations & failure scenarios to ensure your app handles temporary secret store unavailability.
Enable audit & alerts for suspicious access.

Implementing secret management properly makes your .NET applications more secure, maintainable, and compliant with modern security standards.

Boost .NET Performance with SIMD (`System.Numerics.Vector`)

Morteza Jangjoo — Wed, 05 Nov 2025 19:02:09 +0000

If you work with numerical-heavy workloads in .NET — like financial calculations, trading engines, or scientific simulations — performance matters. One of the most powerful tools available is SIMD (Single Instruction Multiple Data) via System.Numerics.Vector.

What is SIMD?

SIMD allows a single CPU instruction to operate on multiple data points at once.

Traditional code:

float sum = 0;
for (int i = 0; i < data.Length; i++)
    sum += data[i];

With SIMD, multiple values are processed in parallel, significantly speeding up numeric operations.

Benefits of Using SIMD

Performance Boost: Loops can run 3–5x faster.
Reduced Memory Pressure: Fewer allocations, lower GC overhead.
Low Latency: Perfect for real-time trading engines, market feeds, or signal processing.
Hardware Acceleration: Leverages AVX, SSE, or ARM Neon instructions automatically.

How to Use SIMD in .NET

using System;
using System.Numerics;

class Program
{
    static void Main()
    {
        float[] data = new float[100_000_000];
        for (int i = 0; i < data.Length; i++)
            data[i] = 1.0f;

        Console.WriteLine($"Sum: {SimdSum(data)}");
    }

    static float SimdSum(float[] data)
    {
        int vectorSize = Vector<float>.Count;
        var simdSum = new Vector<float>(0f);

        int i = 0;
        for (; i <= data.Length - vectorSize; i += vectorSize)
            simdSum += new Vector<float>(data, i);

        float total = 0f;
        for (int j = 0; j < vectorSize; j++)
            total += simdSum[j];

        // Remaining elements
        for (; i < data.Length; i++)
            total += data[i];

        return total;
    }
}

Tips:

Vector<float>.Count automatically adapts to CPU vector width.
Use with large arrays or heavy loops for best performance.
Always handle remaining elements outside the vector loop.

When to Use SIMD

Ideal for:

Trading indicators & financial calculations
Image or signal processing
CPU-based ML inference
Scientific simulations
Real-time analytics pipelines

Pro Tip: Combine SIMD with Span<T> to avoid extra allocations.

Conclusion

Using SIMD via System.Numerics.Vector in .NET provides:

Parallel processing of multiple values per CPU instruction
Reduced memory allocations & GC pressure
Higher throughput & lower latency

It’s a must-know optimization for any .NET developer working on high-performance or real-time systems.

References

I’m Morteza Jangjoo and “Explaining things I wish someone had explained to me”

nderstanding Reverse Proxy with .NET & SignalR (With Source Code + ZIP)

Morteza Jangjoo — Wed, 05 Nov 2025 09:30:00 +0000

Reverse Proxy plays a critical role in modern web architecture — especially when building real-time applications using SignalR.
In this guide, we’ll break down what a reverse proxy is, why you need it, and how to use it with .NET + YARP + SignalR.

Fully working example
Client → Proxy → SignalR architecture
ZIP source code included

What is a Reverse Proxy?

A reverse proxy is a server that sits in front of your backend services and forwards client requests to them.

Key benefits:

Load balancing
SSL termination
Central authentication & security
WebSockets support (important for SignalR!)
Routing multiple services under one public endpoint

📡 Why use Reverse Proxy with SignalR?

When building real-time systems (trading apps, dashboards, chat, IoT streaming) you may need:

Challenge	Reverse Proxy Solution
Clients change endpoints?	One static external URL ✅
SSL offload?	Proxy handles certs ✅
Distribute load?	Proxy balances hubs ✅
Run multiple backend instances?	Cluster routing ✅

Architecture

Client → Reverse Proxy (YARP) → SignalR Server

Full Example

We will run:

App	Port
SignalR Server	`5000`
YARP Reverse Proxy	`6000`
Client connects to proxy	✅

Folder Structure

ReverseProxyDemo/
 ├── SignalRServer        // .NET real-time server
 ├── ReverseProxy         // YARP proxy
 └── SignalRClient        // Console test client

Code — SignalR Server (`/SignalRServer/Program.cs`)

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.SignalR;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddSignalR();
var app = builder.Build();
app.MapGet("/", () => "SignalR Server Running");
app.MapHub<ChatHub>("/hub/chat");
app.Run();

public class ChatHub : Hub { }

Code — YARP Reverse Proxy (`/ReverseProxy/Program.cs`)

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddReverseProxy().LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"));
var app = builder.Build();
app.MapReverseProxy();
app.Run();

`appsettings.json`

{
  "ReverseProxy": {
    "Routes": {
      "signalrRoute": {
        "ClusterId": "signalrCluster",
        "Match": { "Path": "/hub/{**catch-all}" }
      }
    },
    "Clusters": {
      "signalrCluster": {
        "Destinations": {
          "destination1": { "Address": "http://localhost:5000" }
        }
      }
    }
  }
}

Code — Client (`/SignalRClient/Program.cs`)

using Microsoft.AspNetCore.SignalR.Client;
Console.WriteLine("Client connecting...");
var connection = new HubConnectionBuilder()
    .WithUrl("http://localhost:6000/hub/chat")
    .Build();
await connection.StartAsync();
Console.WriteLine("Connected to SignalR via Reverse Proxy!");

Running the project

Start SignalR server

cd SignalRServer
dotnet run --urls=http://localhost:5000

Start Reverse Proxy

cd ReverseProxy
dotnet run --urls=http://localhost:6000

Start Client

cd SignalRClient
dotnet run

Output:

Client connecting...
Connected to SignalR via Reverse Proxy!

Download Full Source Code (ZIP)

Link: (https://github.com/Morteza-Jangjoo/Reverse_Proxy)

This ZIP contains all three projects ready to run.

Conclusion

Reverse Proxy is essential in modern .NET architectures — especially when building real-time SignalR apps.

With YARP you get:

WebSockets support
Load balancing
Easy routing
Production-ready reverse proxy

Next Step

Want the same setup with:

Docker + Nginx
Angular real-time dashboard
Kubernetes setup

Comment below and I’ll publish part 2

💬 Feedback

If this helped you, drop a ❤️ and follow for more .NET + Realtime + Cloud tutorials.

Real-Time Streaming in .NET SignalR — Live Data Like Trading Apps

Morteza Jangjoo — Tue, 04 Nov 2025 18:19:14 +0000

Building real-time apps in .NET?

Chat and notifications are easy — but what about continuous streaming data like:

Live crypto & Forex prices
Stock tick feeds
IoT sensor streams
AI live token output
Monitoring dashboards

This is where SignalR Streaming becomes a superpower.

Let’s build it — step-by-step

What Is Streaming in SignalR?

Traditional SignalR sends messages one-by-one.

But some applications need constant data flow.

Feature	Normal SignalR	SignalR Streaming
Data pace	On-demand	Continuous
Frequency	Low/medium	High (sub-sec data)
Use case	Chat, Alerts	Trading feeds, IoT, AI
Performance	Good	⭐ Excellent

Project Goal

We will build a mini streaming server that sends random market prices every second, and a client that reads them live.

Perfect for learning + a base for real trading dashboards.

🛠 Backend — .NET SignalR Streaming Server

Create a project

dotnet new web -n SignalRStreamingDemo
cd SignalRStreamingDemo

Add SignalR

dotnet add package Microsoft.AspNetCore.SignalR

Create Hub

MarketHub.cs

using Microsoft.AspNetCore.SignalR;
using System.Runtime.CompilerServices;

public class MarketHub : Hub
{
    public async IAsyncEnumerable<decimal> StreamPrices(
        [EnumeratorCancellation] CancellationToken ct)
    {
        var rand = new Random();
        decimal price = 1000;

        while (!ct.IsCancellationRequested)
        {
            price += (decimal)(rand.NextDouble() - 0.5) * 5;

            yield return Math.Round(price, 2);

            await Task.Delay(1000, ct);
        }
    }
}

Wire Hub in `Program.cs`

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddSignalR();
var app = builder.Build();

app.MapHub<MarketHub>("/marketHub");

app.Run();

Server

Client — Vanilla JS Receiver

Create:

wwwroot/index.html

<!DOCTYPE html>
<html>
<head>
<title>SignalR Stream Demo</title>
<script src="https://cdnjs.cloudflare.com/ajax/libs/microsoft-signalr/7.0.5/signalr.min.js"></script>
</head>

<body>
<h3>📈 Live Prices</h3>
<pre id="log"></pre>

<script>
const conn = new signalR.HubConnectionBuilder()
  .withUrl("/marketHub")
  .build();

async function start() {
  await conn.start();
  const stream = conn.stream("StreamPrices");

  stream.subscribe({
    next: p => document.getElementById("log").textContent += p + "\n",
    complete: () => console.log("done"),
    error: err => console.error(err)
  });
}

start();
</script>
</body>
</html>

Run server:

dotnet run

Open browser:

http://localhost:5000

Boom
Live data — every second

Real-World Notes

Tip	Reason
Use `IAsyncEnumerable<T>`	Best streaming model
Include `CancellationToken`	Prevent leaks
Throttle updates	Protect UI
Use groups per market	Multi-symbol feeds
Benchmark before production	Trading needs speed ⚡

What You Can Build Next

Live crypto dashboard
AI token streaming like ChatGPT
Forex trading panel
IoT data monitor
Game telemetry dashboard

DEV Community: Morteza Jangjoo

Building Resilient .NET Applications with Polly

Retry and Circuit Breaker Patterns Explained with Practical Examples

What Is Resilience in Software Systems?

Understanding Transient Failures

The Retry Pattern

What Is the Retry Pattern?

When Should You Use Retry?

When NOT to Use Retry?

Retry Example with Polly

The Circuit Breaker Pattern

The Problem Circuit Breaker Solves

What Is a Circuit Breaker?

Circuit Breaker States

Circuit Breaker Example with Polly

Combining Retry and Circuit Breaker

Execution Example

Why Polly?

Real-World Use Cases

Key Takeaways

Final Thoughts

Why ILogger File Logging Fails in Production (and How to Fix It)

Why ILogger File Logging Fails in Production (and How to Fix It)

1. ILogger Does NOT Support File Logging

2. Why It Works in Development but Fails in Production

Reason 1: Logging configured only in appsettings.Development.json

Reason 2: Log directory does not exist

Reason 3: Missing write permissions (MOST COMMON)

3. The Correct Way: Use a Real File Logger (Serilog)

4. Install Required Packages

5. Configure Serilog in Program.cs

6. Configure Logging in appsettings.json (NOT Development-only)

7. Ensure the Log Folder Exists

8. Fix Production Permissions

IIS

Linux

Docker

9. Final Checklist (Production Safe)

Conclusion

Focus and Productivity for Developers

Focus and Productivity for Developers: Practical Tips for 2025

** Master Deep Work**

** Batch Tasks & Reduce Context Switching**

** Optimize Your Dev Environment**

** Mindful Breaks & Pomodoro**

** Reduce Cognitive Load**

** Automate Repetitive Tasks**

** Maintain Physical & Mental Health**

** Avoid Multitasking**

** Track Productivity Metrics**

** Organize Knowledge**

Final Thoughts

Domain-Driven Design (DDD)

Domain-Driven Design (DDD): A Practical Guide for Real-World .NET Developers

What Is Domain-Driven Design?

Why DDD Still Matters in 2025

1. Business complexity is growing

2. Perfect fit for Microservices & Event-Driven Systems

3. Helps avoid “Big Ball of Mud”

Key Building Blocks of DDD

** Entities**

** Value Objects**

** Aggregates**

** Repositories**

** Domain Events**

** Bounded Contexts**

When Should You Use DDD?

Use DDD if your project has:

When NOT to Use DDD

DDD + Clean Architecture in .NET (Modern Approach)

Real-World Sample Project (Download)

Final Thoughts

Python Inside .NET

Running Python Inside .NET 9 — A Complete Guide Using Python.NET

Why Use Python Inside .NET?

Prerequisites

1. Install Python

2. Install dependencies

3. Create a .NET 9 Console Project

4. Install Python.NET package

1. `ILogger` Does NOT Support File Logging

Reason 1: Logging configured only in `appsettings.Development.json`

5. Configure Serilog in `Program.cs`

6. Configure Logging in `appsettings.json` (NOT Development-only)

Master Deep Work

Batch Tasks & Reduce Context Switching

Optimize Your Dev Environment

Mindful Breaks & Pomodoro

Reduce Cognitive Load

Automate Repetitive Tasks

Maintain Physical & Mental Health

Avoid Multitasking

Track Productivity Metrics

Organize Knowledge

Entities

Value Objects

Aggregates

Repositories

Domain Events

Bounded Contexts

`Program.cs`

Create file: `/scripts/utils.py`

Updated `Program.cs`

`PyNetIntegration.csproj`

`Program.cs`

Step 2 — Register Configuration in `Program.cs`

`IOptions<T>` — Static Configuration

`IOptionsSnapshot<T>` — Per Request Reload

`IOptionsMonitor<T>` — Real-time Change Notifications

Understanding `ILogger` in .NET Core — A Complete Guide

What is `ILogger`?

Configure Logging in `appsettings.json`

Setting up Logging in `Program.cs`