I want to take a screenshot. In Windows, that's a simple Graphics::CopyFromScreen call.

In Linux, I feel a little confused on how to do this. It seems there is a principal and stark distinction between X11 and Wayland, so I have to include both code paths. For either, it seems there is quite a lot of boilerplate code, often tagged as 'may break depending on your configuration, good luck'.

Effectively, what I found is recommended most often is to call ffmpeg to let it handle that. I'm sure that works, but I find it rather unpalatable.

I find this strange. Taking a screenshot is, in my mind at least, supposed to be a straightforward part of a standard library. Perhaps it is, and I just completely missed it? If not, is there a good library that works out-of-the-box on most variants of linux?

Update: Thank you all for the input. I eventually went with calling ImageMagick. It is fast, easy to use, well documented, and supports capturing arbitrary displays with little effort.

This first push resulted in NuGet Restore times being cut in half, which was a reasonable stopping point for our work. However, along the way, we realized that a more extensive rewrite could improve performance by a factor of 5x or more.

Written from the perspective of several team members, this entry provides a deep dive into the internals of NuGet, as well as strategies to identify and address performance issues.

In the rapidly evolving world of AI and machine learning, effective communication between models and applications is critical. The Model Context Protocol (MCP) is a standardized protocol designed to facilitate this communication by providing a structured way to exchange context and data between AI models and their clients.

The MCP C# SDK is in preview and APIs may change. We will continuously update this blog as the SDK evolves.

The Push Notification Hub (PNH) service recently went through significant modernization. We migrated from legacy components like .NET Framework 4.7.2 and custom HTTP server called “RestServer”, to .NET 8 and ASP.NET Core 8. Moreover, for handling outgoing requests, we moved from custom HTTP client/handler called “HttpPooler”, to Polly v8 and SocketsHttpHandler. This article describes the journey thus far and its impact on PNH performance.

Sections: Intro (what is PNH), expectations, measurement, migration phases (concrete tech and measurements), closing thoughts, next steps.

PNH is deriving great benefits from .NET 8. Overall performance improved, as evidenced by the Q-Factor metric, by about 70%. Performance is a major factor for a service like this and will reflect positively in basically all flows on Teams platform that got to do with messaging. The results actually exceeded our expectations by significant margin.

In order to ensure the long-term sustainability of my OSS projects, I will be commercializing AutoMapper and MediatR.

What Will This Look Like?

The short answer is "I don't know exactly". I'm working out those details now and will share them when I figure it out.

Dev containers are pre-configured, isolated environments that allow developers to work on projects without worrying about dependencies and configurations. They are particularly useful for trying out new technologies, as they provide a consistent and reproducible setup.

The containers are docker containers.

Working together with Cygames to push the limits of performance of both server-side(.NET) and client-side(Unity) C# through open source.

GitHub https://github.com/Cysharp

• MemoryPack: Extreme performance binary serializer for C# and Unity.
• MagicOnion: Unified Realtime/API framework for .NET platform and Unity.
• ConsoleAppFramework: Micro-framework for console applications to building CLI tools for .NET.
• MasterMemory: Embedded Typed Readonly In-Memory Document Database for .NET and Unity.
• ZString: Zero Allocation StringBuilder for .NET and Unity.
• UniTask: Provides an efficient async/await integration for Unity.

The libraries look very interesting.

These services run on Azure compute and are primarily .NET based.

[.NET Aspire] lets us find all of those minor issues locally, and removes much of the need for full deployment to do our basic hookup validation.

.NET Aspire also automates emulator usage for Azure dependencies out of the box