Author: DKN

DKN

Permission Denied ! – when i Opened folder from WSL inside vscode and tried creating a file .

I ran into this issue when i tried to create a file . The solution is to run the following command

sudo chown -R bond007:bond007 /home/bond007/MyWorkSpace/Projects/2026

it will ask you for the password . enter the password and it is done . after that you can create any files within the directory .

happy coding 💌

DKN

Streamlining Power Platform ALM with Native Dataverse Git Integration

Managing the application lifecycle in Power Platform has always involved balancing the needs of citizen developers, professional developers, and IT administrators. With the introduction of native Git integration in Dataverse, Microsoft has significantly simplified this process — making source control accessible to the entire team without requiring deep DevOps expertise.

What Is Dataverse Git Integration?

Dataverse Git integration allows development teams to synchronize solutions and solution objects across one or more Microsoft Dataverse environments using a supported Git provider such as Azure DevOps or GitHub. The integration is built natively into the solutions experience in Power Apps (make.powerapps.com), meaning makers can interact with source control directly through familiar interfaces — no extra tooling required.

The core recommendation: use Git integration with developer environments only. Use build pipelines to create solution artifacts, and use Pipelines in Power Platform to handle deployments to test and production.

ALM in Power Platform — The Bigger Picture

Power Platform already includes robust out-of-the-box ALM capabilities: solutions as containers for platform objects, environment management, and deployment via pipelines. Git integration takes this further by providing a streamlined, native path to version control — one that works for both makers and developers alike.

Key Benefits of Using Git Integration

  • Source Control as the Source of Truth: Previously, many organizations relied on maker environments as the de facto source of truth simply because non-native Git integration required specialized IT skills to set up. Native Git integration removes that barrier — it can be enabled in just a few steps and offers a familiar interface for all team members.
  • Safety, Auditing, and Compliance: By adopting Git integration, teams automatically follow Software Development Lifecycle (SDLC) best practices. This includes version control, code reviews, and static analysis — all contributing to higher quality, more reliable, and more secure solutions. Traceability and audit trails are built in, helping teams meet compliance requirements.
  • Short-Lived Development Environments: Because your environment’s customizations and configurations are stored in source control, you can spin up new development environments quickly and tear them down just as fast. This reduces storage overhead, encourages experimentation, and enables faster iteration cycles.
  • Fusion Development Teams: Teams that blend low-code makers and professional developers (“fusion teams”) benefit enormously. Each contributor can work independently in their own environment and collaborate by syncing to a shared repository — enabling parallel development without stepping on each other’s work.
  • Protection and Recovery: Storing solutions in source control provides a reliable safety net. If unintended changes occur in an environment, you can quickly restore to any previous version.

Key Concepts to Understand

Unmanaged vs. Managed Solutions

Solutions stored in source control originate from unmanaged solutions in a maker’s environment. Makers can freely add, remove, and update objects that sync to source control when committed. Managed solutions, on the other hand, are built from source control and deployed into downstream environments (test, production) where they cannot be directly edited. This separation ensures source control remains the single source of truth and that all changes flow through the proper channels.

File Formatting for Solution Objects

Git integration introduces a new, human-readable file format for solution objects stored in source control. This format makes it easier to review changes over time. A key improvement: solution objects are no longer duplicated per solution — instead, they’re stored once and can be shared across multiple solutions in the same repository and folder, reducing redundancy.

Code-First Development with Git

Power Platform supports both low-code and code-first development paths. Code-first developers using tools like the Power Platform CLI, Visual Studio, and VS Code extensions can now be fully integrated into the same Git workflow as low-code makers.

Without Git integration, managing code-first objects like Power Apps component framework (PCF) controls and Dataverse plug-ins was difficult — these objects are deployed as compiled assets and aren’t directly editable in the maker portal. Git integration bridges this gap, giving code-first developers a native home in the workflow.

Best Practice: Build Process for Code-First Objects

When code-first objects (such as plug-ins or PCF controls) are deployed directly to an unmanaged solution and then committed to source control, only the compiled (binary) version is stored — not the source code. This can lead to two versions of the same object in the repository, causing confusion and potential drift.

The recommended approach is to build code-first objects through a formal solution build process and import the generated unmanaged solution into the maker environment. This keeps source code as the single source of truth and the built artifacts in sync. You can automate this with Azure Pipelines or GitHub Actions workflows that generate artifacts for use in Power Platform pipelines and Git sync processes.

Getting Started

If your organization is looking to modernize its Power Platform ALM practices, native Dataverse Git integration is a compelling starting point. It lowers the barrier to entry for source control adoption, supports both makers and developers, and integrates naturally with existing Azure DevOps or GitHub workflows.

To dive deeper, check out the official Microsoft documentation on Dataverse Git Integration Overview, and explore how Azure DevOps and GitHub repositories can supercharge your team’s delivery process.

Source: Microsoft Learn — Power Platform ALM documentation

DKN

C# 14 Is Here: Everything You Need to Know (With Code Examples)

Microsoft has shipped C# 14 alongside .NET 10, and it’s packed with quality-of-life improvements that make everyday code cleaner, safer, and more expressive. Let’s walk through every major feature — with fresh, practical examples you can try right now.

1. Extension Members — Properties, Statics, and Operators on Any Type

C# has long supported extension methods. C# 14 takes it much further with the new extension block — you can now add properties, static members, and even operators to types you don’t own.

Imagine you work with strings a lot and want a clean .IsValidEmail check, a .WordCount property, and the ability to repeat a string with *:

public static class StringExtensions
{
    extension(string text)
    {
        // Extension property — use it like: email.IsValidEmail
        public bool IsValidEmail => text.Contains('@') && text.Contains('.');
        // Extension property — use it like: sentence.WordCount
        public int WordCount => text.Split(' ', StringSplitOptions.RemoveEmptyEntries).Length;
    }
    extension(string)
    {
        // Static extension property — use it like: string.Placeholder
        public static string Placeholder => "N/A";
        // User-defined operator — use it like: "hello" * 3  =>  "hellohellohello"
        public static string operator *(string text, int times) =>
            string.Concat(Enumerable.Repeat(text, times));
    }
}
// Usage:
string email = "dev@example.com";
Console.WriteLine(email.IsValidEmail);        // True
Console.WriteLine("hello world".WordCount);   // 2
Console.WriteLine(string.Placeholder);        // N/A
Console.WriteLine("ping! " * 3);             // ping! ping! ping!

