Forem: Vimal

Modern Logging and Telemetry in .Net

Vimal — Fri, 20 Feb 2026 15:29:53 +0000

Introduction

Logging and telemetry are essential pillars of operational excellence in modern software systems. They provide real-time visibility into application behavior, system performance, and user interactions, enabling DevOps teams to detect and troubleshoot issues quickly before they impact users. Beyond just technical insights, this data informs product management decisions and enhances customer engagement by enabling proactive improvements and a deeper understanding of how users interact with the product.

🎯 Article Objective

The objective of this article is to introduce you to the fundamentals of OpenTelemetry and its integration with Azure Application Insights in a .NET application. It aims to highlight the importance of logging and telemetry in achieving operational excellence, particularly in modern cloud-native systems. By the end of this article, readers will understand how to:

Set up OpenTelemetry for distributed tracing and metrics collection in a .NET Web API.
Enable real-time visibility into application performance using Application Insights.
Enhance troubleshooting, DevOps workflows, and customer experience through effective telemetry.
Implement correlation IDs for traceability across services.
Collect critical performance metrics such as CPU usage, memory availability, and request duration.

This hands-on guide empowers developers to build more reliable, observable, and user-centric applications.

🔍 What is OpenTelemetry?

OpenTelemetry is an open-source standard for collecting telemetry data — logs, metrics, and traces — from your application.

It helps answer:

How long does a request take?
What services were involved in processing it?
Where are the bottlenecks?

📘 Why Not Just Use Logging?

Traditional logging is useful, but lacks context. Here’s how OpenTelemetry compares:

Feature	Logging	OpenTelemetry
Simple log messages	✅	✅
Tracing across services	❌	✅
Built-in metrics (CPU, memory)	❌	✅
Visualization in tools like Application Insights	❌	✅
Correlation across services	❌	✅

🎯 Why Use OpenTelemetry with Application Insights?

Application Insights is a powerful observability platform in Azure.
OpenTelemetry allows your app to send standardized, portable telemetry data.
Gain end-to-end visibility into distributed systems, including APIs, microservices, and external dependencies.

🛠️ Step-by-Step: Use OpenTelemetry in .NET 7

We’ll build a simple Web API that uses OpenTelemetry to trace requests and collect system metrics.

📦 Step 1: Add Required Packages

Run this in your terminal:

dotnet add package Microsoft.ApplicationInsights.AspNetCore
dotnet add package OpenTelemetry.Extensions.Hosting
dotnet add package OpenTelemetry.Instrumentation.AspNetCore
dotnet add package OpenTelemetry.Instrumentation.Http
dotnet add package OpenTelemetry.Exporter.ApplicationInsights

🧠 Step 2: Configure Program.cs

using Microsoft.ApplicationInsights.Extensibility;
using OpenTelemetry.Resources;
using OpenTelemetry.Trace;
using OpenTelemetry.Metrics;

var builder = WebApplication.CreateBuilder(args);

// Enable Application Insights
builder.Services.AddApplicationInsightsTelemetry();

// OpenTelemetry setup
builder.Services.AddOpenTelemetry()
    .ConfigureResource(resource => resource.AddService("MyWebApi"))
    .WithTracing(tracing => tracing
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddSource("MyWebApi")
        .SetSampler(new AlwaysOnSampler())
        .AddApplicationInsightsExporter(options =>
        {
            options.ConnectionString = builder.Configuration["APPLICATIONINSIGHTS_CONNECTION_STRING"];
        }))
    .WithMetrics(metrics => metrics
        .AddAspNetCoreInstrumentation()
        .AddRuntimeInstrumentation()
        .AddProcessInstrumentation()
        .AddApplicationInsightsMetricsExporter(options =>
        {
            options.ConnectionString = builder.Configuration["APPLICATIONINSIGHTS_CONNECTION_STRING"];
        }));

var app = builder.Build();

// Middleware to add correlation ID to response
app.Use(async (context, next) =>
{
    var traceId = System.Diagnostics.Activity.Current?.TraceId.ToString();
    if (!string.IsNullOrEmpty(traceId))
    {
        context.Response.Headers.Add("X-Correlation-ID", traceId);
    }
    await next();
});

app.MapControllers();
app.Run();

📂 Step 3: Create a Controller (TraceDemoController.cs)

using Microsoft.AspNetCore.Mvc;
using System.Diagnostics;

namespace MyWebApi.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class TraceDemoController : ControllerBase
    {
        private static readonly ActivitySource ActivitySource = new("MyWebApi");

        [HttpGet("hello")]
        public IActionResult Get()
        {
            using var activity = ActivitySource.StartActivity("SayHello");

            var traceId = Activity.Current?.TraceId.ToString();
            return Ok(new
            {
                Message = "Hello, world!",
                TraceId = traceId
            });
        }
    }
}

⚙️ Step 4: Add Configuration (appsettings.json)

Add your Application Insights connection string:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information"
    }
  },
  "APPLICATIONINSIGHTS_CONNECTION_STRING": "InstrumentationKey=YOUR-KEY-HERE"
}

📊 Metrics You Get Automatically

OpenTelemetry + Application Insights gives you:

Metric	Source
Request duration	`AddAspNetCoreInstrumentation`
CPU usage	`AddRuntimeInstrumentation`
Memory available	`AddProcessInstrumentation`
Request count	`AddAspNetCoreInstrumentation`

All these show up in Azure Application Insights under Metrics.

🧪 Testing the API

Run the app:

dotnet run

Call the endpoint:

GET http://localhost:5000/TraceDemo/hello

You’ll see the X-Correlation-ID in the response headers — that’s your trace ID!

📈 Viewing in Application Insights

Go to Azure Portal > Application Insights.

Use:

Application Map for service relationships.
Metrics to view CPU, memory, and requests.
Traces to search with X-Correlation-ID.
Performance to analyze slow endpoints.

✅ Summary

With OpenTelemetry + Application Insights, you now have:

✔ Distributed tracing

✔ Built-in performance metrics

✔ Context-rich diagnostics

✔ Cloud-native observability

This is a big step up from traditional logging and a must-have for any production-ready .NET app.

🧭 What’s Next?

Connect logs (ILogger) to trace context.

Export telemetry to other tools (Jaeger, Prometheus, etc.).

Set up alerts based on CPU, memory, or request duration.

🧠 Got Questions?

Feel free to drop issues or suggestions!

Managing NPM Registries in restricted environments

Vimal — Wed, 23 Jul 2025 05:26:27 +0000

Problem statement:

Recently we faced a challenge where our organization does not allow us to connect to the public NPM registry to develop locally. However the CI/CD pipelines of the client organization allowed connection to the public registry. As a team, we were pondering on different approaches to handle this unique situation. We could probably use two copies of package.json one for local having reference link to private registry and then another one for CI/CD pipeline. Is this a good approach or is there a better approach? Let us explore this in the article.

Introduction

This is a common scenario in some enterprise environments, developers work behind strict firewalls or disconnected networks that block access to the public NPM registry. Yet, the CI/CD pipelines (like Azure DevOps) may be fully open to the internet. This mismatch creates a development headache—how do you keep your dependencies synced and builds working smoothly?

