DEV Community: dotnet

Why your React Native app can't connect to your local .NET API (And how to fix it)

Muhammad Saad Bin Nadeem — Sun, 05 Apr 2026 05:58:17 +0000

You just built a beautiful .NET Core Web API. You test it in Swagger or Postman, and it works perfectly. It returns data instantly.

So, you open up your React Native Expo app, write a simple axios.get('http://localhost:5257/api/users'), press save, and... 💥 Network Error.

If you are testing on an Android emulator or a physical device, this error will drive you crazy. Here is exactly why it happens and how to set up your environment variables to fix it forever.

The Problem: What is "Localhost"?
When you type localhost inside your React Native code, the code is running inside the mobile device (or emulator).

To your computer, localhost means the computer itself.

To your Android emulator, localhost means the Android device's internal loopback network.

The emulator is literally looking inside itself for a .NET server that doesn't exist, failing, and throwing a Network Error.

The Solution: The Magic IP Addresses
To fix this, you need to point your mobile app to your computer's actual network address, depending on what you are testing on.

Testing on the iOS Simulator (Mac) Apple made this easy. The iOS simulator shares the host machine's network.

URL to use: http://localhost:

Testing on the Android Emulator Google built the Android emulator to run on an isolated virtual router. To break out of that router and talk to your computer's localhost, they provide a specific alias IP.

URL to use: http://10.0.2.2:

Testing on a Physical Device (iPhone or Android via Wi-Fi) If you are running the Expo app on your actual phone, neither localhost nor 10.0.2.2 will work. Your phone needs your computer's local Wi-Fi IP address.

Open your terminal and type ipconfig (Windows) or ifconfig (Mac).

Find your IPv4 address (it usually looks like 192.168.1.X or 10.0.0.X).

URL to use: http://192.168.1.X:
(Note: For this to work, you must ensure your .NET app is listening on your local IP, not just localhost. You can do this by running dotnet run --urls "http://0.0.0.0:")

The Best Practice: Environment Configuration
Instead of manually changing your Axios URLs every time you switch from iOS to Android, set up a dynamic config.

If you are using Expo, create a .env file at the root of your project:

Code snippet

# Change this depending on your testing device!
# iOS Simulator
# EXPO_PUBLIC_API_URL=http://localhost:5257/api

# Android Emulator
EXPO_PUBLIC_API_URL=http://10.0.2.2:5257/api

# Physical Device
# EXPO_PUBLIC_API_URL=http://192.168.1.45:5257/api

Then, configure your Axios instance once, and never touch it again:

TypeScript

import axios from 'axios';

const api = axios.create({
  baseURL: process.env.EXPO_PUBLIC_API_URL,
  headers: {
    'Content-Type': 'application/json',
  },
});

export default api;
Now, whenever you switch testing devices, you just uncomment the right line in your .env file, restart your Expo server with npx expo start -c (to clear the cache), and your API will connect flawlessly.

I hope this saved you a few hours of debugging! I build full-stack architectures and post weekly about React Native, .NET Core, and mobile enterprise solutions. Make sure to follow my profile here on Dev.to so you don't miss the next architecture breakdown!

reactnative, #dotnet, #javascript, and #beginners

Structuring Reusable Search Screens in Razor Pages

Y.Arakawa — Sun, 05 Apr 2026 03:19:39 +0000

Search screens look simple when you only have one or two of them.

That was not the situation I was dealing with.

I had many business screens with the same basic shape: a few search inputs, paging, sorting, and a table of results. The problem was not that any single screen was hard to build. The problem was that each new screen repeated the same query-building work in a slightly different way, and small changes started spreading across too many PageModel classes.

So the reason I changed the structure was straightforward: I wanted each screen to describe its own search conditions without re-implementing the same filtering and paging mechanics every time.

What worked better for me was to keep the search input on the PageModel, map those properties to entity fields with attributes, and let shared infrastructure build the EF Core query.

This is not a universal solution for every kind of search UI. It fits CRUD-heavy business screens where GET-based filtering, paging, and predictable extension matter more than highly custom search behavior.

The Shape I Wanted

The screen itself stays ordinary.

It is still a GET form with a results table.

@page
@model UsersModel

<form method="get">
    <div>
        <label asp-for="Name"></label>
        <input asp-for="Name" />
    </div>

    <div>
        <label asp-for="Phone"></label>
        <input asp-for="Phone" />
    </div>

    <button type="submit">Search</button>
</form>

<table>
    <!-- result rows -->
</table>

The important part is not the Razor markup. The important part is that search state stays in the query string, so reload, sharing, and debugging remain simple.

On the server side, I wanted the screen model to declare only the fields it cares about.

using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;

[BindProperties(SupportsGet = true)]
public abstract class SearchPageModel<TEntity> : PageModel where TEntity : BaseEntity
{
    protected readonly IRepository<TEntity> Repository;

    protected SearchPageModel(IRepository<TEntity> repository)
    {
        Repository = repository;
    }

    public int Skip { get; set; }
    public int Take { get; set; } = 20;
    public string? Order { get; set; }

    public PagedResult<TEntity>? Results { get; protected set; }

    public virtual async Task OnGetAsync()
    {
        var options = QueryOptionsBuilder.Build<TEntity>(this);
        Results = await Repository.QueryAsync(options);
    }
}

public sealed class UsersModel : SearchPageModel<User>
{
    public UsersModel(IRepository<User> repository) : base(repository)
    {
    }

    [Filter(FilterComparison.Contains, nameof(User.Name))]
    public string? Name { get; set; }

    [Filter(FilterComparison.Contains, nameof(User.Phone))]
    public string? Phone { get; set; }
}

That is the boundary I cared about.

The screen declares search intent.
Shared code handles the repetitive mechanics.

Moving Query Rules Out of the Screen

The small piece that made this scale better was a simple mapping attribute.

[AttributeUsage(AttributeTargets.Property, Inherited = true)]
public sealed class FilterAttribute : Attribute
{
    public FilterAttribute(FilterComparison comparison = FilterComparison.Equal, string? entityFieldName = null)
    {
        Comparison = comparison;
        EntityFieldName = entityFieldName;
    }

    public FilterComparison Comparison { get; }
    public string? EntityFieldName { get; }
}

public enum FilterComparison
{
    Equal,
    Contains,
    StartsWith
}

Then shared infrastructure reads those properties and turns them into query options.

using System.Linq.Expressions;
using System.Reflection;

public static class QueryOptionsBuilder
{
    public static QueryOptions<T> Build<T>(object conditions) where T : BaseEntity
    {
        var filters = new List<Expression<Func<T, bool>>>();

        foreach (var property in conditions.GetType().GetProperties(BindingFlags.Public | BindingFlags.Instance))
        {
            var filter = property.GetCustomAttribute<FilterAttribute>();
            var value = property.GetValue(conditions) as string;

            if (filter is null || string.IsNullOrWhiteSpace(value))
            {
                continue;
            }

            var entityFieldName = filter.EntityFieldName ?? property.Name;
            var parameter = Expression.Parameter(typeof(T), "x");
            var member = Expression.Property(parameter, entityFieldName);
            var contains = typeof(string).GetMethod(nameof(string.Contains), new[] { typeof(string) })!;
            var body = Expression.Call(member, contains, Expression.Constant(value.Trim()));

            filters.Add(Expression.Lambda<Func<T, bool>>(body, parameter));
        }

        // In a real implementation, sorting and paging would typically come from the request (e.g., UI input).
        // Hard-coded here for simplicity since they are not the focus of this article. 
        return new QueryOptions<T>(filters, orderBy: "Name ASC", skip: 0, take: 20);
    }
}

This example is intentionally simplified, but the design point is the same:
the PageModel should describe search fields, not rebuild query assembly logic over and over.

Why This Worked Better

The main benefit was not fewer lines of code by itself.

It was that the extension path became predictable.

If a screen needed one more condition, I added one property and one attribute.
If I wanted to adjust shared search behavior, I changed the infrastructure once.

Using nameof also removed a lot of fragile string matching between screen fields and entity fields, which matters more than it first appears when CRUD screens start multiplying.

This structure also kept the screens naturally URL-driven.
For this kind of business search screen, that is usually what I want.

Trade-Offs

This approach is useful when the search model is mostly declarative.

If a screen has deeply custom filtering rules, highly dynamic query composition, or search behavior that no longer maps cleanly to a property-per-condition model, I would not force it into this shape.

The point is not to abstract every search screen.
The point is to stop repeating the same mechanical work where the screens are actually similar.

Closing

What I wanted was simple: each screen should describe what it searches, and shared infrastructure should handle how the query gets assembled.

That boundary made Razor Pages search screens easier to extend without turning each PageModel into a copy of the previous one.

This kind of structural thinking is also part of what led me to build Cotomy. If you want the longer architectural background behind how I structure business-oriented web screens, I’ve been writing more of that here: https://blog.cotomy.net/

I Built an MCP Server That Understands Your MSBuild Project Graph — Before You Build

Florin Vica — Sat, 04 Apr 2026 19:25:32 +0000

Ask your AI coding assistant about your .NET solution structure and watch it hallucinate. It'll guess at project references, miss TFM mismatches, and confidently tell you things that aren't true — because it has no way to actually evaluate your MSBuild project files.

Existing tools like BinlogInsights require you to build first, then analyze the binary log. That's useful, but it means you need a successful build before you can ask questions. What if your solution is broken? What if you just want to understand the dependency graph before a migration?

I built MSBuild Graph MCP Server to fill this gap. It evaluates MSBuild project files directly — no build required — and exposes the results through 10 MCP tools that any AI assistant can call.

What It Does

Install it as a .NET global tool:

dotnet tool install -g MsBuildGraphMcp

Then ask your assistant natural questions:

"Show me the dependency graph for this solution" → full DAG with topological sort
"Are there any TFM mismatches?" → finds net6.0 projects referencing net8.0 libraries
"What breaks if I remove CoreLib?" → BFS traversal of all direct + transitive dependents
"Compare Debug vs Release" → property and package reference diffs
"Where does LangVersion come from?" → traces to Directory.Build.props, line 3

10 Tools, Grouped by Purpose

Understand Structure:

analyze_solution — parse .sln, .slnx, .slnf with full project metadata
get_project_graph — dependency DAG, topological sort, graph metrics
find_shared_imports — Directory.Build.props/.targets discovery
list_projects — fast listing, no MSBuild evaluation overhead

Find Issues:

detect_build_issues — TFM mismatches, orphans, circular deps, platform conflicts
check_package_versions — NuGet version consistency, CPM detection, VersionOverride

Analyze Impact:

analyze_impact — "what breaks if I touch project X?"
get_build_order — topological sort with critical path length

Compare & Inspect:

compare_configurations — diff any two build configurations
analyze_project_properties — property values with source file + line tracking

Plus 2 guided prompts: project-health-check (scores your solution 1-10) and migration-readiness (assesses .NET version upgrade feasibility).

We Predict. They Report.

Every other MSBuild MCP server does post-build analysis — they parse binary logs after compilation. That's retrospective. We do pre-build analysis: evaluating project files directly through MSBuild's ProjectGraph API.

	MSBuild Graph MCP	Binlog tools
Requires build	No	Yes
Works on broken solutions	Yes	No
Dependency analysis	Full DAG	Limited
TFM compatibility checking	Yes (NuGet.Frameworks)	No
Impact analysis	Yes	No
Configuration diff	Yes	No

This matters when you're planning a migration, onboarding to a large codebase, or debugging build issues in a solution that won't compile yet.

Security: 15 Measures, Zero Side Effects

All tools are read-only. No builds triggered, no files modified, no network requests, no arbitrary commands.

Highlights:

Startup guard blocks MSBUILDENABLEALLPROPERTYFUNCTIONS — mitigates CVE-2025-21172 (property function RCE)
Pre-evaluation XML scanner detects System.IO.File, System.Net, System.Diagnostics in project files before MSBuild evaluates them
IsBuildEnabled = false on all ProjectCollection instances — prevents target execution
UNC path rejection, extension whitelist, symlink detection, input length caps
Error sanitization strips user paths and stack traces from responses
Allowed directories via MSBUILD_MCP_ALLOWED_PATHS environment variable

MSBuild property functions execute during evaluation by design — this is the same trust model as opening a project in Visual Studio. Only analyze projects you trust.

333 Tests, 8 Bugs Caught

The test suite runs against real MSBuild APIs — no mocks. A TempSolutionBuilder fixture creates actual .sln/.slnx/.csproj files in temp directories for every test scenario.

This approach caught 8 production bugs during development, including:

CircularDependencyException not being caught (MSBuild throws this separately from MSB4251)
ToDictionary crash on duplicate PackageReferences (needed GroupBy first)
Resource leaks on exception paths (added try/finally cleanup)
Unbounded parallelism on 64-core machines (capped at 8)

All 333 tests pass in ~12 seconds on CI.

Get Started

Install:

dotnet tool install -g MsBuildGraphMcp

Claude Desktop — add to claude_desktop_config.json:

{
  "mcpServers": {
    "msbuild-graph": {
      "command": "msbuild-graph-mcp"
    }
  }
}

VS Code — add to .vscode/mcp.json:

{
  "servers": {
    "msbuild-graph": {
      "type": "stdio",
      "command": "msbuild-graph-mcp"
    }
  }
}

Claude Code:

claude mcp add msbuild-graph -- msbuild-graph-mcp

Also works with Cursor, Windsurf, and Visual Studio 2026 Preview.

