290 posts tagged with ".NET"

A real .NET C# Web API usually isn't one project. It's a solution: the API itself, plus one or more class libraries for code that doesn't belong in the web layer, such as the database code. This guide builds that structure from the command line with .NET 10, adds the settings that production projects use, and fixes the two errors those settings raise on the template's own code.

A .NET C# project fills up with files that should never be committed: build output in bin and obj, editor settings, and secrets such as .env. The .NET SDK ships a ready-made .gitignore that covers all of them, and one command adds it to your project. This guide adds it, shows what it ignores, and proves a file is really ignored.

I changed four lines of a .NET project file, and Git reported 32. The ASP.NET Core Web API template creates its files with Windows line endings (CRLF), even on a Mac, while the dotnet commands that later edit a file save it with LF. To Git, every line of such a file looked different. One .gitattributes file, as Git's own documentation describes, stores every text file with LF and ends the noise.

The first build of a brand-new .NET 10 Web API failed with error CA1852 on the template's own WeatherForecast record. The solution turns on Microsoft's recommended code-quality rules and treats warnings as errors, and one of those rules asks for types like this one to be sealed. Adding that one word fixes it.

dotnet restore said Restore succeeded, with one warning: Unable to find a project to restore!. Nothing had been restored. I had run it in a folder whose solution file didn't list any projects yet, so that's what it restored: nothing. Pointing it at the project, or adding the project to the solution first, fixes it.

I created an ASP.NET Core Web API project inside a .NET 10 solution that manages package versions centrally, and the template's own restore failed with error NU1008. The template writes a package version into the project file, which central package management doesn't allow. Moving that one version to Directory.Packages.props fixes it.

An agent that you serve with Microsoft Agent Framework's MapAGUIServer answers every request as if it had never met you — until the server has somewhere to keep conversations. That place is a session store. This guide adds one for development, shows the same follow-up question before and after, and explains where the history really ends up.

An AG-UI request carries three IDs: threadId, runId and parentRunId. When the server remembers conversations, a follow-up keeps the first, changes the second, points the third at the turn before — and carries only the new message. This guide shows each request and what the server sends back, from a real agent.

Some code belongs only on a developer's machine: an in-memory store, a relaxed setting, a debugging aid. ASP.NET Core knows which environment it runs in, and one if around builder.Environment.IsDevelopment() keeps that code out of everywhere else. This guide shows the check, where to put it, and how to try the other branch on your own machine.

I gave a Microsoft Agent Framework agent a session store so it would remember conversations, and every request started failing with a 500: Agent isolation key is required but was not provided by the configured AgentIsolationKeyProvider. I had configured no provider at all. The default store wanted to know who was calling, and my API had no way to tell it.