A common (but bad) idea is to maintain two separate package.json files—one for local dev and one for CI/CD. But this introduces more problems than it solves.

The better, cleaner approach? Use .npmrc files smartly.

In this article let us explore how to:

Use a private registry for local development
Let Azure DevOps pipelines use the public registry
Securely manage credentials
Avoid sync issues between environments

❌ Why Two `package.json` Files Is a Bad Idea

Some teams try to maintain one package.json for local (private registry) and another for CI/CD (public registry).

Here’s why that’s problematic:

Dependency drift: Easy to forget syncing both files
Lockfile conflicts: package-lock.json mismatches can cause broken builds
Hard to audit: Tools like npm audit, dependabot, etc. lose context
Increased complexity: More files, more chances of human error

✅ The Right Way: Use `.npmrc`

Local Development Setup

In your Angular or Node project, create a .npmrc file only for local use:

# .npmrc (DO NOT commit to Git)
registry=https://your-private-registry.company.com/
always-auth=true

Or for scoped packages:

@your-org:registry=https://your-private-registry.company.com/

`.gitignore` It!

To avoid leaking sensitive registry info, add .npmrc to .gitignore:

.npmrc

Now you can safely run:

npm install

Azure DevOps CI/CD Setup

✅ Option 1: Use Public NPM Registry (Recommended for Pipelines)

Azure DevOps build agents can access the public registry by default. So just omit .npmrc in your repo and let it install dependencies directly from https://registry.npmjs.org.

- script: npm ci
  displayName: 'Install Dependencies'

Option 2: Use Private Registry in CI/CD (If Required)

If your pipeline must use a private registry, create a secret token in Azure DevOps (npm_token) and inject .npmrc at build time:

variables:
  NPM_TOKEN: $(npm_token)

steps:
  - script: |
      echo "registry=https://your-private-registry.company.com/" > .npmrc
      echo "//your-private-registry.company.com/:_authToken=$(NPM_TOKEN)" >> .npmrc
    displayName: 'Configure Private Registry'

  - script: npm ci
    displayName: 'Install Dependencies'

Full Azure DevOps Pipeline for Angular

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: NodeTool@0
  inputs:
    versionSpec: '18.x'
  displayName: 'Install Node.js'

- script: |
    echo "registry=https://registry.npmjs.org/" > .npmrc
  displayName: 'Use Public NPM Registry'

- script: npm ci
  displayName: 'Install Dependencies'

- script: npm run build
  displayName: 'Build Angular App'

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: 'dist'
    artifactName: 'angular-app'

Local vs CI/CD Setup

Local vs CI/CD

Key Takeaways

Don’t manage two package.json files
Use .npmrc to cleanly separate dev and CI registry logic
Keep .npmrc out of version control
Use secure tokens in Azure DevOps

Bonus Tips

Use `npmrc` CLI for Switching

If you switch between multiple registries, use npmrc:

npmrc private
npmrc public

Scoped Packages

To avoid overriding global registry settings, scope packages and use this pattern:

@your-org:registry=https://private.registry.com/

Wrapping Up

Using .npmrc properly lets you handle both restricted dev environments and open CI/CD pipelines with ease. It’s clean, secure, and scalable—everything a good DevOps setup should be.

Let me know in the comments your feedback, if you want a complete deploy-to-Azure setup or if you're facing similar restrictions in your organization!

Designing for Dependency Injection — Think Like a Developer, Not a Container

Vimal — Sun, 20 Jul 2025 16:21:47 +0000

Before reaching for .AddScoped or new, take a step back and ask what your class needs to do — not what it needs to create. This should model a functionality from the business domain.

Design Thinking First, DI Later

A well-designed class doesn't scream for injection. It simply:

Has a clear purpose.
Exposes what it needs to perform that purpose.
Delegates responsibilities it shouldn't own.

Let’s unpack that with a practical approach.

Step 1: Identify the Class's Responsibility

Ask: What behavior is this class responsible for? . Let us analyse an order processing functionality. How would you model the behavior and construct the class?

Example:

public class OrderProcessor
{
    public void ProcessOrder()
    {
        // Validate order
        // Charge payment
        // Send confirmation email
    }
}

Looking at the above class, you’ve already spotted the problem: This class does too much. This is linked to the 'S' in SOLID principles, the class should handle only a single-responsibility.

Step 2: Delegate Responsibilities via Abstractions

Break it down. Let other services handle each concern.

public interface IOrderValidator
{
    bool Validate(Order order);
}

public interface IPaymentService
{
    void Charge(Order order);
}

public interface INotificationService
{
    void SendConfirmation(Order order);
}

Now rewrite OrderProcessor as a coordinator, not a worker:

public class OrderProcessor
{
    private readonly IOrderValidator _validator;
    private readonly IPaymentService _payment;
    private readonly INotificationService _notifier;

    public OrderProcessor(
        IOrderValidator validator,
        IPaymentService payment,
        INotificationService notifier)
    {
        _validator = validator;
        _payment = payment;
        _notifier = notifier;
    }

    public void ProcessOrder(Order order)
    {
        if (!_validator.Validate(order)) return;

        _payment.Charge(order);
        _notifier.SendConfirmation(order);
    }
}

You’ve just designed for Dependency Injection — without thinking about the container.

Step 3: Make It Testable and Flexible

This class can now be tested using mocks:

var mockValidator = new Mock<IOrderValidator>();
mockValidator.Setup(v => v.Validate(It.IsAny<Order>())).Returns(true);

var mockPayment = new Mock<IPaymentService>();
var mockNotifier = new Mock<INotificationService>();

var processor = new OrderProcessor(mockValidator.Object, mockPayment.Object, mockNotifier.Object);
processor.ProcessOrder(new Order());

✅ No real implementations required. ✅ You can test logic in isolation.

Step 4: Let the Container Wire It Up

Only now do you register it in .NET Core:

builder.Services.AddScoped<IOrderValidator, OrderValidator>();
builder.Services.AddScoped<IPaymentService, StripePaymentService>();
builder.Services.AddScoped<INotificationService, EmailNotifier>();
builder.Services.AddScoped<OrderProcessor>();

Summary: The Design-First DI Checklist

Step	Ask Yourself…	Outcome
1	What does this class need to do?	Define the class’s responsibility
2	What can be delegated to collaborators?	Extract abstractions
3	How can this class be tested in isolation?	Refactor for injectability
4	Where do I register this in DI container?	Configure DI at the edges

📌 Remember

DI isn’t about using a container.
It’s about designing classes that ask for what they need, instead of building it themselves.

Start from behavior. Inject contracts. Let the container worry about construction.

Dependency Injection in .NET Core

Vimal — Sun, 20 Jul 2025 15:56:40 +0000

Overview

Dependency Injection (DI) is a software design pattern and technique that deals with how components acquire their dependencies. Rather than creating dependencies internally, a class receives them from the outside — improving modularity, testability, and flexibility.

In .NET, Dependency Injection is a first-class citizen, built directly into the ASP.NET Core framework.

Purpose