Requires .NET SDK 8.0+ and Windows (MSBuildLocator discovers VS/.NET SDK installations).

Try It

Install with dotnet tool install -g MsBuildGraphMcp
Point your AI assistant at a .NET solution
Ask: "Run a project health check on this solution"

The project-health-check prompt runs all 10 tools and produces a scored report with actionable recommendations.

Links:

GitHub
NuGet

MIT licensed. Contributions welcome.

Agent Middleware in Microsoft Agent Framework 1.0

Seenivasa Ramadurai — Sat, 04 Apr 2026 19:14:54 +0000

A familiar pipeline pattern applied to AI agents

Covers three middleware types, registration scopes, termination, result override, and when to use each

Not a New Idea

If you have used ASP.NET Core or Express.js, you already understand the core concept. Both frameworks let you register a chain of functions around every request. Each function receives a context and a next() delegate. Calling next() continues the chain. Not calling it short circuits it. That is the pipeline pattern a clean way to apply cross cutting concerns like logging, authentication, and error handling without touching any business logic.

Microsoft’s Agent Framework applies this exact pattern to AI agents. The next() delegate becomes call_next(), the context object holds the agent’s conversation instead of an HTTP request, and the pipeline wraps an AI reasoning turn instead of a web request. If you know app.Use() or app.use(), you already know the shape of what follows.

What is new, and worth understanding deeply, is that an agent turn is not a single request/response cycle. It is a multi step reasoning loop, and Agent Framework exposes three distinct interception points within it. The rest of this post covers all three types, how they differ, when to use each, and how they come together in a real SQL agent example.

Middleware

The Agent Framework supports three types of middleware, each intercepting a different layer of execution:

Agent middleware wraps agent runs, giving you access to inputs, outputs, and overall control flow.
Function middleware wraps individual tool calls, enabling input validation, result transformation, and execution control.
Chat middleware wraps the underlying requests sent to AI models, exposing raw messages, options, and responses.

All three types support both function based and class based implementations.

Chaining

When multiple middleware of the same type are registered, they execute as a chain each middleware calls call_next() to hand off control to the next one in line.

Rather than passing updated values into call_next() as arguments, middleware mutates the shared context object directly. This means any changes you make to the context before calling call_next() are automatically visible to downstream middleware, with no need to thread values through the call explicitly.

Execution Order

Agent level middleware always wraps run level middleware. Given agent middleware [A1, A2] and run middleware [R1, R2], the execution order is:

A1 → A2 → R1 → R2 → Agent → R2 → R1 → A2 → A1

Function and chat middleware follow the same wrapping principle, applied at the time of each tool call or chat request respectively.

Why we need it

The biggest value is not convenience; it is correctness and consistency.

Without middleware, teams usually end up in one or both of these patterns:

Pattern 1: policy hidden in prompts

Example instruction:

"Never run destructive SQL. Never send data to personal email."

This is useful guidance, but it is still model behavior, not a hard gate. As prompts get long, tools increase, and edge cases appear, this policy can become inconsistent. It is also hard to audit after the fact.

Pattern 2: policy duplicated in each tool

def run_sql(query: str) -> str:
    if "drop" in query.lower():
        return "blocked"
    ...

def export_data(target: str) -> str:
    if "gmail.com" in target.lower():
        return "blocked"
    ...

def quote_inventory_line(quantity: int) -> str:
    if quantity > 10000:
        return "blocked"
    ...

This looks safe, but it creates:

duplicated logic
inconsistent rules across tools
expensive updates when policy changes

Middleware fixes both

With middleware, concerns live at the right boundary:

run level checks in Agent middleware
per tool checks in Function middleware
model call telemetry/metadata in Chat middleware

Result:

cleaner tools
stronger guardrails
easier tests
better observability

1. Agent Middleware-outermost layer

Agent middleware is the outermost layer of the pipeline. It fires once per turn before any LLM call is made and after the final reply or response is produced making it the right place for concerns that span the entire turn: input validation, security screening, audit logging, and output transformation.

Implementation Styles & Chaining

Agent middleware supports both class based and function based implementations both are fully equivalent, and the choice comes down to whether you need instance state or prefer a lighter syntax.
When multiple middleware components are registered, they form a chain. Each component is responsible for calling call_next() to pass control to the next layer; omitting this call short-circuits the pipeline, preventing any downstream middleware or the LLM from running.

Note that call_next() takes no arguments. Instead of passing updated values explicitly, middleware mutates the shared AgentContext object directly — any changes made before await call_next() are automatically visible to everything further down the chain.

Class-Based Implementation

Subclass AgentMiddleware and override process(). The example below shows SecurityAgentMiddleware It inspects the latest user message and short-circuits the pipeline if it detects a threat the LLM is never invoked for blocked requests.

class SecurityAgentMiddleware(AgentMiddleware):
    """Agent-level guard: blocks risky **user chat text** before the model runs.

    Inspects ``context.messages[-1]`` (latest user turn). If :func:`_unsafe_input_reason`
    returns a reason, sets ``context.result`` to a canned assistant reply and **does not**
    call ``call_next()``, so the LLM and tools are skipped for that turn.
    """

    async def process(
        self,
        context: AgentContext,
        call_next: Callable[[], Awaitable[None]],
    ) -> None:
        # Only the latest user utterance is checked (typical for a single-turn REPL).
        last_message = context.messages[-1] if context.messages else None
        if last_message and last_message.text:
            query = last_message.text
            reason = _unsafe_input_reason(query)
            if reason:
                print(f"[SecurityAgentMiddleware] Security Warning: {reason}; blocking request.")
                # Short-circuit: set the assistant reply here; do NOT call call_next() → no LLM, no tools.
                context.result = AgentResponse(
                    messages=[
                        Message(
                            "assistant",
                            [f"Request blocked: {reason}."],
                        )
                    ]
                )
                return

        print("[SecurityAgentMiddleware] Security check passed.")
        # Continue pipeline: model + optional run_sql; function middleware runs inside tool path.
        await call_next()

# here is the _unsafe_input_reason function & For brevity, I’ve omitted the full code.”

def _unsafe_input_reason(query: str) -> str | None:
    """Classify why a user message should be blocked, or ``None`` if it may proceed.

    Checks run in order: injection-style patterns first, then destructive natural language.
    """
    # Order matters: catch obvious SQL fragments before broader NL patterns.
    if _looks_like_dangerous_sql(query):
        return "injection-style or suspicious SQL fragment in your message"
    if _looks_like_destructive_database_intent(query):
        return "destructive database request (e.g. delete/drop/truncate)"
    return None

Function Based and Decorator Based Styles

Agent Framework also supports function based and decorator based implementations. All three styles are equivalent; choose based on whether you need state or explicit type annotations.

Function based

async def logging_agent_middleware(

context: AgentContext,

next: Callable[[AgentContext], Awaitable[None]],

) -> None:

print("[Agent] Turn starting")

await next(context)

print("[Agent] Turn completed")

Decorator-based (no type annotation required)

@agent_middleware

async def simple_agent_middleware(context, next):

print("Before agent execution")

await next(context)

print("After agent execution")

Registering Middleware

Middleware is registered when constructing the agent. Pass a list to the middleware argument different middleware types can be mixed in the same list and the framework routes each to the correct pipeline layer automatically:

FOUNDRY_PROJECT_ENDPOINT = "https://sreeniagent.services.ai.azure.com/api/projects/sreeni_foundry"
FOUNDRY_MODEL = "gpt-4.1"


async with (
    AzureCliCredential() as credential,
    Agent(
        client=FoundryChatClient(
            credential=credential,
            project_endpoint=FOUNDRY_PROJECT_ENDPOINT, # Your Microsoft Foundry project URL 
            model=FOUNDRY_MODEL, # The model you deployed 
        ),
        name="Sreeni-SqlAssistant",
        instructions=(
            "You help users query a small demo database. "
            "The only table is `customers` with columns id, name, city. "
            "Always use the run_sql tool with a proper SELECT; explain results briefly."
        ),
        tools=run_sql,
        # Agent middleware wraps the turn; function middleware wraps each tool call
        middleware=[SecurityAgentMiddleware(), LoggingFunctionMiddleware()],
    ) as agent,
):

When to Use Agent Middleware

Agent middleware is the right choice for any concern that applies to the turn as a whole, rather than to a specific tool call or model request.

2.FunctionMiddleware- The ToolCall Layer

FunctionMiddleware fires inside the agent turn, but only when the LLM decides to invoke a tool. A single agent turn can trigger multiple tool calls, and FunctionMiddleware wraps each one independently. This makes it the right place for concerns that are specific to tool execution: timing, input validation, result transformation, and tool call auditing.

The FunctionInvocationContext Object

Each FunctionMiddleware component receives a FunctionInvocationContext, which is scoped to a single tool invocation:

When to Use FunctionMiddleware

Use it for concerns specific to tool execution the execution timing and performance monitoring, validating or sanitising tool arguments before they run, capping the number of times a tool may be called in one turn, transforming tool results before the LLM sees them, or auditing exactly which tools were called and with what arguments.

Terminating the Function Calling Loop

Setting context.terminate = True inside FunctionMiddleware does something powerful: it stops the LLM’s function calling loop entirely. The LLM will not receive the tool result and will not make any further tool calls in this turn. This is useful for enforcing tool call budgets or stopping a loop that is going in an undesirable direction.


@function_middleware

async def budget_middleware(context, next):

 if context.function.name == "run_sql":

 # Allow at most one SQL query per turn

 call_count = context.metadata.get("sql_calls", 0)

 if call_count >= 1:

 context.result = "Query limit reached for this turn."

 context.terminate = True  # stop the LLM tool-calling loop

 return

 context.metadata["sql_calls"] = call_count + 1

 await next(context)

Warning: Termination and Chat History

Terminating the function calling loop can leave the chat history in an inconsistent state a tool-call message with no corresponding tool result. This may cause errors if the same history is used in subsequent agent runs. Use termination carefully and consider clearing or repairing the history afterward.

3. ChatMiddleware —The LLM Call Layer

ChatMiddleware is the deepest layer. It wraps the actual inference call sent to the underlying language model the raw list of messages, the model options, and the response that comes back. This layer fires for every call to the LLM within a turn, which can be more than one if tools are used.

The ChatContext Object

Each ChatMiddleware component receives a ChatContext.

Function Based Example


  async def logging_chat_middleware(

  context: ChatContext,

  next: Callable[[ChatContext], Awaitable[None]],

  ) -> None:

  print(f"[Chat] Sending {len(context.messages)} messages to model")

  await next(context)

  print("[Chat] Model response received")

Because ChatMiddleware sees the exact message list going to the model, it can be used to inject system instructions, strip sensitive content, enforce token budgets, or even substitute a cached response all without the AgentMiddleware or FunctionMiddleware layers knowing anything changed.

When to Use ChatMiddleware

Use it when you need access to the raw LLM call: injecting or modifying system level instructions per call, redacting PII from messages before they leave your infrastructure, enforcing token count limits, caching repeated inference calls, or monitoring every model request for compliance purposes.

Registration: Agent Level vs. Run Level (run scope)

Microsoft Agent Framework supports two scopes for registering middleware. Understanding the difference is important for designing flexible agent systems.

Agent Level Middleware

Middleware passed in the middleware=[...] list when constructing the Agent applies to every single call to agent.run() for the lifetime of that agent. This is where you put policies that should always be enforced: security guards, mandatory audit logging, content filters.

Run Level Middleware

You can also pass middleware directly to a single agent.run() call. This middleware applies only to that one invocation and is discarded afterward. It is useful for per request customisation: adding a trace ID for a specific call, applying extra validation for a sensitive operation, or attaching a debug logger without affecting every other turn.

Choosing the Right Middleware Type

With three types available, the choice usually comes down to what you need to see and at what granularity.

Conclusion

Microsoft Agent Framework’s middleware brings the same pipeline contract you know from ASP.NET Core and Express ordered components, a context object, and a call_next() delegate into the world of AI agents. The structural difference is that an agent turn is not a single request/response cycle but a multi-step reasoning loop, and Agent Framework exposes three separate interception points within it.

AgentMiddleware is the right home for turn level concerns: security screening, content policy, and audit logging.

FunctionMiddleware is the right home for tool level concerns: execution timing, argument validation, and tool call budgets.

ChatMiddleware is the right home for model level concerns: raw message inspection, token enforcement, and caching.

Thanks
Sreeni Ramadorai

How I built a 20MB Native C# alternative to a 100MB+ Electron app

KeyVibe — Sat, 04 Apr 2026 17:03:06 +0000

Hi everyone! 👋

I love the sound of mechanical keyboards, and sometimes I use software to emulate those sounds when typing on a quiet laptop. But I noticed a frustrating trend: most popular apps for this (like Mechvibes) are built on Electron.

They consume over 100MB of RAM just to play simple .wav files in the background! As a developer who cares about optimization, that felt like a huge waste of resources.

So, I decided to build my own solution using Native C#.

Enter KeyVibe ⌨️

KeyVibe is a native utility app that plays customizable mechanical keyboard sounds while you type.

Key Features:

📉 Ultra-Lightweight: It uses only ~20MB of RAM and <1% CPU.
⚡ Zero Latency: By using low-level global keyboard hooks in C#, the sound feedback is instant.
🎨 Customizable: You can map different sounds to specific key groups.

Try it out!

My newly completed project. Sharing for anyone interested in saving some RAM!

