The art of simplicity

Security vulnerabilities in your dependencies are one of those things where I know that I should address them promptly, but the process of hunting down the right package version, understanding the scope of the issue, and making the change without breaking anything can turn a five-minute fix into a frustrating rabbit hole. With the Visual Studio March 2026 update, that workflow just got a whole lot smoother. GitHub Copilot can now help you fix NuGet package vulnerabilities directly from Solution Explorer, turning what used to be a manual research task into a guided, in-editor experience. What's new? When Visual Studio detects a vulnerability in one of your NuGet packages, you'll now see a Fix with GitHub Copilot link alongside the vulnerability notification in Solution Explorer. One click is all it takes to kick off the process: Copilot analyzes the vulnerability, identifies the appropriate dependency updates, and implements them for you — without disrupting the rest of y...

With the Data API builder, you can easily generate an API on top of an existing database. However typing out the configuration settings in the dab-config.json isn't much fun. The auto-entities features I talked about before can certainly help, but that is not always the right solution. With the integrated GUI in the MSSQL extension for Visual Studio Code, you can replace the manual JSON configuration with a visual interface that handles entity selection, CRUD permission mapping, API type targeting, and Docker-based local deployment — all without leaving the editor. This post covers exactly what the UI does, what it generates, and where it falls short. Entry points The DAB configuration view is accessible from two places: Object Explorer — right-click a database node → Build Data API (Preview)... Schema Designer — Design API button (top-right toolbar) or the Backend icon in the left panel Both open the same configuration surface. Entity selection Tables a...

While creating a workflow system with the Microsoft Agents SDK, I encountered the following error message when testing my workflow: System.InvalidOperationException: Cannot use a Workflow that is already owned by another runner or parent workflow. at Microsoft.Agents.AI.Workflows.Workflow.TakeOwnership(...) at InProcessRunnerContext..ctor(...) at InProcessRunner.CreateTopLevelRunner(...) It's cryptic if you haven't seen it before. But once you understand the ownership model, the fix is straightforward. What's actually happening .NET workflow runtimes treat workflow instances as stateful, non-reentrant objects. When a runner picks up a workflow, it takes exclusive ownership of that instance. No other runner — and no parent workflow — is allowed to touch it while that ownership is held. This is by design. Workflows accumulate state as they execute, and allowing two runners to share that state simultaneously would corrupt it. The runtime enforces ow...

Data API builder 2.0 (currently in public preview) is a major release focused on MCP and AI integration. Among its headline features is the ability to expose stored procedures as custom MCP tools , making them discoverable and callable by AI agents. No glue code, no middleware, no extra plumbing. In this post I'll walk through how the feature works, and show a practical example: wiring up a full-text search stored procedure as its own dedicated tool that any MCP client can discover and call by name. The idea: a dedicated search tool By default, DAB's SQL MCP Server exposes tables and views through generic DML tools — things like list_books , get_book , and so on. These are useful for straightforward CRUD, but they're not designed for complex operations like full-text search. With custom-tool: true , you can go further. Set that flag on a stored-procedure entity and DAB dynamically registers the procedure as a named, purpose-built tool in tools/list . The AI agent di...

If you've been maintaining a large dab-config.json , you know the pain: every table, view, and stored procedure needs its own entities block. Schema grows, config grows. Someone adds a table and forgets to update the config, and suddenly your API is silently missing endpoints. DAB 2.0 Preview introduces autoentities — a pattern-based approach that discovers and exposes database objects automatically, every time DAB starts. This post covers how it works, how to configure it from the CLI, and what to watch for. Getting started As DAB 2.0 is still in preview, you first need to install the preview version: dotnet tool install microsoft.dataapibuilder --prerelease Note: MSSQL data sources only, for now. Initialize a new dab-config.json file if it doesn't exists yet: dotnet dab init Remark:  Notice that we prefix dab with dotnet to avoid collisions with the globally installed release version. How it works Instead of defining each entity explicitly, you define one ...

After pulling some NuGet packages into my .NET Aspire project, I ran into this cryptic startup failure: Aspire.Hosting.DistributedApplicationException: Newer version of the Aspire.Hosting.AppHost package is required to run the application. Ensure you are referencing at least version '13.2.2'. at Aspire.Hosting.Dcp.DcpDependencyCheck.EnsureDcpVersion(DcpInfo dcpInfo) at Aspire.Hosting.Dcp.DcpDependencyCheck.GetDcpInfoAsync(...) at Aspire.Hosting.Dcp.DcpHost.StartAsync(...) The app host refuses to start, and the logs point you toward a version check deep inside DCP internals. The error message tells me that a minimum version of the hosting package is required,but no matter how many times I ran dotnet restore or update NuGet packages through Visual Studio, the error persists. That's because there are two places that pin the Aspire version. Why updating NuGet packages isn't enough Aspire AppHost projects use a special SDK reference at the very...