This is a game-changer for library authors — your APIs can now feel like true language primitives.

2. The field Keyword — Say Goodbye to Backing Fields

Every C# developer has written a property with validation that forced them to declare a private backing field. The new field keyword lets the compiler generate it for you.

Here’s a UserProfile class that enforces age and username rules — no manual backing fields needed:

public class UserProfile
{
    // Compiler synthesizes the backing field automatically
    public string Username
    {
        get;
        set => field = string.IsNullOrWhiteSpace(value)
            ? throw new ArgumentException("Username cannot be blank.")
            : value.Trim().ToLower();
    }
    public int Age
    {
        get;
        set => field = (value is < 0 or > 150)
            ? throw new ArgumentOutOfRangeException(nameof(Age), "Age must be between 0 and 150.")
            : value;
    }
}
// Usage:
var profile = new UserProfile();
profile.Username = "  Alice  ";  // stored as "alice"
profile.Age = 30;                // fine
profile.Age = 200;               // throws ArgumentOutOfRangeException

Cleaner classes, less noise — and full control over validation logic without the ceremony.

3. Null-Conditional Assignment — Assign Only When It Makes Sense

The ?. operator has been a null-safety staple for reading values. In C# 14, you can use it on the left side of an assignment too — so the right side only executes when the target isn’t null.

Consider an e-commerce scenario where you conditionally update a shopping cart:

public class Cart
{
    public string PromoCode { get; set; }
    public List<string> Items { get; set; } = new();
    public decimal Discount { get; set; }
}
Cart activeCart = GetActiveCart(); // might return null
// Old way — manual null guard required:
if (activeCart != null)
{
    activeCart.PromoCode = "SAVE20";
    activeCart.Discount += 20m;
}
// C# 14 — clean and concise:
activeCart?.PromoCode = "SAVE20";
activeCart?.Discount += 20m;   // compound assignment works too!
// The promo code lookup won't even run if activeCart is null:
activeCart?.PromoCode = FetchBestPromoFromApi();

Notice the last line — FetchBestPromoFromApi() is not called at all if activeCart is null. That’s a real benefit when those calls are expensive.

4. Implicit Span Conversions — High-Performance Code, Less Friction

Span<T> and ReadOnlySpan<T> are the go-to tools for zero-allocation data processing in .NET. C# 14 introduces implicit conversions so you can pass arrays where spans are expected — and vice versa — without manual casting.

// A method that processes data efficiently using ReadOnlySpan
static double AverageTemperature(ReadOnlySpan<double> readings)
{
    double sum = 0;
    foreach (var temp in readings) sum += temp;
    return sum / readings.Length;
}
double[] dailyReadings = { 22.5, 23.1, 21.8, 24.0, 22.9 };
// C# 14: the array converts implicitly — no .AsSpan() call needed
double avg = AverageTemperature(dailyReadings);
Console.WriteLine($"Average: {avg:F1}°C"); // Average: 22.9°C
// Span and ReadOnlySpan also compose more naturally with generics
ReadOnlySpan<char> greeting = "Hello, World!";
Span<char> buffer = new char[greeting.Length];
greeting.CopyTo(buffer);

Less ceremony around high-performance code means it’s easier to adopt these patterns throughout your codebase.

5. nameof with Unbound Generics — Cleaner Type Names

Previously, nameof required a closed generic type like nameof(Dictionary<string, int>) just to get back "Dictionary". In C# 14, you can pass the unbound form directly.

// Before C# 14 — you had to supply dummy type arguments:
string name1 = nameof(Dictionary<string, int>); // "Dictionary"
string name2 = nameof(List<object>);             // "List"
// C# 14 — just use the unbound form:
string name3 = nameof(Dictionary<,>);  // "Dictionary"
string name4 = nameof(List<>);         // "List"
string name5 = nameof(Func<,,>);       // "Func"
// Real-world use: building a generic cache key or log label
public static string CacheKey<T>() => $"cache:{nameof(List<>)}:{typeof(T).Name}";
Console.WriteLine(CacheKey<int>());    // cache:List:Int32
Console.WriteLine(CacheKey<string>()); // cache:List:String

6. Lambda Parameters with Modifiers — No Full Types Required

When a lambda parameter needed a modifier like ref or out, you previously had to write the full type for every parameter, even the ones you didn’t care about. Not anymore.

// A delegate for a try-parse style conversion
delegate bool TryConvert<TIn, TOut>(TIn input, out TOut result);
// Before C# 14 — all parameter types had to be spelled out:
TryConvert<string, int> parseOld = (string text, out int result) =>
    int.TryParse(text, out result);
// C# 14 — just add the modifier, skip the type:
TryConvert<string, int> parseInt  = (text, out result) => int.TryParse(text, out result);
TryConvert<string, bool> parseBool = (text, out result) => bool.TryParse(text, out result);
// Works great for inline swap utilities with ref params:
delegate void Swapper<T>(ref T a, ref T b);
Swapper<int> swap = (ref a, ref b) => (a, b) = (b, a);
int x = 10, y = 20;
swap(ref x, ref y);
Console.WriteLine($"x={x}, y={y}"); // x=20, y=10

7. Partial Constructors and Events — Better Source Generator Support

Source generators are a cornerstone of modern .NET tooling (think: EF Core, SignalR, logging). C# 14 extends the partial keyword to constructors and events, making generator-heavy classes much easier to split between generated and hand-written code.

// File: OrderProcessor.cs  (your hand-written code)
public partial class OrderProcessor
{
    // Defining declaration — no body, no initializer
    public partial OrderProcessor(string region);
    public void Process(Order order) => Console.WriteLine($"Processing in {_region}");
}
// File: OrderProcessor.Generated.cs  (source generator output)
public partial class OrderProcessor
{
    private readonly string _region;
    private readonly ILogger _logger;
    // Implementing declaration — has the body and base/this call
    public partial OrderProcessor(string region) : base()
    {
        _region = region;
        _logger = LoggerFactory.Create(b => b.AddConsole()).CreateLogger<OrderProcessor>();
        _logger.LogInformation("OrderProcessor created for region: {Region}", region);
    }
}