📥 Download: https://github.com/KeyVibeOfficial/KeyVibe/releases/
🛡️ Security: To save you any worries about running a new .exe, here is the VirusTotal scan (0/71 clean): https://www.virustotal.com/gui/file/698d0d0877646eee5afc40d793c3c5b99df86d8c087fadca886e1c0f33e9ff4f/detection
I'd love to hear your feedback! Let me know what you think.

BRAND IDENTITY DESIGN SERVICE

Get The Design — Sat, 04 Apr 2026 16:17:49 +0000

BRAND IDENTITY DESIGN SERVICE

https://www.getthedesign.com/service/brand-identity-design-service/

If your brand online needs a revitalized image or a complete rebranding, Get The Design is an agency company here to assist you.
BEST BRAND IDENTITY DESIGNS Remember best brands are the ones designed, delivered, and used by the clients

Why I Stopped Using Local PDF Libraries in my Docker Microservices

Andrea Lima — Sat, 04 Apr 2026 14:02:24 +0000

If you’ve ever built a .NET or Node.js app that generates PDFs, you know the drill. It works perfectly on your Windows/Mac development machine. Then, you deploy it to a Linux-based Docker container, and boom:

System.Drawing.Common throws a GDI+ error.

The PDF renders, but all the fonts are replaced by weird squares.

The container size doubles because you had to install libgdiplus, fontconfig, and a bunch of X11 dependencies.

The "Dependency Hell" of PDF Engines
Most popular libraries (like iText, Puppeteer, or older versions of QuestPDF) rely on underlying OS graphics libraries. In a microservices world, this is a nightmare:

Bloated Images: Your lightweight Alpine image is no longer lightweight.

Memory Leaks: Many wrappers for PDF generation aren't great at disposing of unmanaged resources.

Inconsistency: A table that looks perfect in Dev might have slight alignment issues in your CI/CD pipeline due to different library versions in the Linux distro.

Moving to a Stateless, API-First Approach
Recently, I decided to offload this entire "heavy lifting" to a dedicated microservice. Instead of fighting with libgdiplus in every new project, I built a stateless API: SwiftInvoice.

The logic is simple: Your app shouldn't be a printing press. It should just handle data.

By using an external API, my Dockerfiles went from this:

# The "Heavy" way
FROM mcr.microsoft.com/dotnet/aspnet:8.0
RUN apt-get update && apt-get install -y libgdiplus libx11-6 && ln -s /usr/lib/libgdiplus.so /usr/lib/gdiplus.dll
# ... more font configurations ...

To this:

# The "Clean" way
FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine
# Just your app. The API handles the rest.

Quick Win: Professional Invoices in Seconds
I integrated Native PIX support (for Brazilian markets) and I18n (EN, PT, ES) directly into the engine. You just POST a JSON, and you get a clean, print-ready PDF stream back.

Example (Node.js):

JavaScript

const axios = require('axios');
const fs = require('fs');

const generateInvoice = async () => {
    const options = {
        method: 'POST',
        url: 'https://swiftinvoice.p.rapidapi.com/GenerateInvoice',
        headers: {
            'content-type': 'application/json',
            'X-RapidAPI-Key': 'YOUR_RAPIDAPI_KEY', // Get it at rapidapi.com
            'X-RapidAPI-Host': 'swiftinvoice.p.rapidapi.com'
        },
        data: {
            // Document Info
            InvoiceNumber: "2026-001",
            Language: "pt-BR", // Supports pt-BR, en-US, es-ES
            Currency: "BRL",
            IssueDate: new Date().toISOString(),
            DueDate: "2026-04-15T00:00:00Z",
            Template: "blue", // Design theme
            IsDraft: false,

            // Sender Info
            SenderName: "Your Company Name",
            SenderCity: "Rio de Janeiro",
            SenderDocument: "00.000.000/0001-00", // CNPJ/CPF
            LogoUrl: "https://yourlink.com/logo.png",

            // Recipient Info
            RecipientName: "Client XYZ",
            RecipientAddress: "Main Street, 123",
            CustomerEmail: "client@email.com",

            // Items & Billing
            Items: [
                { Description: "Software Development", Quantity: 1, UnitPrice: 1500.00 },
                { Description: "Cloud Maintenance", Quantity: 1, UnitPrice: 50.00 }
            ],
            TaxRate: 0,
            DiscountAmount: 0,

            // Payment & PIX
            PixKey: "your-pix-key@provider.com", // Native QR Code generation
            BankName: "Banco do Brasil",
            Agency: "0001",
            AccountNumber: "12345-6"
        },
        responseType: 'arraybuffer'
    };

    try {
        const response = await axios.request(options);
        fs.writeFileSync('invoice.pdf', response.data);
        console.log('✅ PDF successfully generated: invoice.pdf');
    } catch (error) {
        console.error('❌ Error details:', error.response ? error.response.data.toString() : error.message);
    }
};

generateInvoice();

Update: I've just released a repository with full boilerplate examples in C#, Node.js, Python, PHP, and Go! Check it out here.

Conclusion
Focus on your business logic, not on debugging Linux font rendering. If you want to try this approach, I’ve made SwiftInvoice available on RapidAPI with a Free Tier for developers to experiment with.

👉 Check it out here: SwiftInvoice on RapidAPI

I'm curious: How are you handling PDF generation in your current stack? Are you still using local libraries or have you moved to a service-based model?

Modernizing .NET Architectures for AI-Native Workloads

Elvin Suleymanov — Sat, 04 Apr 2026 12:38:01 +0000

For the past decade, .NET architects have been perfecting a craft. Clean separation of concerns. Domain-driven design. Event-driven microservices. CQRS. Hexagonal architecture. The patterns are mature, battle-tested, and well-understood. Teams have learned how to build systems that are reliable, maintainable, and scalable.

Then AI arrived - not as a feature, but as an expectation.

Not the AI of a sentiment analysis endpoint bolted onto the side of an API. Not a classification model embedded in a background job. The new expectation is AI that reasons across your entire domain, remembers context across sessions, orchestrates multi-step workflows autonomously, and integrates with every surface of your product simultaneously.

This is what it means to be AI-native. And it does not fit cleanly into the architectures most .NET teams built over the last decade.

This article is a practical guide to bridging that gap. We will examine how to evolve a modern .NET architecture to support AI-native workloads - without discarding everything you have built and without compromising the engineering discipline that makes .NET systems trustworthy.

Who is this for? Senior .NET engineers, architects, and tech leads who are integrating AI deeply into production systems and need a structural framework for doing it correctly.

What AI-Native Actually Means
Why Traditional .NET Architectures Struggle with AI
The AI-Native Architecture Stack
Semantic Kernel as the AI Orchestration Layer
Designing AI-Aware Domain Models
Vector Storage and Semantic Memory in .NET
The Agent Pattern: Autonomous AI in Your Domain
Streaming AI Responses with ASP.NET Core
Observability for AI Workloads
Guardrails: Safety, Cost Control, and Responsible AI
Real-World Walkthrough: AI-Native CRM Feature
Migration Path: Evolving an Existing .NET System

1. What AI-Native Actually Means

The term AI-native is used loosely in the industry, so let us define it precisely for the context of .NET architecture.

An AI-native system is one in which the AI capability is structurally integrated into the architecture - not added as a feature on top of it. The difference matters enormously in practice.

Consider two approaches to adding a "smart contract summarization" feature to a legal SaaS product.

The first approach creates a new API endpoint, calls an LLM from inside a service method, returns the result. The AI is a black box embedded in a single method in a single service. It has no awareness of the domain model, no memory of previous interactions, no ability to take follow-up actions, and no path for the engineering team to reason about what the AI actually did or why.

The second approach models the AI capability as a first-class architectural concern. The AI orchestrator knows the domain. It has access to the company's private knowledge base via semantic search. It can take actions in the system - drafting a document, flagging a clause, notifying a reviewer - via well-defined tool interfaces. Every AI interaction is observable, traceable, and auditable. The LLM provider is an infrastructure dependency, not a hardcoded implementation detail.

The second approach is AI-native. It is also significantly harder to build. This article gives you the framework to do it correctly.

2. Why Traditional .NET Architectures Struggle with AI

The Clean Architecture and Domain-Driven Design patterns that .NET teams have embraced are fundamentally synchronous, deterministic, and stateless between requests. A command handler receives input, applies business rules, persists state, and returns. The output is predictable given the input. The execution time is bounded and measurable.

AI workloads break every one of these assumptions.

LLM calls are slow. A single inference call to GPT-4o or Claude 3.7 takes anywhere from 500ms to 30 seconds depending on the prompt length and output complexity. An application command handler that takes 15 seconds to complete will time out, exhaust thread pool resources, and generate a torrent of support tickets.

LLM outputs are non-deterministic. Two identical prompts with the same model can produce subtly different outputs. Unit tests that assert on exact string output will fail randomly. Deterministic business logic cannot assume deterministic AI output.

AI workflows are long-running and stateful. An agent that researches a topic, drafts a document, asks the user for clarification, incorporates the feedback, and then publishes the result is not a request-response operation. It is a workflow that spans multiple turns, potentially across multiple sessions. The request-scoped dependency injection lifetime and the stateless HTTP handler model do not accommodate this naturally.

AI introduces external costs per call. Every LLM call costs money in API tokens. Traditional architectures have no concept of per-call economic cost - there is no mechanism to budget, throttle, or optimize LLM usage without building it explicitly.

The context window is a shared resource. An LLM call is not just "pass input, get output." The entire conversation history, retrieved documents, tool definitions, and system prompt all compete for space inside a fixed context window. Managing this window is a first-class engineering problem that has no analog in traditional CRUD architecture.

These are not minor inconveniences. They are fundamental mismatches between the assumptions embedded in traditional .NET architecture and the requirements of AI-native workloads. Addressing them requires structural changes, not just new NuGet packages.

3. The AI-Native Architecture Stack

Before writing any code, it helps to visualize how an AI-native .NET system is layered. The following stack extends the familiar Clean Architecture layers with the AI-specific concerns that sit between the application layer and the external AI infrastructure.

┌──────────────────────────────────────────────────────────────────┐
│                        Presentation Layer                        │
│          ASP.NET Core Minimal APIs   Blazor   gRPC               │
│          Streaming responses    WebSockets    SignalR             │
├──────────────────────────────────────────────────────────────────┤
│                      AI Orchestration Layer          ← NEW       │
│          Semantic Kernel Kernel      Agent runtime               │
│          Planner    Memory manager   Plugin registry             │
│          Prompt template engine      Token budget manager        │
├──────────────────────────────────────────────────────────────────┤
│                       Application Layer                          │
│          Command / Query handlers    Domain services             │
│          AI Tool implementations    Workflow coordinators        │
├──────────────────────────────────────────────────────────────────┤
│                        Domain Layer                              │
│          Entities    Value objects    Domain events              │
│          AI-aware aggregates         Semantic metadata           │
├──────────────────────────────────────────────────────────────────┤
│                     Infrastructure Layer                         │
│          PostgreSQL    Redis    Blob storage                      │
│          Vector DB (pgvector / Qdrant / Azure AI Search)         │
│          LLM providers (OpenAI / Azure OpenAI / Anthropic)       │
│          Embedding providers    Observability (OTEL)             │
└──────────────────────────────────────────────────────────────────┘

The AI Orchestration Layer is the critical addition. It is not part of the domain - it does not contain business rules. It is not part of the infrastructure - it is not a database driver or an HTTP client. It is the translation layer between your domain logic and the probabilistic, non-deterministic, token-consuming world of large language models. Keeping it as a distinct layer is what makes the rest of the architecture testable, maintainable, and provider-agnostic.

4. Semantic Kernel as the AI Orchestration Layer

Microsoft's Semantic Kernel is the .NET ecosystem's answer to the AI orchestration problem. It provides the abstractions that allow you to build the AI Orchestration Layer without coupling your application to a specific LLM provider, embedding model, or vector store.

The core concept in Semantic Kernel is the Kernel - a dependency injection container for AI services and plugins. Everything flows through it.

// Program.cs - register Semantic Kernel with all AI services
builder.Services.AddKernel()
    .AddAzureOpenAIChatCompletion(
        deploymentName: config["AzureOpenAI:DeploymentName"]!,
        endpoint: config["AzureOpenAI:Endpoint"]!,
        apiKey: config["AzureOpenAI:ApiKey"]!)
    .AddAzureOpenAITextEmbeddingGeneration(
        deploymentName: config["AzureOpenAI:EmbeddingDeployment"]!,
        endpoint: config["AzureOpenAI:Endpoint"]!,
        apiKey: config["AzureOpenAI:ApiKey"]!)
    .Plugins
        .AddFromType<CustomerPlugin>()
        .AddFromType<ContractPlugin>()
        .AddFromType<NotificationPlugin>();

// Register vector memory store
builder.Services.AddSingleton<IVectorStore>(sp =>
    new QdrantVectorStore(new QdrantClient("localhost")));

Plugins as domain capability exposure

The Plugin system is how you expose your domain to the AI. A plugin is a C# class whose public methods are decorated with [KernelFunction] and natural-language descriptions. The AI reads these descriptions and decides which functions to call and in what order based on the user's intent.

public sealed class CustomerPlugin
{
    private readonly ICustomerRepository _customers;
    private readonly IOrderRepository    _orders;

    public CustomerPlugin(
        ICustomerRepository customers,
        IOrderRepository orders)
    {
        _customers = customers;
        _orders    = orders;
    }