Dependency Injection aims to separate the creation of a component’s dependencies from the component’s behavior, promoting Inversion of Control (IoC). The class should focus only on what it needs to do, not on how to create the things it needs.

"Don't call me, I’ll call you." — This summarizes Inversion of Control, where the framework injects required services into your class.

Some of the common dependencies needed in application are:

Services (ILogger, DbContext, etc.)
Repositories (ICustomerRepository)
Configurations (IOptions)
External integrations (IEmailService, IPaymentGateway)

Types of Dependency Injection

There are three common forms of DI:

Constructor Injection (most common)
Setter Injection (property-based)
Interface Injection (less common in .NET)

1. Constructor Injection

The dependency is provided through the class constructor.

public interface IMessageService
{
    string GetMessage();
}

public class EmailMessageService : IMessageService
{
    public string GetMessage() => "Message via Email";
}

public class NotificationManager
{
    private readonly IMessageService _messageService;

    public NotificationManager(IMessageService messageService)
    {
        _messageService = messageService;
    }

    public void Notify()
    {
        Console.WriteLine(_messageService.GetMessage());
    }
}

Registration in .NET Core

builder.Services.AddTransient<IMessageService, EmailMessageService>();
builder.Services.AddTransient<NotificationManager>();

2. Setter (Property) Injection

Dependencies are set via public properties. Not natively supported by the built-in container, but possible manually.

public class LoggerService
{
    public IMessageService MessageService { get; set; }

    public void Log()
    {
        Console.WriteLine(MessageService?.GetMessage());
    }
}

In this case, MessageService would need to be set manually after object construction.

3. Interface Injection

The dependency provides an interface to inject itself into the consumer. Rare in .NET:

public interface IInjectable
{
    void Inject(IMessageService messageService);
}

Consumers then implement Inject to receive the dependency.

Lifetimes in .NET DI

When registering services, you specify how long a service lives:

Transient – new instance each time
Scoped – one instance per request
Singleton – one instance for the app lifetime


builder.Services.AddTransient<IMyService, MyService>(); // new each time
builder.Services.AddScoped<IMyService, MyService>();    // one per web request
builder.Services.AddSingleton<IMyService, MyService>(); // shared instance

Dependency Graph

.NET Core builds a dependency graph during application startup. Circular dependencies (A → B → A) are automatically detected and cause an error.

Benefits of DI

Decoupling: Easier to replace or extend components
Testability: Easier to write unit tests using mocks
Reusability: Services can be reused across classes
Maintainability: Easier to manage and evolve large applications

Real-world Example

public interface IPaymentProcessor
{
    void Process(decimal amount);
}

public class StripePaymentProcessor : IPaymentProcessor
{
    public void Process(decimal amount)
    {
        Console.WriteLine($"Processed ${amount} via Stripe.");
    }
}

public class CheckoutService
{
    private readonly IPaymentProcessor _paymentProcessor;

    public CheckoutService(IPaymentProcessor paymentProcessor)
    {
        _paymentProcessor = paymentProcessor;
    }

    public void Checkout()
    {
        _paymentProcessor.Process(100);
    }
}

Registration:

builder.Services.AddScoped<IPaymentProcessor, StripePaymentProcessor>();
builder.Services.AddScoped<CheckoutService>();

Usage:

var checkout = app.Services.GetRequiredService<CheckoutService>();
checkout.Checkout(); // Outputs: Processed $100 via Stripe.

Anti-Patterns to Avoid

Service Locator Pattern: Using IServiceProvider.GetService() everywhere breaks DI principles.
Too Many Dependencies: If a class has too many injected services, it's likely violating Single Responsibility Principle.
Mixing lifetimes improperly: Injecting Scoped into Singleton can cause unexpected behavior.

Conclusion

Dependency Injection in .NET Core encourages clean architecture by separating behavior from object creation. It's built-in, powerful, and essential for test-driven and scalable .NET applications.

By focusing on what your classes need to do, and not how they get their dependencies, your application becomes more maintainable, testable, and adaptable to change.

Distribute iOS mobile applications(without App Store)

Vimal — Wed, 16 Jul 2025 00:59:02 +0000

Ever built an app just for yourself and wondered, "How do I get this running on my iPhone without publishing it to the App Store?" Whether you're testing a side project, creating a tool for personal productivity, or experimenting with Flutter or SwiftUI, deploying a private app to your own device is totally doable—no paid Apple Developer account required.

In this post, I’ll walk you through how to:

Build and install a personal iOS app on your device using Xcode
Run the app without using TestFlight or the App Store
Fix that annoying issue where the app stops working once you unplug the USB
Decide if a free Apple ID is enough for your needs—or if it's time to go Pro

Let’s dive into how you can run your own iOS app —no distribution headaches, no gatekeepers, just your code on your phone.

1. Free (“Personal”) Provisioning via Xcode

Apple lets you install debug builds on your own device using just a free Apple ID—but with some limitations (e.g. 1 app per bundle‑ID, the provisioning profile expires weekly, and you can’t share to other people).

Install Xcode
– On your Mac, download Xcode from the App Store.
– Make sure you have at least macOS Sonoma (14.0) or later.
Open Your Project
– If you’re using Flutter, open your project root and execute.
```
    flutter build ios

    open ios/Runner.xcworkspace 
```
– If you’re native Swift/Obj‑C: open your .xcodeproj or .xcworkspace.
Add Your Apple ID
1. In Xcode, go to Xcode ▶️ Settings ▶️ Accounts, click “+”, and sign in with your Apple ID.
2. Select your Apple ID, then “Manage Certificates” → click “+” → “iOS Development”.
Set Bundle Identifier
1. In the Project Navigator select your main target (e.g. Runner).
2. Under Signing & Capabilities → Team, choose your personal Apple ID.
3. Change the Bundle Identifier to something unique (e.g. com.yourname.myapp).
Connect Your iPhone

– Plug your iPhone into the Mac via USB (or enable wireless debugging).
– In Xcode’s toolbar, select your device from the run‑destination menu.
Build & Run

– Click ▶️ (Run). Xcode will automatically generate a provisioning profile, sign the app, install it on your device, and launch it.
– If you see a “Untrusted Developer” alert on your phone, go to Settings ▶️ General ▶️ VPN & Device Management and trust your Apple ID profile.
Re‑sign Weekly

Free provisioning profiles last 7 days. After that, you need to re‑build & run from Xcode to renew.

⚡Tip:
If you’re expecting to be able to tap the app icon and launch it without ever reconnecting,enable wireless debugging so Xcode can install & re‑sign over Wi‑Fi, without a cable each time:

With your device plugged in, open Window → Devices and Simulators in Xcode.

Select your iPhone or device in the left list, then check Connect via network.

Now you can unplug the USB cable—and as long as both Mac and iPhone are on the same Wi‑Fi, you can build & Run wirelessly.

2. Paid Apple Developer Program (₹8,400/year)

If you want more flexibility— Ad‑Hoc distribution, TestFlight, multiple devices, push notifications, or to share with up to 100 testers—you’ll need a paid account.

What is Ad-Hoc Distribution?
Ad-Hoc distribution lets you install an app on up to 100 physical iOS devices per year using an IPA file (the iOS app package), without going through the App Store or TestFlight.