Your hand-written file stays clean and readable. The generated file handles all the plumbing. No mismatch, no duplication.

8. User-Defined Compound Assignment Operators

Custom types can now define their own behavior for compound operators like +=, -=, and *=. Previously this was inferred from the binary operator; now you can override it directly for full control.

public struct Budget
{
    public decimal Amount { get; private set; }
    public Budget(decimal amount) => Amount = amount;
    // Standard addition
    public static Budget operator +(Budget a, Budget b) => new(a.Amount + b.Amount);
    // User-defined compound: += can now enforce a cap rule
    public static Budget operator +=(Budget current, Budget extra)
    {
        var newAmount = current.Amount + extra.Amount;
        return new Budget(Math.Min(newAmount, 100_000m)); // cap at 100k
    }
    public override string ToString() => $"${Amount:N0}";
}
var budget = new Budget(90_000m);
budget += new Budget(15_000m); // would be 105k — capped to 100k
Console.WriteLine(budget);     // $100,000

Getting Started with C# 14 Today

All of these features are available now. To try them out:

C# 14 continues the language team’s philosophy of removing friction without adding complexity. Each of these features solves a real daily annoyance — and the cumulative effect on code readability is significant.

Source: What’s new in C# 14 — Microsoft Learn

DKN

Python Agents Just Got Smarter: Agent Skills Is Now Officially Production-Ready

Microsoft has officially released Agent Skills for Python as a stable, production-ready API inside the Microsoft Agent Framework. If you’ve been holding off on building agent-powered applications because of experimental APIs, it’s time to take a second look.

What Are Agent Skills?

Agent Skills is an open format for bundling domain expertise — instructions, reference documents, and executable scripts — into reusable packages that agents load on demand. Instead of cramming everything into a single system prompt, an agent advertises available skill names, then progressively loads only what it needs for the current task. The result: a leaner context window and agents that stay fast and focused.

Each skill is described by a SKILL.md file (for file-based skills) or equivalent code properties. The agent moves through four stages: advertise → load instructions → read resources → run scripts — fetching only what’s relevant for the job at hand.

Three Ways to Build Skills

The release supports three authoring styles, all treated identically at runtime:

  • File-based skills — A directory containing a SKILL.md, optional scripts, and supporting documents. Ideal for cross-functional teams maintaining skills in a shared repository.
  • Class-based skills — Python classes that package instructions and scripts, distributable via internal PyPI feeds like any other Python package.
  • Code-defined skills — Skills created directly in application code, useful when a skill must be generated dynamically or needs to close over application state.

Built for Enterprise Use

Production readiness means more than a stable API. This release ships with the governance controls enterprises need:

  • Human-in-the-loop approval — The three core skill tools require explicit approval by default. Selectively relax approval for trusted, read-only operations.
  • Controlled script execution — File-based scripts are delegated to a runner you supply, giving full control over sandboxing, resource limits, and audit logging.
  • Filtering — Expose only a curated subset of a shared skill library to a specific agent, with context-aware predicates based on the requesting agent or tenant.
  • Caching — Skills resolve once and are reused, with optional per-key isolation for multi-tenant scenarios.

Real-World Use Cases

  • Policy enforcement — Package HR policies, expense rules, or IT security guidelines as skills. Agents load the right policy at query time for consistent, grounded answers.
  • Support playbooks — Turn troubleshooting guides into skills so agents follow documented resolution steps every time.
  • Multi-team composition — Teams author and publish skills independently; you assemble them into a single agent with no cross-team coordination required.

Getting Started

from agent_framework import Agent, SkillsProvider
from pathlib import Path

skills_provider = SkillsProvider.from_paths(
    skill_paths=str(Path(__file__).parent / "skills"),
    disable_load_skill_approval=True,
    disable_read_skill_resource_approval=True,
)

async with Agent(client=client, instructions="You are a helpful assistant.",
                 context_providers=[skills_provider]) as agent:
    response = await agent.run("Help me with onboarding.")

Learn More

With the Python API now stable, teams can build on Agent Skills in production without worrying about breaking changes — a solid foundation for shipping governed, composable AI agents at scale.

Source: Microsoft Agent Framework Blog

DKN

Your AI Coding Agent Can Now Build and Manage Dataverse — Here’s How

The way enterprise software gets built is changing fast. Rather than manually piecing together APIs, command-line tools, and custom scripts, developers are increasingly turning to AI agents — describing what they need and letting the agent figure out the execution. But for that shift to work with platforms like Microsoft Dataverse, the platform itself needs to be something agents can actually understand and operate.

That’s exactly what Dataverse Skills delivers. Released as an open-source plugin for GitHub Copilot and Claude Code, Dataverse Skills gives AI coding agents deep, practical knowledge of Dataverse — from connecting and authenticating to building schemas, loading data, and running analytical queries. All of it driven by natural language.

What Are Dataverse Skills, Really?

At its core, Dataverse Skills is a plugin that teaches your coding agent how to work with Dataverse. It doesn’t expose a menu of commands for you to choose from. Instead, you describe your goal in plain English, and the agent decides which skills to apply, in what sequence, using which underlying tools.

Think of it as giving your AI agent a domain expert’s knowledge of Dataverse — without you needing to be that expert yourself.

The underlying engine uses the Power Platform CLI (PAC CLI) for authentication, solution management, and automation tasks, paired with the Dataverse Web API and Python SDK for data operations. But you never have to think about any of that. Natural language is the only interface you need.

Three Phases, One Unified Experience

The plugin’s capabilities are organized around three core phases of any Dataverse project:

1. Connect

The agent discovers your Dataverse environments, authenticates using PAC CLI or Azure CLI, registers the Dataverse MCP server, and sets up a consistent project structure. You don’t configure anything manually — the agent handles the entire discovery and initialization process.

2. Build