    [KernelFunction]
    [Description("Retrieve a customer profile including contact details, " +
                 "subscription plan, and account status.")]
    public async Task<CustomerDto> GetCustomerProfileAsync(
        [Description("The unique customer identifier (UUID)")]
        string customerId,
        CancellationToken cancellationToken = default)
    {
        var customer = await _customers.GetByIdAsync(
            Guid.Parse(customerId), cancellationToken);

        return customer is null
            ? throw new CustomerNotFoundException(customerId)
            : CustomerDto.FromDomain(customer);
    }

    [KernelFunction]
    [Description("List the most recent orders for a customer, " +
                 "sorted newest first. Returns order status, total, and items.")]
    public async Task<IReadOnlyList<OrderSummaryDto>> GetRecentOrdersAsync(
        [Description("The unique customer identifier (UUID)")]
        string customerId,
        [Description("Maximum number of orders to return. Default is 10.")]
        int limit = 10,
        CancellationToken cancellationToken = default)
    {
        var orders = await _orders.GetRecentByCustomerAsync(
            Guid.Parse(customerId), limit, cancellationToken);

        return orders.Select(OrderSummaryDto.FromDomain).ToList();
    }

    [KernelFunction]
    [Description("Update the subscription plan for a customer. " +
                 "Valid plans are: starter, professional, enterprise.")]
    public async Task<string> UpdateSubscriptionPlanAsync(
        [Description("The unique customer identifier (UUID)")]
        string customerId,
        [Description("The new subscription plan name")]
        string planName,
        CancellationToken cancellationToken = default)
    {
        await _customers.UpdatePlanAsync(
            Guid.Parse(customerId), planName, cancellationToken);

        return $"Successfully updated customer {customerId} to {planName} plan.";
    }
}

The descriptions you write on [KernelFunction] and each parameter are not comments - they are the interface between your code and the language model. The quality of your function descriptions directly determines the reliability of the AI's decisions about when and how to call them. This is description engineering, and it is one of the most underappreciated skills in AI-native .NET development.

5. Designing AI-Aware Domain Models

A traditional domain entity is designed to support business rules enforced by application code. An AI-aware domain entity also needs to support semantic understanding - the ability for an AI to reason about what the entity means, not just what fields it has.

This is a subtle but important distinction. Consider a Contract entity in a legal SaaS:

// Traditional domain entity
public sealed class Contract
{
    public Guid   Id            { get; private set; }
    public string Title         { get; private set; }
    public string FullText      { get; private set; }
    public ContractStatus Status { get; private set; }
    public DateTimeOffset EffectiveDate { get; private set; }
    public DateTimeOffset ExpiryDate    { get; private set; }

    // Business rules enforced in domain
    public void Approve(UserId approver)
    {
        if (Status != ContractStatus.PendingReview)
            throw new DomainException("Only contracts pending review can be approved.");

        Status = ContractStatus.Approved;
        AddDomainEvent(new ContractApprovedEvent(Id, approver));
    }
}

// AI-aware domain entity adds semantic metadata
public sealed class Contract
{
    public Guid   Id            { get; private set; }
    public string Title         { get; private set; }
    public string FullText      { get; private set; }
    public ContractStatus Status { get; private set; }
    public DateTimeOffset EffectiveDate { get; private set; }
    public DateTimeOffset ExpiryDate    { get; private set; }

    // Semantic metadata - generated asynchronously after entity creation
    public string?          AiSummary       { get; private set; }
    public IReadOnlyList<string> KeyClauses { get; private set; } = [];
    public IReadOnlyList<string> RiskFlags  { get; private set; } = [];
    public float[]?         EmbeddingVector { get; private set; }
    public DateTimeOffset?  LastIndexedAt   { get; private set; }

    public void ApplySemanticAnalysis(
        string summary,
        IReadOnlyList<string> clauses,
        IReadOnlyList<string> risks,
        float[] embedding)
    {
        AiSummary       = summary;
        KeyClauses      = clauses;
        RiskFlags       = risks;
        EmbeddingVector = embedding;
        LastIndexedAt   = DateTimeOffset.UtcNow;

        AddDomainEvent(new ContractIndexedEvent(Id));
    }

    // Business rules unchanged - domain integrity is not AI's responsibility
    public void Approve(UserId approver)
    {
        if (Status != ContractStatus.PendingReview)
            throw new DomainException("Only contracts pending review can be approved.");

        Status = ContractStatus.Approved;
        AddDomainEvent(new ContractApprovedEvent(Id, approver));
    }
}

The semantic metadata lives in the domain entity, but it is never set by the AI directly. The domain event pipeline triggers an asynchronous background job that calls the AI, generates the semantic analysis, and then calls ApplySemanticAnalysis through a proper command. The domain's integrity is preserved. The AI capability is additive, not structural.

6. Vector Storage and Semantic Memory in .NET

Vector storage is the persistence layer of AI-native systems. It stores embedding vectors alongside their source content and metadata, enabling semantic search - finding documents that are meaningfully similar to a query rather than just lexically matching keywords.

In a .NET system, the vector store is infrastructure. It belongs in the Infrastructure layer and is accessed through an interface defined in the Domain or Application layer.

// Application layer interface - no vector store dependency
public interface IContractSemanticSearch
{
    Task<IReadOnlyList<ContractSearchResult>> SearchAsync(
        string query,
        int maxResults = 10,
        float minSimilarity = 0.7f,
        CancellationToken ct = default);

    Task IndexContractAsync(
        Guid contractId,
        string content,
        ContractMetadata metadata,
        CancellationToken ct = default);
}

// Infrastructure implementation - Qdrant vector store
public sealed class QdrantContractSemanticSearch : IContractSemanticSearch
{
    private const string CollectionName = "contracts";

    private readonly QdrantClient                   _qdrant;
    private readonly ITextEmbeddingGenerationService _embeddings;

    public QdrantContractSemanticSearch(
        QdrantClient qdrant,
        ITextEmbeddingGenerationService embeddings)
    {
        _qdrant     = qdrant;
        _embeddings = embeddings;
    }

    public async Task<IReadOnlyList<ContractSearchResult>> SearchAsync(
        string query,
        int maxResults = 10,
        float minSimilarity = 0.7f,
        CancellationToken ct = default)
    {
        // Generate embedding for the search query
        var queryEmbedding = await _embeddings.GenerateEmbeddingAsync(query, ct);

        // Vector similarity search in Qdrant
        var results = await _qdrant.SearchAsync(
            collectionName: CollectionName,
            vector: queryEmbedding.ToArray(),
            limit: (ulong)maxResults,
            scoreThreshold: minSimilarity,
            cancellationToken: ct);

        return results
            .Select(r => new ContractSearchResult(
                ContractId: Guid.Parse(r.Payload["contract_id"].StringValue),
                Title:       r.Payload["title"].StringValue,
                Summary:     r.Payload["summary"].StringValue,
                Similarity:  r.Score))
            .ToList();
    }

    public async Task IndexContractAsync(
        Guid contractId,
        string content,
        ContractMetadata metadata,
        CancellationToken ct = default)
    {
        // Chunk large contracts into overlapping segments
        var chunks = ChunkText(content, chunkSize: 512, overlap: 64);

        var points = new List<PointStruct>();

        foreach (var (chunk, index) in chunks.Select((c, i) => (c, i)))
        {
            var embedding = await _embeddings.GenerateEmbeddingAsync(chunk, ct);

            points.Add(new PointStruct
            {
                Id     = new PointId { Uuid = Guid.NewGuid().ToString() },
                Vectors = new Vectors { Vector = new Vector { Data = { embedding } } },
                Payload =
                {
                    ["contract_id"]  = contractId.ToString(),
                    ["title"]        = metadata.Title,
                    ["summary"]      = metadata.AiSummary ?? "",
                    ["chunk_index"]  = index,
                    ["effective_date"] = metadata.EffectiveDate.ToString("O"),
                }
            });
        }

        await _qdrant.UpsertAsync(CollectionName, points, cancellationToken: ct);
    }

    private static IReadOnlyList<string> ChunkText(
        string text, int chunkSize, int overlap)
    {
        var words  = text.Split(' ', StringSplitOptions.RemoveEmptyEntries);
        var chunks = new List<string>();

        for (int i = 0; i < words.Length; i += chunkSize - overlap)
        {
            var chunk = string.Join(' ', words.Skip(i).Take(chunkSize));
            if (!string.IsNullOrWhiteSpace(chunk))
                chunks.Add(chunk);

            if (i + chunkSize >= words.Length)
                break;
        }

        return chunks;
    }
}

Choosing your vector store

pgvector is the pragmatic choice for teams already running PostgreSQL. It adds vector similarity search as a PostgreSQL extension, keeping your operational footprint minimal. It handles tens of millions of vectors efficiently and supports HNSW indexing for fast approximate nearest-neighbor search.

Qdrant is purpose-built for vector search at scale. It supports filtering on payload metadata alongside vector similarity, which is essential for multi-tenant systems where you need to restrict search results by tenant before computing similarity.

Azure AI Search is the managed option for teams on Azure. It combines traditional keyword search with vector search in a single index, handles chunking and embedding generation natively, and integrates directly with Azure OpenAI.

7. The Agent Pattern: Autonomous AI in Your Domain

An agent is an AI component that can reason about a goal, decide what tools to use, call those tools in sequence, observe the results, adjust its plan, and iterate until the goal is achieved or it determines it cannot proceed further.

In .NET terms, an agent is a Semantic Kernel feature that combines a chat model with a set of plugins and a planning strategy. The agent pattern is powerful and genuinely dangerous if implemented naively - an autonomous component that can call your domain methods without human approval is a significant risk surface.

// Define an agent scoped to a specific workflow
public sealed class ContractReviewAgent
{
    private readonly Kernel              _kernel;
    private readonly IAgentAuditLogger  _audit;
    private readonly ITokenBudgetService _budget;

    public ContractReviewAgent(
        Kernel kernel,
        IAgentAuditLogger audit,
        ITokenBudgetService budget)
    {
        _kernel = kernel;
        _audit  = audit;
        _budget = budget;
    }

    public async IAsyncEnumerable<AgentUpdate> ReviewContractAsync(
        Guid contractId,
        string userInstruction,
        AgentRunContext context,
        [EnumeratorCancellation] CancellationToken ct = default)
    {
        // Enforce token budget before starting
        var remainingBudget = await _budget.GetRemainingAsync(context.TenantId, ct);
        if (remainingBudget < 5_000)
        {
            yield return AgentUpdate.Error("Insufficient token budget for this operation.");
            yield break;
        }

        // Build agent with only the plugins relevant to contract review
        // Principle of least privilege: do not give the agent tools it does not need
        var agent = new ChatCompletionAgent
        {
            Name = "ContractReviewAgent",
            Kernel = _kernel.Clone(),
            Instructions = """
                You are a contract review assistant. Your job is to analyze the
                specified contract and provide a structured review covering:

                1. A plain-English summary of what the contract covers.
                2. Key obligations for each party.
                3. Any unusual or high-risk clauses that should be flagged for
                   human legal review.
                4. Recommended questions the reviewer should clarify before signing.

                Always retrieve the full contract text before writing your review.
                Do not make assumptions about contract content you have not retrieved.
                """,
            Arguments = new KernelArguments(
                new OpenAIPromptExecutionSettings
                {
                    ToolCallBehavior = ToolCallBehavior.AutoInvokeKernelFunctions,
                    MaxTokens        = Math.Min(remainingBudget, 4_096),
                    Temperature      = 0.1  // Low temperature for analytical tasks
                })
        };

        // Scoped plugins - only what this agent needs
        agent.Kernel.Plugins.AddFromType<ContractPlugin>();
        agent.Kernel.Plugins.AddFromType<LegalReferencePlugin>();

        var history = new ChatHistory();
        history.AddUserMessage(
            $"Please review contract {contractId}. Additional context: {userInstruction}");

        // Stream agent responses and intermediate steps
        await foreach (var message in agent.InvokeStreamingAsync(history, ct))
        {
            // Log every tool call for audit trail
            if (message.Content?.Contains("tool_call") == true)
                await _audit.LogToolCallAsync(context, message.Content, ct);

            // Deduct token usage from budget
            if (message.Metadata?.TryGetValue("usage", out var usage) == true)
                await _budget.DeductAsync(context.TenantId, usage, ct);

            yield return AgentUpdate.Progress(message.Content ?? "");
        }
    }
}

The principle of least privilege for agents

The single most important safety rule for agent design is to give each agent only the tools it needs for its specific task. A ContractReviewAgent should not have access to the NotificationPlugin or the BillingPlugin. A CustomerSupportAgent should be able to read customer data but not write it without a human approval step in the loop.

Model this exactly like you model authorization in the rest of your system - with explicit, minimal, audited grants rather than broad access.

8. Streaming AI Responses with ASP.NET Core

LLM inference is slow. Waiting for a full response before returning anything to the client produces an experience that feels broken - the UI freezes, the user wonders if something went wrong, and the HTTP request may time out entirely on long outputs.

Streaming solves all three problems simultaneously. ASP.NET Core's IAsyncEnumerable<T> support makes streaming AI responses to clients a first-class, clean pattern.