Key Features:

App is signed with a special “Ad-Hoc” provisioning profile
You manually specify the UDIDs (device IDs) of the devices you want to allow
You export an IPA from Xcode or CI
You can install the app using:
- Apple Configurator (USB)
- OTA (Over-the-Air) tools like Diawi, Firebase App Distribution, etc.

Enroll
– Go to https://developer.apple.com and sign up for the Apple Developer Program.
– Pay the annual fee (₹8,400 in India).
Register Devices (for Ad‑Hoc)
– In App Store Connect → Your App → Devices, add each device’s UDID.
Create an App ID & Provisioning Profile
– In Certificates, IDs & Profiles, register your App ID (bundle‑ID), and generate an Ad‑Hoc or Development provisioning profile that includes your registered devices.
Build & Distribute
- In Xcode, select your paid “Team” under Signing.
- Archive your build (Product ▶️ Archive), then export an Ad‑Hoc IPA.
- Distribute via:
  - TestFlight (easiest for multiple testers)
  - Direct install (using tools like Apple Configurator or a simple web‑hosted OTA link)
App Updates

You can push updates through TestFlight or simply rebuild & redistribute the IPA.

Choosing Between the Two

Feature	Free Provisioning	Paid Developer Program
Cost	Free	₹8,400/year
Device count	1 (per bundle‑ID)	Up to 100 (Ad‑Hoc), unlimited TestFlight
Profile expiration	7 days	1 year
App distribution to others	No	Yes (Ad‑Hoc, TestFlight)
Push Notifications, App Store	No	Yes

✅ When Should You Use Ad-Hoc?
Use Ad-Hoc if:

You have a private app you want to install on your team’s or family’s devices
You want to avoid App Store delays
You want more freedom than TestFlight’s 90-day limit

If it’s just for your own testing and you don’t mind re‑signing weekly, the free path is simplest. If you want reliable longer provisioning, wider distribution, or App Store/TestFlight support, go with the paid Developer Program.

Leave me a message if you’d like more detail on any of these steps!

Securely Managing Secrets in Configuration in .NET Applications

Vimal — Fri, 04 Jul 2025 10:18:37 +0000

The Problem

Many developers make the mistake of adding connection strings to appsettings file of .Net application. This makes its way in to the repository and becomes a target of database attacks.Storing connection strings as plain text in configuration files and checking them into a repository can lead to security vulnerabilities, as sensitive information like passwords can be easily accessed by unauthorised users.

Possible Solution

.Net provides a number of configuration providers for storing and reading configuration. Storing sensitive configuration items like connection strings in an environment variable is the safest way to avoid connection string or password exposure. Configuration is read from the process that the application is running in.
This code works locally as well on Azure after deployment.

In the case of Azure App Service, just need to add the configuration item and value under Settings > Environment Variables on the App Service in Azure portal.

To add a connection string to environment variables locally, follow these steps:

1. Set Environment Variable in Your Operating System

On Linux or macOS:

You can set the environment variable in your terminal session:

export DBConnectionString="Server=tcp:your-server.database.windows.net,1433;Database=your-database;User ID=your-username;Password=your-password;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;"

To make it persistent across sessions, add the above line to your shell configuration file (e.g., ~/.bashrc, ~/.zshrc, or ~/.bash_profile), and then reload the file:

source ~/.bashrc

On Windows:

Open the Start Menu and search for "Environment Variables."
Click on Edit the system environment variables.
In the System Properties window, click Environment Variables.
Under User variables or System variables, click New.
Add the following:
- Variable name: DBConnectionString
- Variable value: Server=tcp:your-server.database.windows.net,1433;Database=your-database;User ID=your-username;Password=your-password;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
Click OK to save.

2. Verify the Environment Variable

To ensure the environment variable is set correctly, you can print it in your terminal:

On Linux/macOS:

echo $DBConnectionString

On Windows (Command Prompt):

echo %DBConnectionString%

On Windows (PowerShell):

$env:DBConnectionString

3. Access the Environment Variable in Your Application

In your application, you can access the environment variable using Environment.GetEnvironmentVariable:

var connectionString = Environment.GetEnvironmentVariable("DBConnectionString");

4. Test the Configuration

Run your application and ensure the connection string is being picked up correctly. You can log the connection string for debugging purposes:

Console.WriteLine($"SQL Connectionstring: {connectionString}");

Summary

Set the environment variable using your operating system's tools.
Access the variable in your application using Environment.GetEnvironmentVariable.

Let me know if you need further assistance!

Practical Caching in .NET: Strategies, Eviction, Keys, and Metrics

Vimal — Sat, 21 Jun 2025 13:42:51 +0000

Key Objectives

Understand the different caching options available in .NET.
Learn about cache eviction strategies and when to use them.
Discover best practices for choosing cache keys.
Explore how to measure cache efficiency using instrumentation and logging.
See practical code samples for real-world caching scenarios.

Why Caching Matters

Caching is a fundamental technique for improving application performance and scalability. By storing frequently accessed data in a fast-access layer, you reduce database load, speed up response times, and can even improve reliability during transient back-end failures.

Fetching data from cache saves networks calls to database, query execution time which speeds up the overall response time.

Caching Options in .NET

.NET provides several built-in caching mechanisms:

In-Memory Cache (IMemoryCache)
Stores data in the memory of the application process. Fast, but data is lost on restart and not shared across servers.
Distributed Cache (IDistributedCache)
Supports external cache stores like Redis or SQL Server. Data is shared across multiple app instances and survives restarts.
Response Caching
Caches HTTP responses at the middleware level for web APIs.
Output Caching (ASP.NET Core 7+)
Caches the output of controllers or Razor pages.

Cache Eviction Strategies

Eviction determines when items are removed from the cache. Common strategies in .NET:

Absolute Expiration The item is removed after a fixed time, regardless of usage.

  _memoryCache.Set(key, value, TimeSpan.FromMinutes(10));

Sliding Expiration The item stays in the cache as long as it is accessed within a time window.

_memoryCache.Set(key, value, new MemoryCacheEntryOptions
{
    SlidingExpiration = TimeSpan.FromMinutes(5)
});

Manual Eviction Remove items explicitly when data changes.

_memoryCache.Remove(key);

Size-based Eviction Set a size limit for the cache; least recently used items are evicted when the limit is reached.

Choosing Cache Keys

Cache keys should be:

Unique: Represent the data being cached (e.g., "user_123" for user with ID 123).
Consistent: Use a predictable pattern for easy invalidation.
Scoped: Include context if needed (e.g., "product_{id}_details").
Example:

string cacheKey = $"employee_{employeeId}";

Measuring Cache Efficiency

To know if your cache is effective, instrument your code to log:

Cache Hits: Data was found in the cache.
Cache Misses: Data was not found and had to be loaded.
Evictions: When items are removed due to expiration or manual removal.
Retrieval Times: Time taken to fetch from cache vs. database.
Sample Instrumentation:

var stopwatch = Stopwatch.StartNew();
if (_memoryCache.TryGetValue(key, out var value))
{
    _logger.LogInformation("Cache hit for {Key} at {Time}", key, DateTime.UtcNow);
}
else
{
    _logger.LogInformation("Cache miss for {Key} at {Time}", key, DateTime.UtcNow);
    value = await LoadFromDatabaseAsync();
    _memoryCache.Set(key, value, TimeSpan.FromMinutes(10));
}
stopwatch.Stop();
_logger.LogInformation("Retrieval for {Key} took {Elapsed} ms", key, stopwatch.ElapsedMilliseconds);

Advanced:

For distributed caches like Redis, you can use Redis server metrics or middleware like App Metrics for more detailed analysis.

Example: In-Memory Cache with Eviction and Instrumentation

public class EmployeeCacheService
{
    private readonly IMemoryCache _memoryCache;
    private readonly ILogger<EmployeeCacheService> _logger;

    public EmployeeCacheService(IMemoryCache memoryCache, ILogger<EmployeeCacheService> logger)
    {
        _memoryCache = memoryCache;
        _logger = logger;
    }

    public async Task<Employee> GetEmployeeAsync(int employeeId)
    {
        string key = $"employee_{employeeId}";
        var stopwatch = Stopwatch.StartNew();

        if (_memoryCache.TryGetValue(key, out Employee employee))
        {
            _logger.LogInformation("Cache hit for {Key} at {Time}", key, DateTime.UtcNow);
        }
        else
        {
            _logger.LogInformation("Cache miss for {Key} at {Time}", key, DateTime.UtcNow);
            employee = await LoadEmployeeFromDb(employeeId);
            _memoryCache.Set(key, employee, new MemoryCacheEntryOptions
            {
                AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10)
            });
            _logger.LogInformation("Cache set for {Key} at {Time}", key, DateTime.UtcNow);
        }

        stopwatch.Stop();
        _logger.LogInformation("Retrieval for {Key} took {Elapsed} ms", key, stopwatch.ElapsedMilliseconds);
        return employee;
    }

    public void EvictEmployee(int employeeId)
    {
        string key = $"employee_{employeeId}";
        _memoryCache.Remove(key);
        _logger.LogInformation("Cache evicted for {Key} at {Time}", key, DateTime.UtcNow);
    }
}

Summary

.NET offers several caching options: in-memory, distributed (Redis, SQL), and response/output caching.
Choose the right eviction strategy for your scenario: absolute, sliding, manual, or size-based.
Use clear, unique cache keys for easy management and invalidation.
Instrument your cache usage to measure hits, misses, evictions, and performance.
Caching is a powerful tool—use it wisely to boost your app’s speed and scalability!

What caching strategies have worked best for your .NET projects? Share your experience in the comments!

The Hidden Performance Pitfalls of EF Core LINQ Queries

Vimal — Tue, 27 May 2025 10:25:04 +0000

The Good Part

Entity Framework Core (EF Core) is a popular Object-Relational Mapper (ORM) that simplifies data access in .NET applications by allowing developers to use LINQ (Language Integrated Query) for interacting with databases. This abstraction provides strong typing, compile-time checking, and a more readable syntax than raw SQL.

The Problem

Developers find it easy to write a LINQ query to fetch results from database with the built-in IntelliSense support. However, beneath this convenience lies a critical challenge:

EF Core translates LINQ queries into SQL at runtime, often producing complex and inefficient SQL queries that can severely degrade database performance.

EF Core LINQ queries are translated into SQL at runtime, often resulting in inefficient and bloated SQL statements.
Developers may not realize the performance impact, especially on large datasets with complex joins.

⚡Tip: Performance Optimization with AsNoTracking()
When querying data using Entity Framework, the default behavior is to track the returned entities in the change tracker. This allows EF to detect changes and persist them back to the database. However, if you're only reading data and not modifying it, this tracking introduces unnecessary overhead. Therefore, for read-only operations use AsNoTracking() with LINQ to improve performance. e.g.

var customers = context.Customers.AsNoTracking().ToList();

Solution using Stored Procedure

Stored procedures have the advantage of being compiled once and stored in the database. This reduces the overhead of parsing and compiling SQL statements every time they are run.

Let us create two stored procedures for our example:

A SELECT stored procedure to retrieve customers by country.

CREATE PROCEDURE GetCustomersByCountry
    @Country NVARCHAR(50)
AS
BEGIN
    SELECT * FROM Customers
    WHERE Country = @Country
END

A NON-SELECT stored procedure to update a customer's contact name.

CREATE PROCEDURE UpdateCustomerContactName
    @CustomerID NCHAR(5),
    @ContactName NVARCHAR(100)
AS
BEGIN
    UPDATE Customers
    SET ContactName = @ContactName
    WHERE CustomerID = @CustomerID
END

EF core does not provide out-of-the-box support for stored procedures yet. Use one of the methods described below:

Method 1: Handcraft Stored Procedure Methods

SELECT Stored Procedure using FromSqlRaw

For stored procedure returning data, create a method using FromSqlRaw to execute the stored procedure and map the results to a model.

public async Task<List<Customer>> GetCustomersByCountryAsync(string country)
{
    return await _context.Customers
        .FromSqlRaw("EXEC GetCustomersByCountry @Country = {0}", country)
        .ToListAsync();
}

NON-SELECT Stored Procedure


public async Task<int> UpdateCustomerContactNameAsync(string customerId, string contactName)
{
    return await _context.Database.ExecuteSqlRawAsync(
        "EXEC UpdateCustomerContactName @CustomerID = {0}, @ContactName = {1}",
        customerId, contactName);
}

With this method developers will have to take care of the method creation and mappings, adding overhead.

Method 2: EF Core Power Tools Integration

Why use EF Core Power Tools?

It automatically generates mappings for stored procedures and functions as LINQ-callable methods.
Eliminates manual SQL strings, reducing errors and improving maintainability.
Allows reverse engineering of complex database schemas.

How to Use EF Core Power Tools

1️⃣ Install the Extension

Open Visual Studio, go to Extensions → Manage Extensions.
Search for EF Core Power Tools, install it, and restart Visual Studio.

2️⃣ Reverse Engineer Your Database

Right-click your project → EF Core Power Tools → Reverse Engineer.
Select your SQL Server database.
Select Tables, Views, and Stored Procedures (like GetCustomersByCountry).

3️⃣ Generated Code Example
When using EF Core Power Tools to reverse engineer stored procedures, the tool generates method stubs and result classes based on the stored procedure signatures. Here's how the methods for the two stored procedures would typically look after generation:

SELECT Stored Procedure

public virtual async Task<List<GetCustomersByCountryResult>> GetCustomersByCountryAsync(string country)
{
    var countryParam = new SqlParameter("@Country", country ?? (object)DBNull.Value);

    return await this.Set<GetCustomersByCountryResult>()
        .FromSqlRaw("EXEC GetCustomersByCountry @Country", countryParam)
        .ToListAsync();
}

The generated mapping means you can now call:

var customers = await context.GetCustomersByCountryAsync(country);

NON-SELECT Stored Procedure