Once connected, the agent can scaffold full data models from scratch: tables, columns, choice fields, lookup relationships, many-to-many relationships, forms, and views. It picks the right tool for each task — MCP for quick reads, the Python SDK for bulk operations, and the Web API as needed — and registers every component into your solution automatically.

3. Operate

With the schema in place, the agent can load data, run cross-table analytical queries, and bulk-import records from CSV files. Need 50 realistic sample records with domain-specific content generated on the fly? One prompt is all it takes.

Seeing It in Action

Here’s a real example of what this looks like in practice. You open your terminal, install the plugin with a single command, and type:

“I’m building a logistics and inventory management system for Veloce Apparel. I need tables for Warehouses, Products, Suppliers, Shipments, and Incidents — with lookups, a many-to-many between Products and Suppliers, and a self-referential shipment routing chain (tracking a package’s journey through hub transfers). Create everything in a VeloceLogistics solution, load sample data, and show me which shipments are currently delayed or stuck in transit.”

From that single prompt, the agent autonomously:

  1. Discovers your Dataverse environment and configures MCP
  2. Creates the solution using PAC CLI
  3. Builds five tables with choice columns, lookups, and a many-to-many relationship
  4. Generates and runs a Python script to bulk-load realistic sample data
  5. Queries across tables to answer the business question

No toggling between documentation tabs. No manual CLI commands. No context switching. The agent orchestrates everything from end to end.

Works With Both GitHub Copilot and Claude Code

Development teams rarely standardize on a single AI coding tool. Some developers prefer GitHub Copilot; others work with Claude Code. Dataverse Skills was built with this reality in mind. Since the skills are written as plain Markdown files with YAML frontmatter — not compiled binaries or proprietary formats — the same plugin works identically in both environments.

Install it from the plugin marketplace for either agent and you get the same knowledge, the same safety checks, and the same results. One investment, both tools covered.

Open Source and Built to Extend

The project is MIT-licensed and openly available on GitHub. Each skill is a standalone Markdown file — readable, editable, and extensible without any compiled code. Teams can add new skills for their own Dataverse customizations, improve existing ones, or contribute bug fixes back via pull request. The architecture is deliberately approachable for anyone who wants to tailor it to their environment.

A Broader Shift in How Platforms Get Used

Dataverse Skills is more than a productivity tool — it signals a broader direction for enterprise platforms. As AI agents become a standard part of the developer workflow, the platforms they interact with need to be operable through intent, not just through traditional interfaces. Describing what you want and having it built, configured, and queryable in your environment is no longer a future concept. With Dataverse Skills, it’s available today.

Getting Started

Install the plugin with one command:

  • GitHub Copilot (VS Code): /plugin install dataverse@awesome-copilot
  • Claude Code: /plugin install dataverse@claude-plugins-official

Then describe your intent and let the agent do the rest.

Original article: Dataverse Skills: Your Coding Agent Now Speaks Dataverse by Suyash Kshirsagar, Microsoft.

DKN

Say Goodbye to Repetitive Admin Tasks: Dataverse Admin Skills Now in Public Preview

If you’ve ever spent an afternoon clicking through the Power Platform Admin Center to apply the same setting across a dozen Dataverse environments, you’ll understand the frustration. Microsoft has now addressed exactly that pain point with the public preview launch of Dataverse Admin Skills — a capability that brings natural language administration to your coding tool, whether that’s GitHub Copilot or Claude Code.

The Admin Bottleneck Problem

Picture this: your security team requests that auditing be enabled across all 20 of your Dataverse environments — today. Without automation, that means 20 separate logins, 20 sets of clicks, and 20 opportunities for human error. Alternatively, you put in a request to a developer to write a bulk script — and wait.

This is the exact gap Dataverse Admin Skills is designed to close. Instead of navigating admin consoles or waiting on scripts, you simply describe what you want in plain English, and the agent handles the rest.

How It Works

Dataverse Admin Skills operates through two complementary paths:

  • Natural Language (Agentic) Path: Using the Dataverse Skills Plugin inside GitHub Copilot or Claude Code, you describe your intent in plain English. The plugin translates your request into the appropriate PAC CLI commands, executes them against the Dataverse Web API, and gives you a clear summary of what changed. It supports multi-environment parallel execution and enforces built-in safety guardrails — including confirmation prompts before any destructive actions.
  • Direct Scripting Path: The same PAC CLI commands powering the agentic experience are available for use in Bash, PowerShell, or SDK scripts. This makes it ideal for CI/CD pipelines, runbooks, and repeatable automation workflows.

Both paths rely on PAC CLI (v2.6+, .NET Framework) and the Dataverse Web API, ensuring a consistent and trusted execution layer.

A Real Example

Say you type: “Enable AllowMCP setting on all environments starting with Preprod.”

Here’s what happens behind the scenes:

  1. The agent lists your Dataverse environments.
  2. It filters for environments matching your criteria.
  3. It asks you to confirm the target list before making any changes.
  4. It updates each environment in parallel.
  5. It presents a summary table of every change made.

One sentence. No browser tabs opened. No scripts written.

What’s Available Right Now

  • Settings Management: Read and update 37 allowlisted PPAC toggles across environments — covering MCP, audit, retention, recycle bin, search, Microsoft Fabric integration, security, and more. Works on a single environment or in bulk with parallel execution.
  • Bulk Delete: Schedule, monitor, pause, resume, and cancel bulk delete jobs. Safety is built in — confirmation prompts, FetchXML validation, and warnings for system tables help prevent accidental data loss.
  • Long-Term Retention: Enable retention on entities, set archival criteria using FetchXML, and track retention jobs. Particularly valuable for compliance scenarios where data needs to be retained but not kept in active storage.
  • Capacity Management (Coming Soon): Storage breakdowns, growth trends, capacity alerts, and archival recommendations — all accessible from your coding tool.

Getting Started in Three Steps

Step 1: Install the Plugin

  • In GitHub Copilot (VS Code): /plugin install dataverse@awesome-copilot
  • In Claude Code: /plugin install dataverse@claude-plugins-official

Step 2: Connect Your Environments

Open your coding tool and ask: “List all my Dataverse environments.” The agent will install PAC CLI if needed, authenticate you, and return your environment list. If anything is missing, it walks you through setup.