// Minimal API endpoint - streams AI response tokens as server-sent events
app.MapPost("/api/contracts/{contractId}/review", async (
    Guid contractId,
    ReviewContractRequest request,
    ContractReviewAgent agent,
    ITokenBudgetService budget,
    ClaimsPrincipal user,
    CancellationToken ct) =>
{
    var tenantId = user.GetTenantId();

    var context = new AgentRunContext(
        TenantId:    tenantId,
        UserId:      user.GetUserId(),
        OperationId: Guid.NewGuid());

    // Return streaming response - ASP.NET Core handles chunked transfer
    return Results.Ok(StreamReviewAsync(contractId, request.Instruction, agent, context, ct));
})
.WithName("ReviewContract")
.WithOpenApi()
.RequireAuthorization("ContractReview")
.RequireRateLimiting("ai-operations");

// Local function returns IAsyncEnumerable for streaming
static async IAsyncEnumerable<ReviewChunk> StreamReviewAsync(
    Guid contractId,
    string instruction,
    ContractReviewAgent agent,
    AgentRunContext context,
    [EnumeratorCancellation] CancellationToken ct)
{
    await foreach (var update in agent.ReviewContractAsync(contractId, instruction, context, ct))
    {
        yield return new ReviewChunk(
            Type:    update.Type.ToString(),
            Content: update.Content,
            At:      DateTimeOffset.UtcNow);
    }
}

public record ReviewChunk(string Type, string Content, DateTimeOffset At);

On the client side, whether you are using Blazor, React, or a mobile application, the experience is a smooth token-by-token stream of text appearing in real time - the same experience users have come to expect from ChatGPT and Claude.

@* Blazor component - consuming the streaming review endpoint *@
@code {
    private readonly StringBuilder _reviewBuffer = new();
    private bool _isStreaming;

    private async Task StartReviewAsync()
    {
        _isStreaming = true;
        _reviewBuffer.Clear();

        using var response = await Http.PostAsJsonAsync(
            $"/api/contracts/{ContractId}/review",
            new { Instruction = UserInstruction });

        response.EnsureSuccessStatusCode();

        await foreach (var chunk in response.Content
            .ReadFromJsonAsAsyncEnumerable<ReviewChunk>())
        {
            if (chunk is null) continue;

            _reviewBuffer.Append(chunk.Content);
            StateHasChanged();   // Re-render as each chunk arrives
        }

        _isStreaming = false;
        StateHasChanged();
    }
}

9. Observability for AI Workloads

AI workloads introduce observability challenges that traditional APM tools are not equipped to handle out of the box. Latency, token consumption, prompt content, model version, temperature setting, and tool call sequences all need to be captured to diagnose problems and control costs.

Semantic Kernel ships with OpenTelemetry support built in. The following setup captures the metrics and traces that matter most in production.

// Program.cs - OpenTelemetry for AI workloads
builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddSource("Microsoft.SemanticKernel")
        .AddSource("MyApp.AI")
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddOtlpExporter())
    .WithMetrics(metrics => metrics
        .AddMeter("Microsoft.SemanticKernel")
        .AddMeter("MyApp.AI.Tokens")
        .AddMeter("MyApp.AI.Latency")
        .AddAspNetCoreInstrumentation()
        .AddOtlpExporter());

// Custom activity source for AI-specific spans
public static class AiTelemetry
{
    public static readonly ActivitySource Source = new("MyApp.AI");

    public static Activity? StartAgentRun(
        string agentName,
        string tenantId,
        string operationId)
    {
        var activity = Source.StartActivity(
            $"agent.{agentName}",
            ActivityKind.Internal);

        activity?.SetTag("ai.agent.name",     agentName);
        activity?.SetTag("ai.tenant.id",      tenantId);
        activity?.SetTag("ai.operation.id",   operationId);
        activity?.SetTag("ai.model",          "gpt-4o");

        return activity;
    }

    public static void RecordTokenUsage(
        string tenantId,
        string operation,
        int promptTokens,
        int completionTokens)
    {
        TokenUsageCounter.Add(
            promptTokens + completionTokens,
            new TagList
            {
                { "tenant.id",  tenantId },
                { "operation",  operation },
                { "token.type", "total" }
            });
    }

    private static readonly Counter<int> TokenUsageCounter =
        new Meter("MyApp.AI.Tokens")
            .CreateCounter<int>(
                "ai.tokens.used",
                unit: "{tokens}",
                description: "Total tokens consumed per operation");
}

The AI observability checklist

Every AI operation in production should produce traces that capture the agent or chain name, the model used and its version, the number of prompt tokens and completion tokens consumed, the total wall-clock latency, every tool call made and its result, whether the operation succeeded or was cut short by a guardrail, and the tenant ID for multi-tenant systems.

Without this data, debugging a misbehaving agent is guesswork. With it, you can answer the questions that matter: why did the agent call the wrong tool, where is the latency spike coming from, which tenant is consuming 40% of our token budget, and is the model performing worse on inputs with certain characteristics.

10. Guardrails: Safety, Cost Control, and Responsible AI

Guardrails are the engineering controls you put in place to ensure AI workloads behave within defined boundaries - for safety, cost, performance, and regulatory compliance. They are not optional. They are the difference between a feature that delights users and one that causes a production incident at 2am.

Token budget enforcement

public interface ITokenBudgetService
{
    Task<int>  GetRemainingAsync(Guid tenantId, CancellationToken ct);
    Task       DeductAsync(Guid tenantId, object usage, CancellationToken ct);
    Task<bool> TryReserveAsync(Guid tenantId, int estimatedTokens, CancellationToken ct);
}

// Infrastructure implementation backed by Redis
public sealed class RedisTokenBudgetService : ITokenBudgetService
{
    private readonly IDatabase _redis;

    public RedisTokenBudgetService(IConnectionMultiplexer redis)
        => _redis = redis.GetDatabase();

    public async Task<int> GetRemainingAsync(Guid tenantId, CancellationToken ct)
    {
        var key   = $"token_budget:{tenantId}:{GetCurrentMonth()}";
        var value = await _redis.StringGetAsync(key);
        return value.HasValue ? (int)value : GetDefaultMonthlyBudget(tenantId);
    }

    public async Task<bool> TryReserveAsync(
        Guid tenantId, int estimatedTokens, CancellationToken ct)
    {
        var remaining = await GetRemainingAsync(tenantId, ct);
        return remaining >= estimatedTokens;
    }

    private static string GetCurrentMonth()
        => DateTimeOffset.UtcNow.ToString("yyyy-MM");

    private static int GetDefaultMonthlyBudget(Guid tenantId)
        => 500_000; // 500K tokens per tenant per month on starter plan
}

Input and output validation

Every prompt sent to an LLM should be validated before dispatch, and every response received should be validated before being shown to a user or used to trigger a domain action. This is especially important in multi-tenant systems where user-supplied content could contain prompt injection attempts.

public sealed class PromptSafetyMiddleware
{
    private static readonly string[] ForbiddenPatterns =
    [
        "ignore previous instructions",
        "you are now",
        "disregard your",
        "act as if",
        "pretend you are"
    ];

    public static bool IsSafeInput(string userInput)
    {
        var normalized = userInput.ToLowerInvariant();

        return !ForbiddenPatterns.Any(pattern =>
            normalized.Contains(pattern, StringComparison.OrdinalIgnoreCase));
    }

    public static bool IsStructuredOutputValid<T>(string llmOutput)
    {
        try
        {
            var result = JsonSerializer.Deserialize<T>(llmOutput);
            return result is not null;
        }
        catch
        {
            return false;
        }
    }
}

The human-in-the-loop pattern

For any AI action that has irreversible consequences - sending an email, updating a contract status, charging a payment method, deleting records - require explicit human approval before execution. The agent can prepare the action and present it for review. The human approves or rejects. Only then does the domain command execute.

public sealed class PendingAiAction
{
    public Guid              Id          { get; init; } = Guid.NewGuid();
    public string            Description { get; init; } = "";
    public string            CommandJson  { get; init; } = "";
    public string            CommandType  { get; init; } = "";
    public PendingActionStatus Status    { get; private set; } = PendingActionStatus.AwaitingApproval;
    public DateTimeOffset    ExpiresAt   { get; init; } = DateTimeOffset.UtcNow.AddHours(24);

    public void Approve(UserId approver)
    {
        if (Status != PendingActionStatus.AwaitingApproval)
            throw new DomainException("This action has already been resolved.");
        if (DateTimeOffset.UtcNow > ExpiresAt)
            throw new DomainException("This action request has expired.");

        Status = PendingActionStatus.Approved;
    }

    public void Reject(UserId rejector, string reason)
    {
        Status = PendingActionStatus.Rejected;
    }
}

11. Real-World Walkthrough: AI-Native CRM Feature

Let us put the entire architecture together by designing one cohesive AI-native feature: a customer health score assistant for a B2B SaaS CRM. The assistant analyzes a customer's usage data, support history, payment history, and NPS responses, and generates a health score with a plain-English explanation and recommended actions for the account manager.

The feature requirements

The assistant must read customer data across four domains: product usage metrics, support ticket history, billing and payment records, and NPS survey responses. It must produce a structured health score from 0 to 100, a one-paragraph plain-English explanation, and up to three prioritized recommended actions. It must stream the response in real time. It must log every inference for audit. It must respect a per-tenant token budget.

The architecture

Account Manager clicks "Analyze Health"
          │
          ▼
POST /api/customers/{id}/health-analysis
          │
          ▼
HealthAnalysisEndpoint
  → Validates token budget
  → Creates AgentRunContext
  → Streams CustomerHealthAgent.AnalyzeAsync()
          │
          ▼
CustomerHealthAgent (Semantic Kernel ChatCompletionAgent)
  → Plugins: UsagePlugin, SupportPlugin, BillingPlugin, NpsPlugin
  → Strategy: Auto function calling
  → Temperature: 0.15 (analytical, low creativity)
          │
     ┌────┴────────────────────────────────────┐
     │ Tool calls (in whatever order the       │
     │ model determines is logical)            │
     ├─────────────────────────────────────────┤
     │ UsagePlugin.GetUsageMetricsAsync()      │
     │   → PostgreSQL (metrics schema)         │
     │ SupportPlugin.GetTicketHistoryAsync()   │
     │   → PostgreSQL (support schema)         │
     │ BillingPlugin.GetPaymentHistoryAsync()  │
     │   → PostgreSQL (billing schema)         │
     │ NpsPlugin.GetNpsResponsesAsync()        │
     │   → PostgreSQL (survey schema)          │
     └────┬────────────────────────────────────┘
          │
          ▼
Structured output: HealthAnalysisResult
{
  "score": 74,
  "trend": "declining",
  "explanation": "...",
  "recommended_actions": [...]
}
          │
          ▼
  → Streamed to client as JSON chunks
  → Persisted to customer record (async)
  → Logged to audit trail
  → Token usage deducted from budget

The output schema

// Force the model to return structured output
public sealed record HealthAnalysisResult
{
    [JsonPropertyName("score")]
    [JsonDescription("Health score from 0 (critical) to 100 (excellent)")]
    public int Score { get; init; }

    [JsonPropertyName("trend")]
    [JsonDescription("Score trend: improving, stable, or declining")]
    public string Trend { get; init; } = "";

    [JsonPropertyName("explanation")]
    [JsonDescription("One paragraph plain-English explanation for the account manager")]
    public string Explanation { get; init; } = "";

    [JsonPropertyName("recommended_actions")]
    [JsonDescription("Up to 3 prioritized actions the account manager should take")]
    public IReadOnlyList<RecommendedAction> RecommendedActions { get; init; } = [];
}

public sealed record RecommendedAction(
    [property: JsonPropertyName("priority")]   int    Priority,
    [property: JsonPropertyName("action")]     string Action,
    [property: JsonPropertyName("rationale")]  string Rationale
);

This walkthrough covers roughly 20% of the full implementation, but it demonstrates the key structural principle: the AI is a coordinator that uses your existing domain repositories through the plugin interface. The repositories do not know they are being called by an AI. The domain does not change. Only the orchestration layer is new.

12. Migration Path: Evolving an Existing .NET System

Adopting an AI-native architecture does not require a rewrite. The most effective migration path is incremental and additive - you add the AI Orchestration Layer on top of your existing Clean Architecture without disturbing the layers beneath it.

Phase 1 - Add the AI infrastructure (Week 1-2)

Install Semantic Kernel, configure your LLM provider and embedding model, and add your vector store of choice. Write the ITokenBudgetService, IAgentAuditLogger, and IContractSemanticSearch interfaces. Implement them in the Infrastructure layer. Register everything in DI. No existing code changes.

Phase 2 - Build the first plugin from an existing service (Week 2-3)

Take one existing domain service - the simplest one whose data would be useful to an AI - and wrap it in a [KernelFunction] plugin. Write clear, natural-language descriptions on every method and parameter. Write integration tests that verify the plugin calls the underlying service correctly.

Phase 3 - Build a single AI endpoint with full observability (Week 3-4)

Build one streaming AI endpoint end to end, with token budget enforcement, audit logging, OpenTelemetry traces, and a rate limiting policy specific to AI operations. This is your reference implementation - every subsequent AI feature follows the same pattern.

Phase 4 - Add semantic indexing to existing entities (Week 4-6)

Identify the entities that would most benefit from semantic search. Add the semantic metadata fields to those entities (AI summary, embedding vector, last indexed at). Build the background indexing job that populates them asynchronously via domain commands. This phase does not change any existing read or write paths.

Phase 5 - Expand plugins and agents gradually (Ongoing)

Add plugins for additional domain areas one at a time. Build agents that combine multiple plugins into coherent workflows. Each agent should be narrowly scoped, fully logged, and subject to the human-in-the-loop pattern for any irreversible actions.

