The art of simplicity

After upgrading the GitHub Copilot SDK to the 1.0.0-beta.10 version, initiating the CopilotClient no longer worked. Instead I got the following error message: System.Text.Json.JsonException: The JSON value could not be converted to System.DateTimeOffset. Path: $.timestamp | LineNumber: 0 | BytePositionInLine: 43.  ---> System.InvalidOperationException: Cannot get the value of a token type 'Number' as a string.    at System.Text.Json.ThrowHelper.ThrowInvalidOperationException_ExpectedString(JsonTokenType tokenType)    at System.Text.Json.Utf8JsonReader.TryGetDateTimeOffset(DateTimeOffset& value)    at System.Text.Json.Utf8JsonReader.GetDateTimeOffset()    at System.Text.Json.Serialization.Converters.DateTimeOffsetConverter.Read(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options)    at System.Text.Json.Serialization.Metadata.JsonPropertyInfo`1.ReadJsonAndSetMember(Object o...

In the previous post talked about why the GitHub Copilot SDK matters: it gives you a production-grade agent harness out of the box, so you can skip building the infrastructure and focus on your actual product. Now let's make it concrete. This post walks through everything you need to get up and running with the SDK in .NET — from prerequisites to a working streaming agent with a custom tool. What we will build We’ll keep it simple. By the end of this post you'll have a console application that: Connects to Copilot's agent runtime Sends a prompt and receives a streaming response Has a multi-turn conversation with persistent context Calls a custom tool you define in C# Prerequisites You'll need three things before touching any code. 1. .NET 8 or later The SDK requires .NET 8+. Verify your version: dotnet --version 2. GitHub Copilot CLI, installed and authenticated The SDK communicates with the Copilot CLI running as a local process — i...

At our organisation running a large fleet of .NET services, a deceptively simple question can be surprisingly hard to answer: what versions of .NET are our apps actually running in production? You'd think this would be easy. It isn't. Services get deployed, teams move on, and before long nobody is quite sure whether that one legacy service is still on .NET 6 — or even .NET Core 3.1. Spreadsheets fall out of date. README files lie. The only source of truth is what's actually running. We solved this with three lines of OpenTelemetry configuration. The problem We run dozens of .NET services across multiple teams. We are the middle of a push to .NET 10, but we have no reliable, centralised way to see the current state. We wanted to answer questions like: Which services are still on end-of-life .NET versions? Which teams still have work to do? After a migration wave, how do we confirm everything moved? The solution We already had OpenTelemetry set up ac...

I only recently started using the ASP.NET Core's minimal API style, but an annoying thing I already encountered is the "long parameter list" problem. Route handlers that accept five, six, or seven parameters start to feel unwieldy fast. The good news is that a solution exists through the [AsParameters] attribute, introduced in .NET 7,  that gives you a clean way out. The problem it solves Minimal APIs are appealing precisely because they're lightweight — no controllers, no ceremony. But that simplicity starts to break down as your endpoints grow more complex. Consider this example endpoint: That's eight(!) parameters before you've written a single line of business logic. It's hard to read, hard to test, and grows more painful every time requirements change. Enter [AsParameters] [AsParameters] lets you group related parameters into a plain C# class or record and bind them all at once. ASP.NET Core inspects the type's constructor and public ...

I'll admit it - I first encountered NullLogger in code generated by an AI coding assistant. At first glance, I almost dismissed it as one of those "AI quirks," but then I realized it was actually a real class available in the .NET Framework that I'd been missing out on. What is NullLogger? NullLogger is part of Microsoft.Extensions.Logging and implements the null object pattern for logging. It's a logger that does absolutely nothing - all of its methods are no-ops. While that might sound useless at first, it's actually quite valuable. Imagine you have the following code: Now when testing this code I would normally mock the logger, but thanks to the built-in NullLogger I no longer have to do that: How to use it In the example above I showed the typical way to get an ILogger<T> instance. There is also a non-generic one to create an ILogger instance: Both are singletons, so you're always getting the same instance - no memory overhe...

If you've been using EventCounters for instrumenting your .NET applications, it's time to consider migrating to the newer System.Diagnostics.Metrics API. Based on the OpenTelemetry specification, the Metrics API offers a more modern, flexible, and standardized approach to application instrumentation. Why migrate? The Metrics API provides several advantages over EventCounters: Industry Standard : Built on OpenTelemetry, ensuring compatibility with a wide ecosystem of monitoring tools Better Performance : More efficient with lower overhead Richer Functionality : Support for histograms, exemplars, and more sophisticated metric types Improved API Design : Cleaner, more intuitive interface for defining and recording metrics Better Tooling Support : Growing ecosystem support from APM vendors and monitoring solutions Microsoft has indicated that EventCounters are in maintenance mode, with new development focused on the Metrics API. So reasons enough to m...

Yes! .NET 10 is out and not only does it come with a new SDK and runtime version, but it is accompanied by a new NuGet version. With this version, Microsoft has significantly strengthened NuGet's security capabilities to help build more secure applications. These enhancements focus on improved vulnerability detection, automated package management, and better tooling for managing your dependency tree. Let's explore what's new and how these features can help protect your projects. Transitive dependency auditing The change with probably the biggest impact is the NuGet Audit's default behavior. For projects targeting .NET 10 or higher, the NuGetAuditMode property now defaults to all instead of direct . This means that NuGet will automatically scan not just your direct package references, but also all transitive dependencies for known security vulnerabilities. That’s good news as a a majority of vulnerabilities are often found in indirect dependencies. In a typical...

NET 10 introduces a new feature for developers: one-shot tool execution. If you've ever needed to quickly run a .NET tool for a CI/CD pipeline, a one-off script, or just to try something out without cluttering your system with globally installed tools, this feature is for you. What is one-shot tool execution? One-shot tool execution allows you to run .NET tools directly without installing them globally or locally on your machine. Instead of the traditional two-step process of installing and then running a tool, you can now execute it in a single command. Some use case where I think you could use this feature : CI/CD pipelines where you want clean, reproducible builds Ephemeral environments like containers or temporary build agents Quick experimentation with tools before committing to installation Scripts and automation that need specific tools without side effects The traditional way vs. one-shot execution Previously, to use a .NET tool, you'd ne...