Step 3: Try It Out

Here are some prompts to get started:

  • “Enable the Microsoft Fabric integration on all production environments.”
  • “What is the recycle bin retention period for my sandbox environment?”
  • “Disable Dataverse search across all environments in the Europe region.”
  • “Cancel all system jobs that have been stuck in a waiting state since yesterday.”
  • “Set the long-term retention criteria for the custom log table to archive records older than 2 years.”

Why This Matters

Dataverse Admin Skills represents a meaningful shift in how platform administrators interact with their environments. Rather than being constrained by what a UI exposes or waiting for a developer to write automation scripts, admins can now express intent directly — and act on it at scale. The safety guardrails (allowlists, confirmation prompts, parallel execution controls) mean this power comes without sacrificing governance.

This is currently a public preview release, with Microsoft actively refining and expanding the skill set. Now is a great time to explore what it can do.

Original article: Agentic Administration: Dataverse Admin Skills now available in Public Preview by Anirudha Bakore, Microsoft.

DKN

Deno 2.9: Build Native Desktop Apps, Faster Startup, and a Smarter Toolchain

Deno 2.9 is out, and it’s one of the most feature-packed releases in the runtime’s history. The headline is deno desktop — a new way to ship native desktop applications straight from the JavaScript and TypeScript stack you already use, with no Electron boilerplate and a single binary at the end. But that’s only part of the story. Cold starts are roughly twice as fast, memory use under load has dropped to a third of what it was in 2.8, and migrating an existing npm or pnpm project to Deno is now a matter of a couple of commands.

To upgrade: deno upgrade

deno desktop: Native Apps From Your Web Stack

Building a desktop app has traditionally meant picking up Electron or Tauri, learning a separate toolchain, and shipping an artifact that bears little resemblance to the rest of your codebase. Deno 2.9 changes that with deno desktop.

Point it at any script or web framework project and it produces a native, self-contained desktop application where the UI runs in a webview and your logic runs in Deno. Because deno desktop is built on the same machinery as deno compile, the output is a single distributable binary with your code and assets embedded — no installer wizard, no runtime dependency on the host machine.

The simplest possible app is just a Deno.serve() call — the webview automatically binds to the port the server opens, so there’s no port wiring to configure:

// main.ts
Deno.serve(() =>
  new Response(
    "<!DOCTYPE html><h1>Hello from Deno desktop!</h1>",
    { headers: { "content-type": "text/html" } },
  )
);
// Then run:
// deno desktop main.ts

deno desktop also shares the framework auto-detection introduced in 2.8. Run deno desktop . in a Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, or Vite SSR project and it will detect the framework, build it, and wrap the result automatically. Add --hmr for hot module replacement during development.

Native Desktop APIs Built In

Richer applications get a full set of native APIs available immediately under Deno.*, with no extra packages to install:

  • Deno.BrowserWindow — programmatic control over window size, position, visibility, menus, and DevTools. Bridge between the webview and Deno by binding a function with window.bind() and calling it from page JavaScript via the bindings namespace.
  • Deno.Tray — system-tray icons and panels on all platforms.
  • Deno.Dock — macOS Dock integration.
  • Deno.autoUpdate() — a polling auto-updater that applies binary patches in the background.
  • prompt(), alert(), and confirm() render as native OS dialogs.

Webview or Bundled Chromium

Every deno desktop app needs a browser engine to render its UI. You choose with the --backend flag:

  • webview (default) — uses the OS’s built-in engine (WebView2 on Windows, WebKit on macOS and Linux). Nothing extra is bundled, so binaries stay small and start instantly.
  • cef — bundles Chromium via the Chromium Embedded Framework, guaranteeing the same modern rendering engine on every platform. It adds tens of megabytes but ensures identical behaviour across Windows, macOS, and Linux.

Most apps are happy with the default webview; reach for cef when rendering consistency across platforms is non-negotiable.

Cross-Platform Distribution From a Single Machine

Distribution format follows the extension you pass to --output: .app or .dmg on macOS, .exe or .msi on Windows, .AppImage, .deb, or .rpm on Linux. You don’t need a fleet of build machines. --target cross-compiles to any supported platform and --all-targets builds them all in one command — the Windows .msi and Linux .deb/.rpm installers are authored in pure Rust, so they’re produced from any host without platform-specific packaging toolchains.

deno desktop --output MyApp.dmg main.ts                  # build for the host
deno desktop --target x86_64-pc-windows-msvc main.ts     # cross-compile to Windows
deno desktop --all-targets main.ts                       # build all five targets at once

Note: deno desktop is experimental in 2.9. The API is stabilising and some platform features are still landing. Full documentation is at docs.deno.com/runtime/desktop.

Performance: Twice as Fast, One-Third the Memory

Deno 2.9 ships substantial performance improvements across the board:

  • Cold start: A hello-world program now starts in ~17 ms, down from ~34 ms in 2.8 — nearly 2x faster.
  • Memory: Resident set size under Deno.serve workloads is now essentially flat regardless of payload size — ~62 MB steady-state vs up to 197 MB in 2.8. That’s 3.1x less peak memory on 1 MiB body workloads.
  • HTTP throughput: Deno.serve is 11–27% faster across plaintext, real-world JSON, and large-body workloads, thanks to a new Deno-owned HTTP/1.1 serving path.
  • Crypto and inspect: crypto.subtle and console/Deno.inspect hot paths have been ported from JavaScript to Rust, reducing per-call overhead.

Migrating From npm, pnpm, yarn, or Bun Is Now Trivial

The biggest friction when switching package managers has always been the risk of accidentally upgrading pinned dependencies. Deno 2.9 eliminates that concern entirely. Run deno install in a project that has a package-lock.json, pnpm-lock.yaml, yarn.lock, or bun.lock and Deno will seed a fresh deno.lock directly from it, carrying over every resolved version and integrity hash. No re-resolution, no surprise upgrades.

pnpm workspaces, which previously caused confusing resolution errors because their configuration lives in a separate pnpm-workspace.yaml, are now handled automatically: Deno detects the file and migrates its packages, catalog, and catalogs entries into your deno.json without touching your comments or existing fields.