Current state:
  Clean Architecture with DDD + CQRS
  PostgreSQL, Redis, blob storage
  ASP.NET Core Minimal APIs

After Phase 1:
  + Semantic Kernel registered in DI
  + LLM and embedding provider configured
  + Vector store added (pgvector or Qdrant)
  + Token budget service operational
  + Audit logger operational
  + Full OTEL tracing for AI spans

After Phase 2-3:
  + First plugin wrapping existing domain service
  + First streaming AI endpoint live
  + Rate limiting on AI operations
  + Reference implementation established

After Phase 4-6:
  + Key entities semantically indexed
  + Multiple plugins across domain areas
  + Scoped agents for key workflows
  + Human-in-the-loop for irreversible actions
  + AI-native architecture fully operational

Wrapping Up

Modernizing a .NET architecture for AI-native workloads is not a replacement project - it is an evolution. The Clean Architecture principles, domain-driven design, and engineering discipline that make .NET systems reliable and maintainable are exactly the foundation you need to build AI capabilities that are trustworthy in production.

The key insight is that the AI Orchestration Layer is a new architectural concern that sits between your application layer and your AI infrastructure. It does not replace your domain model - it enriches it. It does not replace your repositories - it calls them through plugins. It does not replace your observability stack - it extends it with AI-specific metrics and traces.

The patterns covered in this article - semantic plugins, vector memory, the agent pattern, streaming responses, token budget guardrails, and the human-in-the-loop - are not theoretical. They are the patterns that production AI-native .NET systems are built on today. Each one maps cleanly to the Clean Architecture and DDD vocabulary that .NET engineers already know.

The migration path is incremental. The risk is manageable. The opportunity is extraordinary.

Start with one plugin. Ship one streaming endpoint. Build from there.

Have you already integrated Semantic Kernel or another AI framework into a .NET production system? Share your experience in the comments - the patterns the community is developing in the real world are ahead of any single article.

Resources

Semantic Kernel Documentation · Semantic Kernel GitHub · pgvector for PostgreSQL · Qdrant Vector Database · Azure AI Search Hybrid Search · OpenTelemetry .NET · ASP.NET Core Streaming with IAsyncEnumerable · Microsoft Responsible AI Principles

How I release a Blazor app to 8 distribution channels

Urban — Sat, 04 Apr 2026 09:03:06 +0000

OpenHabitTracker is a free, open source app for taking Markdown notes, planning tasks, and tracking habits. One codebase, 8 distribution channels. This is everything I had to figure out to ship it.

The previous articles covered why there are so many entry points and how the shared Blazor component library stays platform-agnostic. This article is about what happens after you write the code - the files you need, the gotchas that aren't documented anywhere, and what you have to do on every release.

Why 8 channels?

Each distribution channel has different requirements that forced a separate entry point:

Microsoft Store - MAUI (net9.0-windows)
Google Play - MAUI (net9.0-android)
Apple App Store - MAUI (net9.0-ios)
Mac App Store - MAUI (net9.0-maccatalyst)
Flatpak (Flathub) - Photino - MAUI has no Linux target
Snap Store - Photino
Docker Hub + GitHub Container Registry - Blazor Server
ClickOnce (Windows direct download) - WPF - for users who don't want the Store
PWA - Blazor WASM

Before your first release (all platforms)

The boring but mandatory stuff - brief because it's all googleable:

Register as a developer on each platform (Microsoft Partner Center $19 one-time, Google Play Console $25 one-time, Apple Developer Program $99/year, Snap Store free, Flathub free, Docker Hub free)
Create your app listing on each store with descriptions, screenshots, privacy policy URL
For Apple: create App IDs, provisioning profiles, and distribution certificates in Apple Developer portal
For Google: create a keystore and keep it safe - you can never change it after the first upload
For Microsoft Store: associate your app in Visual Studio to get the publisher identity values

Version numbers - the cross-cutting problem

Before going platform by platform, the version number problem deserves its own section because it's spread across more files than you'd expect, and one of them has a non-obvious constraint.

Files that contain the version number:

OpenHabitTracker.Blazor.Maui/OpenHabitTracker.Blazor.Maui.csproj - two separate fields
Platforms/Windows/Package.appxmanifest
net.openhabittracker.OpenHabitTracker.yaml
net.openhabittracker.OpenHabitTracker.metainfo.xml
snapcraft.yaml
ClickOnceProfile.pubxml
FolderProfile.pubxml (WASM)
VersionHistory.md

The MAUI .csproj has two separate version fields and they serve different purposes:

<ApplicationDisplayVersion>1.2.1</ApplicationDisplayVersion>
<ApplicationVersion>21</ApplicationVersion>

ApplicationDisplayVersion is the human-readable string shown to users. ApplicationVersion is an integer - Android requires it, it must strictly increment on every release, and it cannot be the version string. If you try to use "1.2.1" as the version code, the Android build fails with:

error XA0003: VersionCode 1.2.1 is invalid. It must be an integer value.

So you maintain a separate integer counter alongside your version string. Every release you bump both.

Microsoft Store (MAUI Windows)

First time: Register at Partner Center, pay the one-time fee, create the app reservation, associate the app in Visual Studio (this fills in the publisher identity values), create an MSIX package. (MAUI Windows deployment docs)

Special file: Platforms/Windows/Package.appxmanifest (schema reference)

<Identity
  Name="31456Jinjinov.578313437ADBB"
  Publisher="CN=63F779A2-C88E-4913-81F0-5E6786C4CD1A"
  Version="1.2.1.0" />

<Capabilities>
  <rescap:Capability Name="runFullTrust" />
  <Capability Name="internetClient"/>
</Capabilities>

The Name and Publisher values come from Partner Center when you associate your app. You can't make them up - they must match exactly what the Store has on record or the upload will be rejected.

runFullTrust is required for MAUI apps because they run as regular Win32 processes, not sandboxed UWP apps.

Every release: Bump Version in Package.appxmanifest, publish:

dotnet publish OpenHabitTracker.Blazor.Maui.csproj -c:Release -f:net9.0-windows10.0.19041.0 -p:SelfContained=true -p:PublishAppxPackage=true

Upload the .msixupload to Partner Center.

Google Play (MAUI Android)

First time: Register at Play Console, pay the one-time fee, create the app, set up the keystore, configure release signing. (MAUI Android Google Play docs)

You can test on an Android emulator before building a release:

dotnet build -t:Run -f:net9.0-android

Special file: Platforms/Android/AndroidManifest.xml

<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <application android:allowBackup="true" android:icon="@mipmap/appicon" android:roundIcon="@mipmap/appicon_round" android:supportsRtl="true"></application>
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.INTERNET" />
</manifest>

This file looks minimal, but every permission your app needs must be declared here. Missing a permission and the feature silently fails at runtime. Adding a permission you don't need can cause Play Store review rejections. (Android permission reference)

Every release: Bump ApplicationDisplayVersion and ApplicationVersion (the integer) in .csproj, publish:

dotnet publish -c Release -f:net9.0-android ...

Upload the .aab to Play Console. The integer ApplicationVersion must be higher than the previous release or the upload is rejected.

Apple App Store (MAUI iOS)

First time: Apple Developer Program ($99/year, covers all Apple platforms), create an App ID, create a distribution certificate, create a provisioning profile, install both on your Mac. (MAUI iOS App Store docs, manual provisioning guide)

Apple requires screenshots at exact pixel dimensions or the submission is rejected. Required sizes:

iPhone 6.7": 1290x2796 or 2796x1290
iPhone 6.5": 1242x2688 or 1284x2778
iPhone 5.5": 1242x2208 or 2208x1242
iPad 12.9" (2nd gen): 2048x2732 or 2732x2048
iPad 13": 2064x2752 or 2048x2732

You can test on the simulator before building a release:

dotnet build OpenHabitTracker.Blazor.Maui.csproj -t:Run -c:Release -f:net9.0-ios

Special file: Platforms/iOS/Info.plist

<key>CFBundleIdentifier</key>
<string>net.openhabittracker</string>
<key>CFBundleDisplayName</key>
<string>OpenHT</string>
<key>ITSAppUsesNonExemptEncryption</key>
<false/>
<key>UIDeviceFamily</key>
<array>
    <integer>1</integer>  <!-- iPhone -->
    <integer>2</integer>  <!-- iPad -->
</array>

ITSAppUsesNonExemptEncryption is the one that catches everyone. If you omit it, Apple holds your submission and asks you to answer export compliance questions every single time you submit. Set it to false if your app doesn't use encryption beyond standard HTTPS (which is exempt). (MAUI Info.plist docs)

The signing config lives in the .csproj in a conditional PropertyGroup, not just in the publish command. (MAUI iOS publish CLI docs)

<PropertyGroup Condition="$(TargetFramework.Contains('-ios')) and '$(Configuration)' == 'Release'">
    <RuntimeIdentifier>ios-arm64</RuntimeIdentifier>
    <CodesignKey>Apple Distribution: Your Name (53V66WG4KU)</CodesignKey>
    <CodesignProvision>openhabittracker.ios</CodesignProvision>
</PropertyGroup>

Every release: Publish, upload .ipa via Transporter or Xcode.

dotnet publish OpenHabitTracker.Blazor.Maui.csproj -c:Release -f:net9.0-ios -p:ArchiveOnBuild=true -p:RuntimeIdentifier=ios-arm64 -p:CodesignKey="Apple Distribution: Your Name (53V66WG4KU)" -p:CodesignProvision="openhabittracker.ios"

Mac App Store (MAUI macOS)

First time: Same Apple Developer account, but separate Mac-specific provisioning profile and a second certificate type for the installer package. (MAUI macOS App Store docs, manual provisioning guide)

Required screenshot sizes for Mac App Store: 1280x800, 1440x900, 2560x1600, 2880x1800.

You can test locally before building a release:

dotnet build OpenHabitTracker.Blazor.Maui.csproj -t:Run -c:Release -f:net9.0-maccatalyst

Special file: Platforms/MacCatalyst/Info.plist

<key>CFBundleIdentifier</key>
<string>net.openhabittracker</string>
<key>LSApplicationCategoryType</key>
<string>public.app-category.productivity</string>
<key>NSHumanReadableCopyright</key>
<string>© 2026 Jinjinov</string>
<key>ITSAppUsesNonExemptEncryption</key>
<false/>

Same ITSAppUsesNonExemptEncryption caveat as iOS. Also LSApplicationCategoryType - the Mac App Store requires a category, the App Store will reject submission without it. (MAUI Info.plist docs)

Special file: Platforms/MacCatalyst/Entitlements.plist

<dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.network.client</key>
    <true/>
</dict>

App Sandbox is mandatory for Mac App Store distribution. Without it, Apple rejects the submission outright. With it, you must explicitly declare every capability your app needs - in this case network.client for outgoing connections. Miss one and the feature fails silently inside the sandbox. (MAUI macOS entitlements docs)

The macOS signing config in .csproj requires three separate keys (MAUI macOS publish CLI docs):

<PropertyGroup Condition="$(TargetFramework.Contains('-maccatalyst')) and '$(Configuration)' == 'Release'">
    <CodesignKey>Apple Distribution: Your Name (53V66WG4KU)</CodesignKey>
    <CodesignProvision>openhabittracker.macos</CodesignProvision>
    <CodesignEntitlements>Platforms\MacCatalyst\Entitlements.plist</CodesignEntitlements>
    <PackageSigningKey>3rd Party Mac Developer Installer: Your Name (53V66WG4KU)</PackageSigningKey>
    <EnableCodeSigning>True</EnableCodeSigning>
    <EnablePackageSigning>true</EnablePackageSigning>
    <CreatePackage>true</CreatePackage>
    <MtouchLink>SdkOnly</MtouchLink>
</PropertyGroup>

Three different certificate types are involved: Apple Distribution (signs the app bundle), 3rd Party Mac Developer Installer (signs the .pkg installer). The certificate names include your team ID in parentheses - they come from Keychain after you install the certificates from Apple Developer portal.

Every release:

dotnet publish OpenHabitTracker.Blazor.Maui.csproj -c:Release -f:net9.0-maccatalyst -p:MtouchLink=SdkOnly -p:CreatePackage=true -p:EnableCodeSigning=true -p:EnablePackageSigning=true -p:CodesignKey="Apple Distribution: Your Name (53V66WG4KU)" -p:CodesignProvision="openhabittracker.macos" -p:CodesignEntitlements="Platforms\MacCatalyst\Entitlements.plist" -p:PackageSigningKey="3rd Party Mac Developer Installer: Your Name (53V66WG4KU)"

Upload .pkg via Transporter.

Flatpak / Flathub (Photino, Linux)

This is the most involved distribution channel. Flatpak builds happen in a network-isolated sandbox - no internet access during build. Every dependency must be pre-declared.

Photino depends on WebKit. On a fresh Linux machine you need this before the app will run at all:

sudo apt-get install libwebkit2gtk-4.1

First time: Apply to Flathub, fork their template repo, set up the app manifest, pass the linter, get reviewed. (Flathub submission guide) Flathub creates a separate GitHub repository for your app's manifest at github.com/flathub/net.openhabittracker.OpenHabitTracker. You maintain a fork at github.com/Jinjinov/net.openhabittracker.OpenHabitTracker.

Special file: net.openhabittracker.OpenHabitTracker.yaml

The Flatpak build manifest. It references your git repository by tag AND commit hash - both must match:

- type: git
  url: https://github.com/Jinjinov/OpenHabitTracker.git
  tag: 1.2.1
  commit: 233c4b8410756159e14f31dd7a4e3607efa53749

It also handles cross-architecture builds through environment variables:

build-options:
  arch:
    aarch64:
      env:
        RUNTIME: linux-arm64
    x86_64:
      env:
        RUNTIME: linux-x64
build-commands:
  - dotnet publish OpenHabitTracker.Blazor.Photino/... -r $RUNTIME ...

Special file: net.openhabittracker.OpenHabitTracker.metainfo.xml

Flathub validates this file with a linter before merging the PR. It must pass appstream-util validate and flatpak-builder-lint. It contains the app description, release history, and screenshot URLs. A release entry must be added for every version. (AppStream spec)

Special file: net.openhabittracker.OpenHabitTracker.desktop

[Desktop Entry]
Name=OpenHabitTracker
Comment=Take notes, plan tasks, track habits
Exec=OpenHT
Icon=net.openhabittracker.OpenHabitTracker
Type=Application
Categories=Office;

This is the Linux standard for app launchers - how your app appears in GNOME, KDE, etc. The Icon value must match the SVG filename (without extension).

Special file: net.openhabittracker.OpenHabitTracker.svg

Flathub requires an SVG icon, not PNG. This must use the reverse-domain naming convention that matches your app ID.

Special file: nuget-sources.json

The most unique file in the whole project. Because Flatpak builds in a network-isolated sandbox, it cannot download NuGet packages at build time. Every package - including all transitive dependencies - must be pre-declared with its download URL and SHA-512 hash. This file is generated by flatpak-dotnet-generator.py:

python3 flatpak-dotnet-generator.py --dotnet 9 --freedesktop 25.08 nuget-sources.json OpenHabitTracker/OpenHabitTracker.Blazor.Photino/OpenHabitTracker.Blazor.Photino.csproj

The yaml then references it as an offline source:

sources:
  - type: git
    url: https://github.com/Jinjinov/OpenHabitTracker.git
    tag: 1.2.1
    commit: 233c4b8410756159e14f31dd7a4e3607efa53749
  - ./nuget-sources.json
build-commands:
  - dotnet publish ... --source ./nuget-sources --source /usr/lib/sdk/dotnet9/nuget/packages

nuget-sources.json doesn't need to be regenerated every release - only when NuGet packages change.

Every release:

Before opening a PR, validate everything locally. The Flathub linter will catch these too, but it's faster to fix them locally:

desktop-file-validate net.openhabittracker.OpenHabitTracker.desktop
appstream-util validate net.openhabittracker.OpenHabitTracker.metainfo.xml
flatpak run --command=flatpak-builder-lint org.flatpak.Builder manifest net.openhabittracker.OpenHabitTracker.yaml

Do a full local build and run to confirm it works:

flatpak-builder build-dir --user --force-clean --install --repo=repo net.openhabittracker.OpenHabitTracker.yaml
flatpak run --command=flatpak-builder-lint org.flatpak.Builder repo repo
flatpak run net.openhabittracker.OpenHabitTracker

Then submit:

Create a git tag
Get the commit hash: git ls-remote https://github.com/Jinjinov/OpenHabitTracker.git refs/tags/1.2.1
Update tag and commit in net.openhabittracker.OpenHabitTracker.yaml
Add a release entry to net.openhabittracker.OpenHabitTracker.metainfo.xml
Push to your fork (Jinjinov/net.openhabittracker.OpenHabitTracker)
Open a PR to flathub/net.openhabittracker.OpenHabitTracker
The Flathub bot builds and tests it - wait for ✅ Test build succeeded
If the test build fails: push a fix, update the tag and commit in the yaml, then comment in the PR: bot, build net.openhabittracker.OpenHabitTracker
Merge the PR
Sync your fork back from the upstream flathub repo so it stays up to date

Snap Store (Photino, Linux)

First time: Register at snapcraft.io, register the app name, install Snapcraft and LXD. Snapcraft uses LXD to build in an isolated container - you can't build snaps without it:

sudo snap install snapcraft --classic
sudo snap install lxd
sudo lxd init --auto
sudo usermod -aG lxd $USER
newgrp lxd

Special file: snapcraft.yaml (snapcraft.yaml reference)

name: openhabittracker
base: core24
confinement: strict
version: '1.2.1'

parts:
  openhabittracker:
    source: .
    plugin: dotnet
    dotnet-version: "9.0"
    override-build: |
      dotnet publish OpenHabitTracker.Blazor.Photino/OpenHabitTracker.Blazor.Photino.csproj -c Release -f net9.0 -r linux-x64 -p:PublishSingleFile=true -p:SelfContained=true -o $SNAPCRAFT_PART_INSTALL
      chmod 0755 $SNAPCRAFT_PART_INSTALL/OpenHT

apps:
  openhabittracker:
    extensions: [gnome]
    command: OpenHT
    plugs:
      - hardware-observe
      - home
      - removable-media
      - network

plugs are the snap equivalent of Android permissions - they declare what the app can access. (Snap interfaces reference) extensions: [gnome] pulls in GNOME libraries and is required for GTK-based apps (Photino uses WebKit which is part of the GNOME stack).

confinement: strict means the snap is fully sandboxed. During development you use confinement: devmode and then switch to strict for release.

Every release:

snapcraft pack --debug

If the pack fails, clean the build cache and retry:

snapcraft clean openhabittracker
snapcraft pack --debug

Test locally before uploading:

sudo snap install openhabittracker_1.2.1_amd64.snap --dangerous --devmode
snap run openhabittracker

Upload and verify:

snapcraft login
snapcraft upload --release=stable openhabittracker_1.2.1_amd64.snap
snapcraft status openhabittracker

Docker Hub + GitHub Container Registry (Blazor Server)

First time: Docker Hub account, GitHub account (for GHCR), set up the Dockerfile, test the image locally. Authenticate to both registries before pushing:

docker login

echo <GitHubToken> | docker login ghcr.io -u YourUsername --password-stdin

The GitHub token needs write:packages scope. Generate it at GitHub → Settings → Developer settings → Personal access tokens.

Special file: Dockerfile

Multi-stage build - SDK image to compile, ASP.NET runtime image to run. (Docker multi-stage build docs)

FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build
WORKDIR /src

COPY ["OpenHabitTracker/OpenHabitTracker.csproj", "OpenHabitTracker/"]
COPY ["OpenHabitTracker.Blazor.Web/OpenHabitTracker.Blazor.Web.csproj", "OpenHabitTracker.Blazor.Web/"]
# ... other projects
RUN dotnet restore "OpenHabitTracker.Blazor.Web/OpenHabitTracker.Blazor.Web.csproj"

COPY . .
RUN dotnet publish "OpenHabitTracker.Blazor.Web.csproj" -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS runtime
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "OpenHT.dll"]

Only copying .csproj files first and running dotnet restore before copying the rest is intentional - it lets Docker cache the NuGet restore layer so rebuilds are fast when only source files change.

Special file: docker-compose.yml

This ships to end users, not just for building. Users run docker compose up with this file. It maps environment variables to appsettings.json values so users can set their credentials without modifying the image:

services:
  openhabittracker:
    image: jinjinov/openhabittracker:latest
    ports:
      - "5000:8080"
    environment:
      - AppSettings__UserName=${APPSETTINGS_USERNAME}
      - AppSettings__Email=${APPSETTINGS_EMAIL}
      - AppSettings__Password=${APPSETTINGS_PASSWORD}
      - AppSettings__JwtSecret=${APPSETTINGS_JWT_SECRET}
    volumes:
      - ./.OpenHabitTracker:/app/.OpenHabitTracker

Every release:

docker compose build
docker tag openhabittracker jinjinov/openhabittracker:1.2.1
docker push jinjinov/openhabittracker:1.2.1
docker tag openhabittracker jinjinov/openhabittracker:latest
docker push jinjinov/openhabittracker:latest

docker tag openhabittracker ghcr.io/jinjinov/openhabittracker:1.2.1
docker push ghcr.io/jinjinov/openhabittracker:1.2.1
docker tag openhabittracker ghcr.io/jinjinov/openhabittracker:latest
docker push ghcr.io/jinjinov/openhabittracker:latest

(GitHub Container Registry docs)

WPF + ClickOnce (Windows direct download)

ClickOnce is for users who want a classical Windows installer experience without going through the Microsoft Store.

First time: Configure publish settings in Visual Studio, set up the bootstrapper. (ClickOnce deployment docs)

Special file: Properties/PublishProfiles/ClickOnceProfile.pubxml

<ApplicationVersion>1.2.1.0</ApplicationVersion>
<PublishProtocol>ClickOnce</PublishProtocol>
<RuntimeIdentifier>win-x86</RuntimeIdentifier>
<SelfContained>False</SelfContained>
<BootstrapperPackage Include="Microsoft.NetCore.DesktopRuntime.9.0.x86">
    <Install>true</Install>
    <ProductName>.NET Desktop Runtime 9.0.0 (x86)</ProductName>
</BootstrapperPackage>

SelfContained=False + the bootstrapper means the installer checks for .NET Desktop Runtime and downloads it if missing. This keeps the installer small.

Every release: Bump ApplicationVersion, publish via Visual Studio ClickOnce, zip the output, FTP upload to the download server.

WASM / PWA (Blazor WebAssembly)