public virtual async Task<int> UpdateCustomerContactNameAsync(string customerId, string contactName)
{
    var customerIdParam = new SqlParameter("@CustomerID", customerId ?? (object)DBNull.Value);
    var contactNameParam = new SqlParameter("@ContactName", contactName ?? (object)DBNull.Value);

    return await Database.ExecuteSqlRawAsync(
        "EXEC UpdateCustomerContactName @CustomerID, @ContactName",
        customerIdParam, contactNameParam);
}

Invoke the method:

int rowsAffected = await context.UpdateCustomerContactNameAsync(customerId, newContactName);

No manual SQL strings! Plus, EF Core can track and map results efficiently.

Visual Studio Screenshots for EF Core Power Tools

🔹 Step 1: Reverse Engineer Options

🔹 Step 2: Select Database

🔹 Step 3: Select Stored Procedures and Tables

Conclusion

🔸 EF Core LINQ is great for productivity, but not always for performance.
🔸 Stored procedures can optimize performance, especially for complex queries.
🔸 EF Core Power Tools automates the integration of stored procedures into EF Core, giving you:

Clean LINQ-callable methods.
Auto-generated mappings.
Reduced manual SQL.

Factory Pattern in .Net

Vimal — Mon, 26 May 2025 10:38:20 +0000

Key Objectives of the Article

Understand what the Factory Pattern is and its role in software design.
Learn why the Factory Pattern is important, focusing on flexibility, maintainability, and decoupling.
Explore a real-world example of using the Factory Pattern to dynamically switch between Azure SQL Database, SQLite and In-Memory databases in a .NET Core application.
Review relevant code samples to implement the Factory Pattern for database configuration.
Summarize the benefits of using the Factory Pattern in real-world applications.

What is the Factory Pattern?

The Factory Pattern is a creational design pattern that provides a way to create objects without specifying their exact class. Instead of instantiating objects directly, the Factory Pattern delegates the responsibility of object creation to a factory class or method.

Key Features:

Encapsulation of Object Creation: The logic for creating objects is centralized in a factory, reducing duplication.
Flexibility: Allows switching between different implementations or configurations without modifying the client code.
Abstraction: The client code depends on an interface or abstract class, not the concrete implementation.

Why Do We Need the Factory Pattern?

The Factory Pattern is particularly useful in scenarios where:

Dynamic Object Creation: The type of object to be created is determined at runtime based on configuration or conditions.
Code Reusability: Centralizing object creation logic makes it reusable across multiple parts of the application.
Decoupling: It decouples the client code from the concrete implementation, adhering to the Dependency Inversion Principle.
Simplifies Maintenance: Changes to the object creation logic are isolated in the factory, making the code easier to maintain and extend.

Real-Time Example: Switching Between Azure SQL Database and In-Memory Databases

In a .NET Core application, you may want to switch between databases based on need, for example between an Azure SQL database (for production) and an In-Memory database (for testing or development). The Factory Pattern can encapsulate the logic for configuring the database provider, allowing you to switch databases dynamically based on a configuration setting.

Code Implementation

1. Create the `DbContextFactory` Class

The factory encapsulates the logic for configuring the database provider. Uses the configuration in appsettings to set up the correct database provider.

using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;

namespace Infrastructure.Data
{
    public static class DbContextFactory
    {
        public static void ConfigureDbContext(IServiceCollection services, IConfiguration configuration)
        {
            var databaseProvider = configuration.GetValue<string>("DatabaseProvider");


            if (databaseProvider == "InMemory")
            {
                // Configure In-Memory Database
                services.AddDbContext<AppDbContext>(options =>
                    options.UseInMemoryDatabase("InMemoryDb").EnableSensitiveDataLogging().LogTo(Console.WriteLine));
            }
             else if (databaseProvider == "SQLite")
            {
                // Configure SQLite Database
                var connectionString = configuration.GetConnectionString("SQLiteConnection");
                services.AddDbContext<AppDbContext>(options =>
                    options.UseSqlite(connectionString).EnableSensitiveDataLogging().LogTo(Console.WriteLine));
            }
            else if (databaseProvider == "AzureSQL")
            {
                // Configure Azure SQL Database
                var connectionString = configuration.GetConnectionString("AzureSQLConnection");
                services.AddDbContext<AppDbContext>(options =>
                    options.UseSqlServer(connectionString).EnableSensitiveDataLogging().LogTo(Console.WriteLine));
            }
            else
            {
                throw new InvalidOperationException("Invalid database provider specified in configuration.");
            }
        }
    }
}

2. Update Startup.cs to Use the Factory

Modify the Startup.cs file to use the DbContextFactory for configuring the AppDbContext. This class reads configuration and passes it to the registration methods.

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    services.AddSwaggerGen(c =>
    {
        c.SwaggerDoc("v1", new OpenApiInfo { Title = "Clean Architecture API", Version = "v1" });
    });

    // Register application services
    services.AddTransient<IRepository<Entity>, EntityRepository>();
    services.AddScoped<IEntityService, EntityService>();

    // Use the DbContextFactory to configure the database
    DbContextFactory.ConfigureDbContext(services, _configuration);
}

3. Add Configuration in `appsettings.json`

Add a configuration setting DatabaseProvider to specify whether to use the in-memory database or Azure SQL Database. This is used by DbContextFactory to setup the right database provider.

 "DatabaseProvider": "AzureSQL", // Options: InMemory, SQLite, AzureSQL
  "ConnectionStrings": {
    "SQLiteConnection": "Data Source=app.db",
    "AzureSQLConnection": "Server=tcp:<your-server-name>.database.windows.net,1433;Initial Catalog=<your-database-name>;Persist Security Info=False;User ID=<your-username>;Password=<your-password>;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;"
  }
}

diagram: Illustration of control flow

4. Initialize the Database with Seed Data

Ensure the database is initialized with seed data during application startup.

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseRouting();
    app.UseAuthorization();
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });

    // Initialize the database with seed data
    using (var scope = app.ApplicationServices.CreateScope())
    {
        var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>();
        dbContext.Database.EnsureCreated();

        // Seed data
        if (!dbContext.Entities.Any())
        {
            dbContext.Entities.AddRange(new[]
            {
                new Entity { Id = 1, Name = "Sample Entity 1", Description = "This is a sample entity." },
                new Entity { Id = 2, Name = "Sample Entity 2", Description = "This is another sample entity." }
            });
            dbContext.SaveChanges();
        }
    }

    app.UseSwagger();
    app.UseSwaggerUI(c =>
    {
        c.SwaggerEndpoint("/swagger/v1/swagger.json", "Clean Architecture API V1");
        c.RoutePrefix = string.Empty; // Set Swagger UI at the app's root
    });
}

Summary

The Factory Pattern is a powerful design pattern that simplifies object creation, promotes flexibility, and adheres to key software design principles like decoupling and reusability. In this article, we explored:

What the Factory Pattern is and why it is important.
A real-world example of using the Factory Pattern to switch between SQLite, In-Memory and Azure SQL databases.
Step-by-step implementation with relevant code samples.

By applying the Factory Pattern, you can make your application more flexible, maintainable, and adaptable to changing requirements.

Understanding the Options Pattern in .NET Core

Vimal — Fri, 23 May 2025 10:09:03 +0000