Build tools that shell out to a node binary directly (like Next.js’s Turbopack worker pool) also work without intervention: when no real node is installed, Deno now puts a stand-in on PATH that forwards to itself and translates Node’s CLI arguments. Set DENO_DISABLE_NODE_SHIM=1 to opt out.

A Much Stronger Test Runner

Deno 2.9 closes the gap between the built-in test runner and tools like Vitest and Jest with a wave of new features:

  • Snapshot testing: t.assertSnapshot() is now built directly into the test context, no import required.
  • Change-aware test selection: deno test --changed runs only the tests affected by your uncommitted changes; --changed=origin/main scopes that to a branch diff. Selection walks the full module graph, including across workspace members.
  • Retries and repeats: deno test --retry=2 re-runs failing tests up to two extra times; --repeats=5 runs each test five times and requires all passes. Tests that only pass after a retry are flagged as flaky in the summary.
  • Coverage thresholds: deno coverage --threshold=90 fails the run when line, branch, or function coverage drops below a target, configurable per-metric in deno.json.
  • Sharding: deno test --shard=2/3 splits test files into balanced groups for parallel CI runs.
  • Parameterised tests: Deno.test.each([...]) registers one independently-filterable test per case from a data table, with printf-style name interpolation.

Supply Chain Security Gets Smarter Defaults

Two supply chain guards are now active or available:

  • Minimum dependency age (24 hours, on by default): Deno refuses to install any npm package version published within the last 24 hours. Most malicious packages are detected and unpublished within a day of release, so this single default catches a large class of supply-chain attacks silently. Configurable in .npmrc with min-release-age=72h to wait longer, or min-release-age=0 to opt out entirely.
  • no-downgrade trust policy (opt-in): Enables a provenance-aware trust check that refuses to resolve a package version whose publication trust evidence is weaker than that of any earlier version of the same package — the hallmark of a compromised maintainer token. Enable with trust-policy=no-downgrade in .npmrc.

More Highlights Worth Knowing

  • CSS module imports: import sheet from "./styles.css" with { type: "css" } now works in Deno (under --unstable-raw-imports), returning a CSSStyleSheet instance that runs identically in Deno and in the browser.
  • deno task input-based caching: Declare a task’s files inputs in deno.json and Deno skips the task entirely when nothing relevant has changed, restoring output artifacts from cache.
  • deno link / deno unlink: Manage local package links from the CLI rather than hand-editing config.
  • deno list: A new subcommand that prints declared dependencies and their resolved versions, the equivalent of npm ls.
  • Post-quantum cryptography: crypto.subtle now supports ML-KEM, ML-DSA, SLH-DSA (FIPS 203/204/205), ChaCha20-Poly1305, the SHA-3 family, and Argon2 key derivation.
  • Node.js 26 compatibility: The compatibility target advances to Node 26, and bare node builtins (import "fs") now resolve without any flags.
  • deno watch: A new, more discoverable alias for deno run --watch-hmr.
  • Web Locks API: Full support for navigator.locks for coordinating access to named resources across async tasks and workers.

Getting Started

Upgrade with deno upgrade, or install fresh from deno.com. The full changelog is on GitHub, and the deno desktop documentation is at docs.deno.com/runtime/desktop. For a complete real-world example of a deno desktop app, check out denidian, a note-taking app built with the new feature.

Source: Deno Blog — Deno 2.9 by Bartek Iwańczuk

DKN

How the Agent-to-Agent (A2A) Protocol is Reshaping Multi-Agent Collaboration

A year ago, Google introduced the Agent-to-Agent (A2A) protocol — a communication standard designed from the ground up for the era of generative AI. Where traditional APIs are rigid and deterministic, A2A was built for agents: fluid, autonomous systems that need to collaborate, hand off tasks, and maintain secure boundaries without getting in each other’s way. As A2A celebrates its first anniversary, the ecosystem has grown far beyond what most anticipated.

The Problem With Treating Agents Like APIs

If you’ve built with AI agents before, you’ve likely hit the wall of trying to wire them together using conventional REST APIs. It works — until it doesn’t. Standard APIs return data or errors. They can’t ask clarifying questions, refine an ambiguous request, or adapt mid-task. And when you start chaining multiple agents together, context windows overflow, proprietary logic leaks, and the whole system becomes a fragile monolith.

A2A was designed to solve these problems at the architectural level. Here’s how:

1. Secure Boundaries — Protecting Your “Secret Sauce”

Enterprise agents often need to work with sensitive internal data or proprietary business logic that should never be exposed to an external system or a public LLM. A2A enables a clean “black box” handoff: you assign a task to a specialized internal agent, it executes in its own secure environment, and only the high-value output is returned. Your data and how-to logic stay encapsulated and private throughout.

2. Zero Context Pollution

Every LLM has a finite context window. Force a primary agent to manage complex, multi-step dependencies on top of a conversation, and you’ll quickly see hallucinations and degraded output quality. With A2A, specialized peer agents manage their own state and dependencies, handling complexity internally without ever crowding the primary agent’s memory. Each participant keeps its focus.

3. Dynamic Autonomy

An API either returns a result or fails. An A2A peer agent does something fundamentally different: it collaborates. It can interpret intent, ask for clarification when the request is incomplete, push back on ambiguity, and adapt its approach based on intermediate results. This transforms inter-agent communication from a data transfer into a genuine working relationship.

4. Distributed Workloads and Modular Design

Instead of one team building an entire agentic solution end-to-end, A2A enables workload distribution. Different components of a solution can be developed and maintained by separate teams, vendors, or managed agentic services — each a domain expert in their slice. The result is a modular architecture that is easier to build, easier to test, and far easier to evolve over time.

Real-World Spotlight: FoldRun and Protein Structure Prediction at Scale

To understand how A2A works in practice, consider one of the hardest problems in biology: predicting a protein’s 3D structure. It requires petabyte-scale genetic databases, specialized GPU infrastructure, and orchestration across multiple AI models (AlphaFold, OpenFold, Boltz). For a developer, building this from scratch is an enormous undertaking.