First time: Set up IIS with the URL Rewrite module (required for SPA routing - without it, any direct URL that isn't the root returns 404). (Blazor WASM IIS hosting docs)

Special file: wwwroot/manifest.json (web app manifest spec)

{
  "name": "OpenHabitTracker",
  "short_name": "OpenHT",
  "id": "./",
  "start_url": "./",
  "display": "standalone",
  "background_color": "#808080",
  "theme_color": "#808080",
  "icons": [
    { "src": "/icons/icon-512.png", "type": "image/png", "sizes": "512x512" },
    { "src": "/icons/icon-192.png", "type": "image/png", "sizes": "192x192" }
  ]
}

This makes the app installable as a PWA. display: standalone hides the browser chrome. Without the 512px icon, Chrome won't offer the install prompt.

Special file: wwwroot/service-worker.published.js

The dev version (service-worker.js) is a stub that always fetches from the network. The published version caches all .dll, .wasm, .js, .css, and asset files on first install for offline support. (Blazor PWA docs)

const offlineAssetsInclude = [ /\.dll$/, /\.pdb$/, /\.wasm/, /\.html/, /\.js$/, /\.json$/, /\.css$/, /\.woff$/, /\.png$/, /\.jpe?g$/, /\.gif$/, /\.ico$/ ];

Special file: Properties/PublishProfiles/FolderProfile.pubxml

<PublishUrl>C:\inetpub\wwwroot</PublishUrl>
<DeleteExistingFiles>false</DeleteExistingFiles> <!-- NEVER SET IT TO true! IT WILL DELETE C:\inetpub\wwwroot FOLDER! -->

The danger comment is real. DeleteExistingFiles=true in a publish profile pointed at C:\inetpub\wwwroot will delete the entire folder and everything in it before copying the published output.

Every release: Publish to folder (directly to C:\inetpub\wwwroot), then FTP upload to the server.

The result

8 channels, roughly 15 special files, one codebase. The most time-consuming part on every release is keeping the version number consistent across all these files. The most time-consuming part on the first release is Apple - not because it's hard once you understand it, but because the documentation is scattered and the error messages are unhelpful.

Flatpak is the most technically interesting because of the offline build sandbox and the nuget-sources.json workflow. Flatpak has good official documentation for .NET at docs.flatpak.org/en/latest/dotnet.html - but it still took me a while to put all the pieces together for a real app with many dependencies.

OpenHabitTracker is open source - all the files shown here are in the repo.

.NET FULL STACK COURSE IN TELUGU: FROM BASICS TO ADVANCED CONCEPTS

Chandra Mouli — Sat, 04 Apr 2026 06:06:15 +0000

Introduction
In today’s competitive IT industry, having only basic knowledge is not enough. To stand out, you need to master both fundamental and advanced concepts. Full stack development requires a deep understanding of multiple technologies, making it essential to follow a structured learning approach.
The .NET Full Stack Course in Telugu is designed to take learners from basics to advanced concepts, ensuring a complete understanding of web development.

Learning from Basics
Programming Fundamentals
You will start with:
C# basics
Logical thinking
Coding principles
Frontend Development
Learn how to create user-friendly interfaces using:
HTML
CSS
JavaScript
Moving to Intermediate Level
At this stage, you will learn:
Backend development with ASP.NET Core
Database management
API creation
Advanced Concepts Covered

Microservices Architecture Learn how to build scalable applications using microservices.
Performance Optimization Understand how to improve application performance.
Security Practices Learn how to secure applications and protect data.
Deployment and Maintenance Understand how to deploy applications and manage them effectively. Skills You Will Gain Full stack development expertise Problem-solving skills Advanced coding techniques Real-world application development Career Opportunities After completing the .NET Full Stack Course in Telugu, you can explore roles such as: Senior Developer Full Stack Engineer Software Architect Why This Course Stands Out Covers complete learning path Focuses on practical knowledge Prepares you for real-world challenges Conclusion The .NET Full Stack Course in Telugu: From Basics to Advanced Concepts is the perfect program for anyone looking to master web development. It provides a complete learning journey, helping you build strong technical skills and achieve career success. If you are serious about becoming a professional developer, this course gives you the knowledge, confidence, and experience needed to succeed in the IT industry.

React 19 useActionState: Practical Examples That Replace Your Old Form Code

Vikrant Bagal — Sat, 04 Apr 2026 05:06:48 +0000

React 19 useActionState: Practical Examples That Replace Your Old Form Code

React 19 introduced useActionState, a hook that fundamentally changes how you handle form submissions and async actions. If you're still managing loading states, error states, and submitted values with separate useState calls, this hook will cut your boilerplate in half.

What `useActionState` Does

useActionState wraps an async action function and returns three values:

state — whatever your action returns
dispatch — a function to trigger the action
isPending — true while the action is in flight

const [state, dispatch, isPending] = useActionState(
  async (prevState, formData) => {
    // Your async logic here
    return { success: true, message: "Done" };
  },
  initialState
);

This replaces the React 18 pattern of juggling useState for loading, errors, and results — plus manual e.preventDefault() and try/catch blocks.

Example 1: Simple Form with Validation

Here's a common pattern: a form that validates input, shows loading state, and displays success or error messages.

import { useActionState } from "react";

async function submitForm(prevState, formData) {
  // Simulate API call
  await new Promise(resolve => setTimeout(resolve, 1500));

  const email = formData.get("email");
  if (!email || !email.includes("@")) {
    return { success: false, message: "Please enter a valid email." };
  }

  return { success: true, message: "Submitted successfully!" };
}

function ContactForm() {
  const [state, formAction, isPending] = useActionState(submitForm, {
    success: null,
    message: "",
  });

  return (
    <form action={formAction}>
      <input type="text" name="name" placeholder="Name" />
      <input type="email" name="email" placeholder="Email" />
      <button disabled={isPending}>
        {isPending ? "Submitting..." : "Submit"}
      </button>

      {state.message && (
        <p className={state.success ? "success" : "error"}>
          {state.message}
        </p>
      )}
    </form>
  );
}

Key observations:

No useState for isPending, error, or success — all handled by the hook
No e.preventDefault() — the action attribute handles it
The action receives formData directly via the FormData API
Validation and error handling happen inside the action function

Example 2: Counter with Async Increment

For non-form actions, you can call the dispatch function imperatively with startTransition:

import { useActionState, startTransition } from "react";
import { addToCart } from "./api";

function CartButton() {
  const [count, dispatch, isPending] = useActionState(
    async (prevCount) => {
      return await addToCart(prevCount);
    },
    0
  );

  function handleClick() {
    startTransition(() => {
      dispatch();
    });
  }

  return (
    <div>
      <span>Items: {count}</span>
      <button onClick={handleClick} disabled={isPending}>
        Add to Cart{isPending ? " 🌀" : ""}
      </button>
    </div>
  );
}

This pattern is useful for buttons that trigger side effects without a form — like adding items to a cart, liking a post, or following a user.

Example 3: Multiple Independent Actions in One Component

You can use multiple useActionState calls in the same component, each managing its own state:

import { useActionState } from "react";
import { toggleLike, toggleFollow } from "./actions";

function SocialActions() {
  const [liked, likeAction] = useActionState(toggleLike, false);
  const [following, followAction] = useActionState(toggleFollow, false);

  return (
    <div>
      <form action={likeAction}>
        <button>{liked ? "❤️ Liked" : "♡ Like"}</button>
      </form>
      <form action={followAction}>
        <button>{following ? "✔ Following" : "+ Follow"}</button>
      </form>
    </div>
  );
}

Each action is completely independent — toggling "like" doesn't affect the "follow" state. This is much cleaner than managing multiple useState pairs with separate loading flags.

Example 4: With `useFormStatus` for Child Components

If you need pending state in a child component (like a loading spinner inside a button), use useFormStatus — but it must be in a child of the form, not the form itself:

import { useActionState } from "react";
import { useFormStatus } from "react-dom";

function SubmitButton() {
  const { pending } = useFormStatus();
  return (
    <button type="submit" disabled={pending}>
      {pending ? "Saving..." : "Save"}
    </button>
  );
}

function ProfileForm() {
  const [state, formAction] = useActionState(
    async (prev, formData) => {
      await saveProfile(formData);
      return { saved: true };
    },
    { saved: false }
  );

  return (
    <form action={formAction}>
      <input name="name" defaultValue="John" />
      <SubmitButton /> {/* useFormStatus works here */}
    </form>
  );
}

Example 5: Error-Only State Pattern

For simple cases where you only care about errors (not success state), use a string as the initial state:

import { useActionState } from "react";

function NameForm() {
  const [error, submitAction, isPending] = useActionState(
    async (prev, formData) => {
      const response = await fetch("/api/update-name", {
        method: "POST",
        body: JSON.stringify({ name: formData.get("name") }),
      });

      if (!response.ok) {
        const { message } = await response.json();
        return message; // Return error string
      }
      return ""; // Empty string = no error
    },
    "" // Initial state: no error
  );

  return (
    <form action={submitAction}>
      <input type="text" name="name" />
      <button type="submit" disabled={isPending}>Save</button>
      {isPending && <Spinner />}
      {error && <p className="error">{error}</p>}
    </form>
  );
}

React 18 vs React 19: The Difference

React 18 (old way):

const [isPending, setIsPending] = useState(false);
const [error, setError] = useState(null);
const [result, setResult] = useState(null);

async function handleSubmit(e) {
  e.preventDefault();
  setIsPending(true);
  setError(null);
  try {
    const res = await api.submit(formData);
    setResult(res);
  } catch (err) {
    setError(err.message);
  } finally {
    setIsPending(false);
  }
}

<form onSubmit={handleSubmit}>

React 19 (new way):

const [state, formAction, isPending] = useActionState(
  async (prev, formData) => {
    try {
      const res = await api.submit(formData);
      return { success: true, data: res };
    } catch (err) {
      return { success: false, error: err.message };
    }
  },
  { success: null, data: null, error: null }
);

<form action={formAction}>

The React 19 version eliminates:

Three separate useState calls
Manual e.preventDefault()
Manual setIsPending(true/false)
Try/catch/finally boilerplate

When to Use `useActionState`

Form submissions — any form that sends data to a server
Async actions — like/dislike, follow/unfollow, add to cart
Optimistic updates — combine with useOptimistic for instant UI feedback
Server Functions — works seamlessly with React Server Components

When NOT to Use It

Simple synchronous state updates (just use useState)
Complex multi-step wizards (consider a state machine or form library)
When you need fine-grained control over every state transition

Key Takeaways

useActionState consolidates loading, error, and result state into one hook
Works with both form actions (<form action={formAction}>) and imperative calls (dispatch())
The action function receives formData via the standard FormData API
Combine with useFormStatus in child components for pending state
Multiple useActionState calls in one component are independent

The hook is stable in React 19 and ready for production. If you're still writing React 18-style form handlers, it's time to simplify.

Sources:

What's your experience with useActionState? Are you still on React 18 form patterns, or have you made the switch?

Dotnet Report vs. Telerik Reporting: Which Is Right for Your .NET SaaS?

Dotnet Report — Sat, 04 Apr 2026 03:13:09 +0000

If you're evaluating embedded reporting for a .NET SaaS application, Telerik Reporting and Dotnet Report will both appear on your list. They're both mature, .NET-native products — but they're designed around fundamentally different workflows.

The Core Difference

Telerik Reporting is designed for developer-authored report delivery. A developer or report author uses the Telerik Visual Studio designer to create report definitions. Those reports are then delivered to end users who can view and filter them. Users can't build reports from scratch without designer access.

Dotnet Report is designed for user self-service. You expose your data model to Dotnet Report's engine, and your customers use a drag-and-drop builder to create their own reports — choosing columns, setting filters, picking chart types. Developer involvement per report drops to near zero after initial setup.

Multi-Tenant Isolation: The Key Difference for SaaS

Telerik doesn't have built-in multi-tenant isolation. If you serve multiple clients from a shared database, you implement tenant scoping yourself in every report definition. That works but creates maintenance risk — one missed filter can expose one client's data to another.

Dotnet Report enforces isolation at the query layer via a GetCurrentUser endpoint you implement:

[HttpGet("getCurrentUser")]
[Authorize]
public IActionResult GetCurrentUser()
{
    return Ok(new {
        clientId = User.FindFirst("tenant_id")?.Value,
        dataFilters = new[] {
            new { Field = "TenantId", Value = User.FindFirst("tenant_id")?.Value }
        },
        allowedTables = new[] { "Orders", "Customers", "Products" }
    });
}

These filters are applied server-side before any SQL executes. Users cannot override them in the report builder — they're enforced at the query layer, not the UI layer.

Pricing Model Comparison

Telerik Reporting: Per developer per year (~$1,500-$2,000+ per seat as part of DevCraft Complete). Cost rises with team size.

Dotnet Report: Fixed subscription regardless of the number of developers, end users, or tenants. Predictable and flat as you scale.

For SaaS economics, the distinction matters: as you add more customers and grow your team, Telerik costs scale up with headcount. Dotnet Report stays flat.

User Self-Service

Telerik: Provides a Web Report Designer for power users and report authors to create/edit reports in a browser. For non-technical end users who need to build reports from scratch, the UX requires training.

Dotnet Report: The drag-and-drop report builder is designed for non-technical business users. Finance managers, ops leads, customer success teams can build their own reports without SQL knowledge or training. Comparable in difficulty to building a pivot table in Excel.

Full Feature Comparison

Feature	Dotnet Report	Telerik Reporting
User self-service builder	Full drag-and-drop	Limited (power user designer)
Multi-tenant isolation	Built-in at query layer	DIY implementation
Pricing model	Fixed subscription	Per developer per year
Open-source front-end	Yes (MIT license)	No (proprietary viewers)
White-label branding	Full control	CSS theming only
Report scheduling	Built-in, user-configurable	Requires Reporting Server add-on
Dashboard builder	Included	Limited
Pixel-perfect print reports	Operational focus	Strong
Non-relational data sources	Relational only	JSON, CSV, web service, etc.

When to Choose Telerik

You need pixel-perfect, print-layout reports (invoices, regulatory documents)
A dedicated report author creates and maintains all report definitions
You already have Telerik DevCraft licenses
Reporting consumers are internal users, not SaaS customers

When to Choose Dotnet Report

Your customers need self-service (they build their own reports without developer involvement)
Multi-tenant data isolation needs to be bulletproof and enforced at the query layer
You want flat pricing that doesn't scale with developer headcount or tenant count
You need full white-label control (the Angular front-end is open-source)

Full comparison: dotnetreport.com/blogs/dotnet-report-vs-telerik-reporting/

Start a free 30-day trial of Dotnet Report — no credit card required.

DEV Community: dotnet

Why your React Native app can't connect to your local .NET API (And how to fix it)

reactnative, #dotnet, #javascript, and #beginners

Structuring Reusable Search Screens in Razor Pages

The Shape I Wanted

Moving Query Rules Out of the Screen

Why This Worked Better

Trade-Offs

Closing

I Built an MCP Server That Understands Your MSBuild Project Graph — Before You Build

What It Does

10 Tools, Grouped by Purpose

We Predict. They Report.

Security: 15 Measures, Zero Side Effects

333 Tests, 8 Bugs Caught

Get Started

Try It

Agent Middleware in Microsoft Agent Framework 1.0

Not a New Idea

Middleware

Chaining

Execution Order

Why we need it

"Never run destructive SQL. Never send data to personal email."

Middleware fixes both

Result:

1. Agent Middleware-outermost layer

Implementation Styles & Chaining

Class-Based Implementation

Function Based and Decorator Based Styles

Function based

Decorator-based (no type annotation required)

Registering Middleware

When to Use Agent Middleware

2.FunctionMiddleware- The ToolCall Layer

The FunctionInvocationContext Object

When to Use FunctionMiddleware

Terminating the Function Calling Loop

3. ChatMiddleware —The LLM Call Layer

The ChatContext Object

Function Based Example

When to Use ChatMiddleware

Registration: Agent Level vs. Run Level (run scope)

Agent Level Middleware

Run Level Middleware

Choosing the Right Middleware Type

Conclusion

How I built a 20MB Native C# alternative to a 100MB+ Electron app

Enter KeyVibe ⌨️

Try it out!

BRAND IDENTITY DESIGN SERVICE

Why I Stopped Using Local PDF Libraries in my Docker Microservices

Modernizing .NET Architectures for AI-Native Workloads

Table of Contents

1. What AI-Native Actually Means

2. Why Traditional .NET Architectures Struggle with AI

3. The AI-Native Architecture Stack

4. Semantic Kernel as the AI Orchestration Layer

Plugins as domain capability exposure

5. Designing AI-Aware Domain Models

6. Vector Storage and Semantic Memory in .NET

Choosing your vector store

7. The Agent Pattern: Autonomous AI in Your Domain

The principle of least privilege for agents

8. Streaming AI Responses with ASP.NET Core

9. Observability for AI Workloads

The AI observability checklist

10. Guardrails: Safety, Cost Control, and Responsible AI

Token budget enforcement

Input and output validation

The human-in-the-loop pattern

11. Real-World Walkthrough: AI-Native CRM Feature

The feature requirements

The architecture

The output schema

12. Migration Path: Evolving an Existing .NET System

Phase 1 - Add the AI infrastructure (Week 1-2)

Phase 2 - Build the first plugin from an existing service (Week 2-3)

Phase 3 - Build a single AI endpoint with full observability (Week 3-4)

Phase 4 - Add semantic indexing to existing entities (Week 4-6)

What `useActionState` Does

Example 4: With `useFormStatus` for Child Components

When to Use `useActionState`