Article Objectives

By the end of this article, you will:

Understand what the Options Pattern is in .NET Core.
Learn the importance of strongly-typed configuration using the Options Pattern.
Explore a practical use case where static role information is managed via configuration.
Review relevant code samples to understand how to implement and use the Options Pattern.
Understand the key takeaways for applying the Options Pattern in your projects.

1. What is the Options Pattern?

The Options Pattern in .NET Core is a design pattern used to manage application configuration in a strongly-typed manner. Instead of accessing configuration values directly from the IConfiguration interface, the Options Pattern allows you to bind configuration sections to strongly-typed classes. This makes it easier to manage, validate, and use configuration settings throughout your application.

Key Features:

Strongly-Typed Classes: Configuration values are mapped to classes, reducing the risk of runtime errors due to typos or incorrect keys.
Centralized Configuration: Configuration values are managed in one place, typically in appsettings.json.
Dependency Injection: Configuration classes are injected into services, making them easy to use and test.

2. Why is the Options Pattern Important?

The Options Pattern is important because it promotes strongly-typed configuration, which has several benefits:

Compile-Time Safety: Since configuration values are mapped to classes, you get compile-time checks, reducing the likelihood of runtime errors.
Readability and Maintainability: Configuration values are easier to understand and maintain when they are grouped into meaningful classes.
Testability: Strongly-typed configuration makes it easier to mock and test configuration values in unit tests.

3. Use Case: Managing Static Role Information

Imagine a scenario where your application needs to manage a list of roles (e.g., ADMIN, USER, GUEST) that are static and defined in the appsettings.json file. These role names are used throughout the application, such as for authorization or logging purposes. You could store the role codes in the appsettings.json file along with the role Id. During runtime get the role Id based on role code. Use the role Id then to fetch further details like user role mapping from the database. The Options Pattern is an ideal solution for this scenario.

Example Configuration in appsettings.json:

{
  "RoleInformationOptions": {
    "Roles": [
      {
        "RoleId": "cf755bef-54b0-4117-a51c-36f6d8f9929f",
        "RoleCode": "ADMIN"
      },
      {
        "RoleId": "a1b2c3d4-5678-9101-1121-314151617181",
        "RoleCode": "USER"
      },
      {
        "RoleId": "b2c3d4e5-6789-1011-1213-415161718192",
        "RoleCode": "GUEST"
      }
    ]
  }
}

4. Implementation of the Options Pattern

Step 1: Define the Configuration Classes

Create a class to represent the configuration structure.

using System.Collections.Generic;

namespace Application.Options
{
    public class RoleInformationOption
    {
        public string RoleId { get; set; }//role identifier
        public string RoleCode { get; set; }//role name
    }

    public class RoleInformationOptions
    {
        public List<RoleInformationOption> Roles { get; set; }
    }
}

Step 2: Register the Configuration in Startup.cs

Bind the RoleInformationOptions section from appsettings.json to the RoleInformationOptions class.

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();

    // Register options for strongly-typed configuration
    services.AddOptions();
    services.Configure<RoleInformationOptions>(_configuration.GetSection("RoleInformationOptions"));

    // Register application services
    services.AddScoped<IEntityService, EntityService>();
}

Step 3: Inject and Use the Configuration in a Service

Inject the IOptions<RoleInformationOptions> into a service and use it to retrieve role information.

using System.Linq;
using Microsoft.Extensions.Options;

namespace Application.Services
{
    public class EntityService : IEntityService
    {
        private readonly RoleInformationOptions _roleOptions;

        public EntityService(IOptions<RoleInformationOptions> roleOptions)
        {
            _roleOptions = roleOptions.Value;
        }

        public string GetRoleIdByCode(string roleCode)
        {
            var role = _roleOptions.Roles.FirstOrDefault(r => r.RoleCode == roleCode);
            //TODO: make further database call based on RoleId to get additional info
            return role?.RoleId ?? "Role not found";
        }
    }
}

Step 4: Test the Configuration

Use the service in a controller to test the configuration.

using Microsoft.AspNetCore.Mvc;

namespace Web.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    public class RoleController : ControllerBase
    {
        private readonly IEntityService _entityService;

        public RoleController(IEntityService entityService)
        {
            _entityService = entityService;
        }

        [HttpGet("{roleCode}")]
        public IActionResult GetRoleId(string roleCode)
        {
            var roleId = _entityService.GetRoleIdByCode(roleCode);
            return Ok(new { RoleCode = roleCode, RoleId = roleId });
        }
    }
}

5. Summary

The Options Pattern in .NET Core is a powerful way to manage application configuration. By using strongly-typed classes, you can ensure compile-time safety, improve maintainability, and make your application more testable. In this article, we explored:

What the Options Pattern is and why it is important.
A practical use case for managing static role information.
Step-by-step implementation with relevant code samples.

By applying the Options Pattern, you can simplify configuration management and make your application more robust and maintainable.

Feature Management in .NET

Vimal — Wed, 14 May 2025 13:58:08 +0000

What is Feature management?

Feature management is a software development practice that allows teams to control the release and behavior of features in an application without deploying new code. It’s often implemented using feature flags (also called feature toggles), which are conditional statements in the code that turn features on or off based on configuration.

The Feature Manager in .NET, provided by the Microsoft.FeatureManagement library, is a tool that allows developers to manage and control application features dynamically. It is particularly useful for implementing feature flags or feature toggles, which enable or disable specific features in an application without requiring code changes or redeployment.

Significance of Feature Manager

Dynamic Feature Control:
- Features can be turned on or off at runtime based on configuration or external conditions.
- This allows for gradual rollouts, A/B testing, or enabling features for specific users or environments.
Safe Deployment:
- New features can be deployed in a "disabled" state and enabled only after testing or validation.
- This reduces the risk of introducing bugs or breaking changes in production.
Environment-Specific Features:
- Features can be enabled or disabled based on the environment (e.g., development, staging, production).
Targeted Feature Rollouts:
- Features can be enabled for specific users, groups, or conditions (e.g., premium users, beta testers).
Improved Development Workflow:
- Developers can work on features in parallel without worrying about incomplete features affecting production.
- Incomplete features can be hidden behind feature flags until they are ready.
Integration with Configuration Systems:
- Feature flags can be managed through configuration files (e.g., appsettings.json), external services, or Azure App Configuration.
Azure Integration:
- The Microsoft.FeatureManagement library integrates seamlessly with Azure App Configuration, allowing centralized management of feature flags across multiple applications.

Use Cases of Feature Manager

Gradual Rollouts: Enable a new feature for a small percentage of users and gradually increase the rollout.
A/B Testing: Test different versions of a feature to determine which performs better.
Hotfixes: Quickly disable a problematic feature without redeploying the application.
User-Specific Features: Enable features for specific user groups, such as beta testers or premium users.
Environment-Specific Features: Enable features only in specific environments, such as development or staging.

Example
Using the Feature Manager, you can define a feature flag in appsettings.json:

{
  "FeatureManagement": {
    "EnableNewFeature": true
  }
}

And control the feature in your code:

if (await _featureManager.IsEnabledAsync("EnableNewFeature"))
{
    // Execute the new feature logic
}
else
{
    // Fallback logic
}

In summary, the Feature Manager is a powerful tool for managing application features dynamically, improving flexibility, and reducing deployment risks. It is especially useful in modern development practices like DevOps, Continuous Integration/Continuous Deployment (CI/CD), and cloud-native applications.

Build a Chat App

Vimal — Wed, 14 May 2025 11:50:42 +0000

This is second part in the series Fresher's guide to Generative-AI. We will learn how to build a chat app that can answer questions using locally available LLMs in VS Code. This is possible with the AI Toolkit available as an extension in VS Code without the need for any subscription.

Step-by-Step Guide: Build a Chat App with AI Toolkit in VS Code

STEP 1: Install Prerequisites

Install Visual Studio Code (VS Code) from: https://code.visualstudio.com
Install the following extensions:

AI Toolkit: Search for "AI Toolkit" in the Extensions view and install it.
Python: For Python development and environment management.

Ensure Python 3.9 or newer is installed from: https://www.python.org/downloads

Verify installation:

python --version
pip --version

STEP 2: Set Up Your Project

Create a New Project Directory:

mkdir genai-chat-app
cd genai-chat-app

Initialize a Python Virtual Environment:

python -m venv venv

Activate the Virtual Environment:

Windows:

.\venv\Scripts\activate

macOS/Linux:

source venv/bin/activate

Install Required Python Libraries:

pip install streamlit

STEP 3: Install and Configure AI Toolkit

Launch VS Code.

Click on the AI Toolkit icon in the Activity Bar on the side.

Download a Local Model:

In the AI Toolkit view, go to MODELS > Catalog.
Use filters to find models that can run locally on your machine. For example, you can filter by "Model type" and select "Local run w/ GPU" or "Local run w/ CPU".
Choose a model suitable for your system's capabilities. For instance, models like Phi-3-mini-128k-cpu-int4-onnx are optimized for CPU usage.
Select the model and click on + Add button. The model will be downloaded and appear under My Models in the AI Toolkit.

Load the Model in the Playground:

Right-click on the downloaded model under MY MODELS.
Select Load in Playground to interact with the model and test its responses.

STEP 4: Build the Chat Application

Create a Python Script for the Chat App. In your project directory, create a new file named chat_app.py.

write the chat application code:

python

import streamlit as st
import requests

# Define the local API endpoint provided by AI Toolkit
API_URL = "http://127.0.0.1:5272/v1/chat/completions"

# Set up the Streamlit interface

st.title("Local GenAI Chatbot")

if "messages" not in st.session_state:
    st.session_state.messages = []


# Input field for user messages


user_input = st.text_input("You:", key="input")

if user_input:
    st.session_state.messages.append({"role": "user", "content": user_input})

    # Prepare the payload for the API request
    payload = {
        "model": "Phi-3-mini-128k-cpu-int4-onnx",  # Replace with your model's name
        "messages": st.session_state.messages
    }

    # Send the request to the local API
    response = requests.post(API_URL, json=payload)
    if response.status_code == 200:
        bot_reply = response.json()['choices'][0]['message']['content']
        st.session_state.messages.append({"role": "assistant", "content": bot_reply})
    else:
        st.error("Error: Unable to get response from the model.")


## Display the conversation

for msg in st.session_state.messages:
    st.markdown(f"**{msg['role'].capitalize()}:** {msg['content']}")

Run the Chat Application:

bash
streamlit run chat_app.py

This will start the Streamlit server and open the chat application in your default web browser.

STEP 5: Enhance and Explore

Here are few additional enhancements that can be made to the basic chat app.

Add Conversation Memory: Implement logic to maintain context over multiple interactions.
Customize Prompts: Modify the prompt structure to guide the model's responses.
Integrate Multi-Modal Inputs: Use AI Toolkit's support for attachments to handle images or files.
Deploy the Application: Consider deploying your application using platforms like Streamlit Cloud or Heroku for broader access.

✅ Summary

What we learnt so far:

Install VS Code and required extensions
Set up a Python project with a virtual environment
Install and configure AI Toolkit to download a local model
Build and run a chat application using Streamlit and the local model
Enhance the application with additional features and explore deployment options

Forem: Vimal

Modern Logging and Telemetry in .Net

Introduction

🎯 Article Objective

🔍 What is OpenTelemetry?

📘 Why Not Just Use Logging?

🎯 Why Use OpenTelemetry with Application Insights?

🛠️ Step-by-Step: Use OpenTelemetry in .NET 7

📦 Step 1: Add Required Packages

🧠 Step 2: Configure Program.cs

📂 Step 3: Create a Controller (TraceDemoController.cs)

⚙️ Step 4: Add Configuration (appsettings.json)

📊 Metrics You Get Automatically

🧪 Testing the API

📈 Viewing in Application Insights

Use:

✅ Summary

🧭 What’s Next?

🧠 Got Questions?

Managing NPM Registries in restricted environments

Problem statement:

Introduction

❌ Why Two package.json Files Is a Bad Idea

✅ The Right Way: Use .npmrc

Local Development Setup

.gitignore It!

Azure DevOps CI/CD Setup

✅ Option 1: Use Public NPM Registry (Recommended for Pipelines)

Option 2: Use Private Registry in CI/CD (If Required)

Full Azure DevOps Pipeline for Angular

Local vs CI/CD Setup

Key Takeaways

Bonus Tips

Use npmrc CLI for Switching

Scoped Packages

Wrapping Up

Designing for Dependency Injection — Think Like a Developer, Not a Container

Design Thinking First, DI Later

Step 1: Identify the Class's Responsibility

Step 2: Delegate Responsibilities via Abstractions

Step 3: Make It Testable and Flexible

Step 4: Let the Container Wire It Up

Summary: The Design-First DI Checklist

📌 Remember

Dependency Injection in .NET Core

Overview

Purpose

Types of Dependency Injection

1. Constructor Injection

Registration in .NET Core

2. Setter (Property) Injection

3. Interface Injection

Lifetimes in .NET DI

Dependency Graph

Benefits of DI

Real-world Example

Registration:

Usage:

Anti-Patterns to Avoid

Conclusion

Distribute iOS mobile applications(without App Store)

1. Free (“Personal”) Provisioning via Xcode

2. Paid Apple Developer Program (₹8,400/year)

Choosing Between the Two

Securely Managing Secrets in Configuration in .NET Applications

The Problem

Possible Solution

1. Set Environment Variable in Your Operating System

On Linux or macOS:

On Windows:

2. Verify the Environment Variable

On Linux/macOS:

On Windows (Command Prompt):

On Windows (PowerShell):

3. Access the Environment Variable in Your Application

4. Test the Configuration

Summary

Practical Caching in .NET: Strategies, Eviction, Keys, and Metrics

Key Objectives

Why Caching Matters

❌ Why Two `package.json` Files Is a Bad Idea

✅ The Right Way: Use `.npmrc`

`.gitignore` It!

Use `npmrc` CLI for Switching

1. Create the `DbContextFactory` Class

3. Add Configuration in `appsettings.json`