FoldRun reimagines this entirely. Rather than a fragile pipeline of glued-together APIs, FoldRun is a self-contained, agentic interface. You add it to Gemini Enterprise, the Gemini CLI, or any A2A-compatible environment, assign a structure prediction task in natural language, and FoldRun takes over — managing long-running autonomous tasks, dynamically choosing between models based on prediction confidence, and delivering results as a specialized peer agent. No custom glue code required.

“Having a solution that allows our scientists to use co-folding models with an agentic interface — one which our organization is embracing through Gemini Enterprise — has made testing and integration with workflows much easier.”

— Richard Hughes, BicycleTx

What Else Is the Ecosystem Building?

The A2A community has expanded well beyond life sciences. Here’s a snapshot of where developers are taking the protocol:

  • Agentic Commerce and Autonomous Payments: AI agents are being used to negotiate deals, verify inventory, and execute B2B transactions on behalf of users — with A2A providing the transactional integrity layer.
  • Enterprise Data and Real-Time Streaming: Specialized A2A agents sit at the edge of live event streams and databases, extracting insights and triggering downstream workflows only when specific, compliance-approved conditions are met — without ever exposing raw data to a central model.
  • Cross-Platform IT and DevOps: Operational silos are dissolving. An HR agent can now hand off provisioning parameters to a DevOps peer agent via A2A, which then autonomously configures software licenses, repository access, and secure environments across disconnected SaaS platforms.
  • Secure Telecom and Regulated Networks: In sectors where data exposure is not an option, A2A is being used to implement quantum-safe, end-to-end Message Layer Security (MLS) for autonomous systems — enabling agent collaboration on sensitive data without any underlying information escaping the secure channel.

How to Get Started

The official A2A SDKs are the fastest on-ramp to the ecosystem:

  • Python and Go: Version 1.0 GA — stable and production-ready
  • Java: Beta, tracking the 1.0 spec
  • .NET: Preview, on track for GA
  • JavaScript / TypeScript: Stable on v0.3; 1.0 work in progress

Whether you are building an agent from scratch or extending an existing system to interoperate with the ecosystem, the path to A2A compliance has never been more straightforward.

The Bigger Picture

The shift A2A represents is more than a new protocol. It’s a move away from AI as a monolith — one massive agent trying to do everything — toward AI as an ecosystem: a network of specialized, collaborating agents, each excellent at its job, each secure in its own domain, each able to hand off and receive work through a common language. One year in, that vision is no longer theoretical. It’s shipping code.

Source: Google for Developers Blog — How A2A is Building a World of Collaborative Agents by Alan Blount, Frank Guan, and Nick Losier

DKN

Building Intelligent Agents with Microsoft Agent Framework: The Harness and Claw Explained

What if you could build a fully functional AI agent — one that plans, searches the web, calls your own custom tools, and remembers context across sessions — without wiring together a dozen different libraries? That’s the promise of Microsoft Agent Framework’s harness model, and this post walks through exactly how it works.

This is Part 1 of the Build Your Own Claw series. The guiding example is a personal finance assistant, and by the end you’ll have an interactive terminal agent that can look up stock prices, pull in live market news, and build a step-by-step investment plan on request.

What Is a “Harness” and What Is a “Claw”?

The terminology is deliberately visual. A claw is an agent loop — the thing that wraps a language model, connects it to tools, and keeps the conversation going. A harness is the scaffolding Microsoft Agent Framework provides around that loop: function invocation, conversation history, planning, web search, and file memory are all bundled in by default. You supply the two things that make your agent unique — its purpose (instructions) and its domain-specific tools — and the framework handles everything else.

Step 1: Connect to a Model

Every agent starts with a chat client — the component that communicates with an underlying language model. The framework treats this as a standard interface (IChatClient in .NET), so you can point it at Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic, Google Gemini, Ollama, or any other supported provider without changing the agent code.

For the finance assistant, the setup reads two environment variables — FOUNDRY_PROJECT_ENDPOINT and FOUNDRY_MODEL — and authenticates using Azure’s DefaultAzureCredential. Run az login locally and it just works; in production, swap in a ManagedIdentityCredential for tighter security.

The key insight here: the harness is provider-agnostic. Switching from Foundry to OpenAI is a one-line change in the client setup — the rest of the agent stays the same.

Step 2: Wrap the Client in the Harness

This is where the framework’s value becomes obvious. A single call — AsHarnessAgent() in .NET or create_harness_agent() in Python — transforms the bare chat client into a full agent. You pass in two things:

  • Instructions — a natural language description of what the agent does and how it behaves. For the finance assistant this includes guidance on always verifying numbers with tools, citing sources, and maintaining a watchlist in a watchlist.md memory file.
  • A custom tool — a plain function (get_stock_price) that the model can invoke when it needs live data. The framework automatically generates the JSON schema from the function’s signature and parameter descriptions.

In return, the harness activates everything else automatically:

  • Web search is added as a hosted tool — ask “Any recent news on NVDA?” and it works out of the box, no extra code required.
  • Planning is enabled via a built-in TodoProvider and AgentModeProvider — so a vague request like “Review my watchlist and recommend some stocks to add” becomes a structured, step-by-step plan.
  • File memory is wired up so the agent can persist information (like your watchlist) across sessions.
  • History persistence is handled per service call.

Nothing about web search or planning required any custom implementation — those capabilities came free the moment the harness was created.

Step 3: Run the Interactive Console

Microsoft Agent Framework ships a ready-made terminal UI — the harness console — designed to be copied and adapted as a starting point for any interface (web app, chat surface, IDE extension, etc.). It outputs in colour by mode: cyan for planning, green for execution, and includes built-in commands like /todos, /mode, and /exit.

A typical interactive session with the finance assistant might look like:

  1. Switch to execute mode: /mode execute
  2. Ask for a price: “What’s the price of MSFT?” — the agent calls get_stock_price
  3. Ask for news: “Any recent news on NVDA?” — the agent uses web search
  4. Build a watchlist: “Add MSFT, NVDA and SPY to my watch list” — saved to watchlist.md
  5. Switch to plan mode: /mode plan
  6. Request analysis: “Review my watchlist and recommend some stocks to add” — the agent plans, asks clarifying questions, then executes

Sessions can be saved to disk with /session-export and restored later with /session-import, preserving conversation history, the watchlist, and all context-provider state.

How Plan Mode Actually Works

Plan mode isn’t magic — it’s structured output. When the agent is in plan mode, the console’s planning observer overrides the response format to request a JSON schema-constrained reply instead of free-form text. The model is forced into one of exactly two shapes:

  • Clarification — the model needs more information. It returns one or more questions, each optionally accompanied by suggested choices that the console renders as selectable options.
  • Approval — the model has a complete plan. It returns a single summary and the console prompts you to approve before anything executes.

This design makes agent behaviour feel deliberate and safe: the agent gathers what it needs, presents a plan, and only switches to execute mode after you sign off. The PlanningResponse schema ships with the console sample in both .NET and Python, so you can extend or reshape it to match your own UX requirements.

Toggling Features On and Off

Everything the harness enables — todos, planning modes, web search, file memory, file access, and tool approval — is on by default and individually toggleable. If your use case doesn’t need planning or web search, you disable them with a single option flag:

  • .NET: DisableTodoProvider, DisableAgentModeProvider, DisableWebSearch, DisableFileMemory, DisableFileAccess, DisableToolApproval
  • Python: disable_todo, disable_mode, disable_memory, disable_web_search

The recommended approach is to start with everything enabled and trim to taste once you understand what your agent actually needs.

You Don’t Have to Use the Full Harness

The harness is a convenience layer, not a mandatory container. All of the underlying pieces — web search (a plain tool), planning modes (a context provider), and todos (another context provider) — are individually accessible. You can cherry-pick exactly what you need and plug them into any agent architecture, even one that doesn’t use the harness at all. In .NET, the mode and todo providers live in the Microsoft.Agents.AI package; in Python, everything ships in the agent-framework package.

Try It Yourself

Both the .NET and Python runnable samples are available on GitHub:

What Comes Next

The finance assistant can now look things up, search the web, and produce structured plans. But it can’t touch your files directly, and there’s nothing yet preventing it from taking a sensitive action without asking. Part 2 of the series addresses both: granting file access, gating risky operations behind explicit approvals, and adding durable memory so the agent remembers your preferences between sessions.

Source: Microsoft Dev Blogs — Meet your agent harness and claw by Wes Steyn, Principal Software Engineer

DKN

WSL Containers: A Game Changer for Linux on Windows

At Microsoft Build 2026, Microsoft introduced WSL containers — a major evolution in Linux container development directly on Windows through the Windows Subsystem for Linux (WSL). Containers have become a cornerstone of modern development, from cloud-native applications and AI workloads to testing and deployment pipelines. WSL containers simplify this experience by providing a built-in, enterprise-ready way to create, run, and manage Linux containers on Windows, without requiring additional third-party tooling.

You can access the WSL container feature in the latest pre-release of WSL right away by running wsl --update --pre-release, or by downloading and installing it directly from GitHub.

Overview

WSL container adds two major new features to WSL:

  • A built-in Linux container CLI (wslc.exe)
  • An API for Windows applications to run Linux containers as part of their app logic

WSL Container CLI – wslc.exe

When you update to the latest WSL version, you get a new binary on your path: wslc.exe. This CLI tool supports full Linux container development workflows — running, debugging, testing, and more — with a familiar format that respects your existing muscle memory.

For example, you can run a full Linux desktop in a container:

wslc run -d --name=webtop -e PUID=1000 -e PGID=1000 -e TZ=Etc/UTC -p 3000:3000 -p 3001:3001 lscr.io/linuxserver/webtop:ubuntu-kde

Or check GPU access with a CUDA script:

wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

There is also a built-in alias container.exe that maps to wslc.exe, so you can use either command interchangeably.

WSL Container API

Windows applications can now directly use containers as part of their application logic. WSL ships a NuGet package (available on nuget.org and the WSL releases page) with support for C, C++, and C#.

This API integrates with MSBuild and CMake, meaning you can add a few lines to your project files and have container build and deploy steps become part of your application’s build process — no manual steps required. You can git clone and try a sample or check out the full API reference.

Integration with Enterprise Tools

Monitor Security Events with Microsoft Defender for Endpoint (MDE)

WSL’s existing MDE plugin has been updated to be aware of Linux container events, providing the same security coverage whether you are using a WSL distro or containers. This feature is currently available as part of a private preview which you can sign up for here.

Manage WSL Container Settings with Intune

New management settings for WSL container are being added, allowing organizations to:

  • Control whether users can use WSL distros or containers
  • Specify an allowlist of container registries for pulling images

This addresses the top customer ask: “How can I control which distros/Linux images are allowed in my organization?” Currently available via GPO and an ADMX policy, with official Intune dashboard support coming within a few weeks.

VS Code Dev Containers

WSLc support has been added to VS Code Dev Containers in version 0.462.0-pre-release. To set it up, open the VS Code Dev Container settings, find the “Docker Path” setting, and change it to wslc. This is currently in pre-release and will soon move to general availability.

Further WSL Improvements

Alongside the container feature, Microsoft is making significant improvements to the underlying technology powering both WSL and WSL container:

  • New default file system (virtiofs): Makes Windows file access 2x faster
  • New default networking mode (Consomme): Relays Linux network traffic through Windows, allowing Linux applications to benefit from the same networking environment, security policies, and enterprise integrations available to Windows applications
  • Improved memory reclaim techniques: Gradually and consistently releases memory back to the Windows host when not in use

These lower-level platform changes will also benefit other container tools built on WSL, such as Docker Desktop, Podman Desktop, and Rancher Desktop.

Learn More

You can view the presentation from Build 2026 to learn more about the use cases and see demos. Additionally, visit the WSL container docs page for in-depth guides and sample code.

Feedback and What’s Next

This feature is currently in the pre-release version of WSL as a public preview. Microsoft aims to make WSL containers generally available in fall 2026. Install it, try it out, and file issues and feedback at the WSL GitHub page.

Source: Microsoft Dev Blogs – WSL container is now available for public preview by Craig Loewen, Senior Product Manager