DEV Community: Andreas Nägeli

TechEmpower Framework Benchmarks are now Archived - What's next?

Andreas Nägeli — Tue, 24 Mar 2026 11:48:56 +0000

On 24th of March 2026, the TechEmpower Framework Bechmarks have been discontinued, with their GitHub repository now in archived mode.

The Start

The first round of the TechEmpower Framework Benchmarks dates back to March 2013, covering only as much as 25 different frameworks. Within the following years, all major HTTP web framework implementations where added through contributions to their public GitHub repository, making the project an important litmus test for the performance characteristics of HTTP webservers and application development frameworks. In the most recent Round 23 from February 2025, more than 330 framework implementations were covered.

As it got more and more traction, having good results became a top priority for framework developers for their new software releases. In round 13, Microsoft started to sponsor the project with hardware and used their now first position in the benchmarks to fuel their marketing for ASP.NET Core. Overall, the benchmark's sole existence lead to way faster frameworks for all of us.

The Decline

Although results have continued to be published once a year, there have been virtually no changes or updates to the underlying test platform in recent years. High performance frameworks were capped in plaintext at roughly 30 milion requests per second, due to a combination of wrk and large request headers being sent by the tests. Even though framework developers adressed such topics, the maintainers of TechEmpower did not show much effort to improve those points.

Additionally, the maintainers allowed frameworks to use low-level tricks to get the most out of their framework, causing the results to reflect more a socket benchmark then actual real-life implementations used by end-users. In this regard, the results currently shown are highly missleading and do not reflect typical use cases such as providing a high performance REST API. A large number of "frameworks" listed in the current round would probably even fail basic compliance tests, so they only exist to be shown within the framework results in the first place.

After all, people interested in improving the platform got the impression that the benchmarks are no longer a priority by TechEmpower, and rightly so as the project is now archived.

The Future

Besides TechEmpower FrameworkBenchmarks, there was not much competition - there are the Web Framework Benchmarks, but they are nowhere comparable to the level of detail shown by the FrameworkBenchmarks from TechEmpower.

A few months ago, a new project, HttpArena, was started to adress the pain points with TechEmpower FrameworkBenchmarks. They show a large variety of benchmarks, include new technologies such as HTTP/2 or websockets and have most of the major frameworks already covered. In contrast to FrameworkBenchmarks, they run benchmarks within the created PRs as well as when PRs are merged, giving developers feedback way faster. On top, they promise to keep the framework implementations realistic, so the results should be more credible than those of the FrameworkBenchmarks, making them a better tool for developers and architects deciding on technology.

Conclusion

TechEmpower FrameworkBenchmarks did an amazing job in making performance of web frameworks visible, and caused the overall performance of those frameworks to be greatly improved through their transparent results.

We will see, whether HttpArena or any other platform will continue this work, important for the web today and in the future.

Cover picture by Julian Hochgesang

Beyond ASP.NET: Lightweight Alternatives for C# Web Development

Andreas Nägeli — Mon, 22 Dec 2025 13:44:50 +0000

Many programming languages offer a wide variety of web servers and development frameworks for different target groups and project types. In the C# world, ASP.NET Core is generally considered the default choice. To broaden this perspective, this article provides an overview of all currently available web servers and development frameworks in the .NET ecosystem.

We will highlight active development projects that enable the hosting of web applications. Add-ons for ASP.NET Core (such as FastEndpoints) are not covered in this overview. Furthermore, no overall rating or ranking is given - the frameworks are described in alphabetical order. Nevertheless, there is an overview table for easy comparison of the projects presented here.

For clarity, we group the projects according to their activity into actively developed and no longer active projects. We will only examine the group of actively developed projects in detail.

Actively Developed Servers
- ASP.NET Core
- GenHTTP
- Sisk
- SimpleW
- Unhinged
- Watson
- Wired.IO
Summary
Legacy Servers
- EmbedIO
- NetCoreServer
- Nancy
Conclusion

Actively Developed Servers

This section covers all actively maintained and supported web server frameworks for .NET.

ASP.NET Core

Based on libuv, the library that significantly influenced Node.js, Microsoft modernized the aging ASP.NET with ASP.NET Core starting in 2014. Later, Kestrel, a .NET-based engine, was added as a modern foundation. Minimal APIs marked ASP.NET Core’s arrival in modern web development in 2021.

From both a functional and technical perspective, ASP.NET Core leaves little to be desired: it supports various API styles, common middleware such as compression and caching, and implements all common authentication mechanisms. ASP.NET Core is the only framework in this list that offers native support for HTTP/2 and HTTP/3. Native, and therefore first-class, support for features sometimes depends on Microsoft's positioning of its own solutions – for example, ASP.NET Core does not provide native support for server sent events (SSE) because Microsoft promotes its in-house solution, SignalR, instead. Since there are many dependencies to consider for such a widely used framework, new technologies are sometimes only supported after a delay, as can be seen in the example of Minimal APIs. In the end, almost all use cases can be implemented with ASP.NET Core, even if this often requires the use of community guides and tutorials.

Microsoft sees ASP.NET Core less as a framework that can simply be added to a .NET project and more as a standalone ecosystem. This prevents use cases such as embedding web servers in other applications such as MAUI or WPF apps. It also links the use of ASP.NET Core with other dependencies such as configuration handling, which steepens the learning curve.

In 2016, Microsoft focused on optimizing performance, resulting in ASP.NET Core being the fastest web server framework in TechEmpower Framework Benchmarks Round 13. While other frameworks have been further optimized, Microsoft has rested on its laurels, with the platform achieving 79% and Minimal APIs 64% of maximum performance in TechEmpower's latest JSON test. This means that ASP.NET Core is still very fast, but no longer the leader.

In essence, ASP.NET Core is the best choice for teams building production-grade web services that require a mature ecosystem, long-term support, and seamless integration with cloud and enterprise infrastructure.

GenHTTP

GenHTTP was originally developed as an application server in 2008 and underwent a fundamental modernization in 2019. Similar to most frameworks on this list, it focuses on providing a simple and fast developer experience.

GenHTTP can be used to host REST web services in various styles, web sockets, server-sent events, static files, and single-page applications. After ASP.NET Core, this framework offers the widest range of functions and also includes, for example, a module for reverse proxies, server-side cached content, or mTLS authentication.

GenHTTP aims to make project development as easy as possible for developers, while also offering extensive customization options. For example, the framework allows the addition of further serializers or compression algorithms that are permanently integrated into other frameworks. This results in greater complexity and a slightly steeper learning curve, but GenHTTP generally hides this well from its users. There is support for dependency injection, but built on top of the framework and not as native as in Wired.IO.

Similar to ASP.NET Core, GenHTTP allows the underlying engine to be exchanged – projects can also be hosted on Kestrel and, conversely, GenHTTP functionalities can be used in ASP.NET Core via adapters. This enables support for HTTP/2 and HTTP/3 via Kestrel, even if the internal engine itself only supports HTTP/1.1. In addition, there is an adapter for Wired.IO.

GenHTTP requires .NET 8 or higher. Support is provided via GitHub or a Discord community, but the website also offers commercial support options.

In TechEmpower's FrameworkBenchmarks, GenHTTP achieves 46%, one of the lower results on this list.

To summarize, GenHTTP is well suited for developers who want a flexible, embeddable web server framework with a broad feature set and full control over protocol- and infrastructure-level behavior.

Sisk

Sisk was created by Brazilian developer Adão with the first release appearing around 2022. It focuses on a declarative, dependency-free style and thus on a simpler developer experience than ASP.NET Core.

Sisk has a strong focus on enabling developers to quickly deploy web applications. The documentation is very clear and practical. Those who can live with the range of functions will quickly be able to set up lean and clear projects, including websockets and server sent events. Advanced features such as JWT authentication, caching directives, native dependency injection or SSL headers are missing. The server framework is actively being developed, with several commits per week. Support outside of the GitHub repository is not provided.

Sisk requires .NET version 8 or higher; .NET Standard and the .NET Framework are not supported. As with the other frameworks, only HTTP/1.1 is implemented.

There is an ongoing effort to provide a new engine implementation (cadente) with improved performance. For now, Sisk achieves around 5% in TechEmpower's FrameworkBenchmarks, 43% with the new engine, making it the slowest server on this list.

To sum up: Sisk is a good fit for small, focused web services where simplicity, minimal dependencies, and a declarative programming model are more important than a comprehensive feature set.

SimpleW

Started in 2023, SimpleW provides controller style REST APIs and also supports websockets and server sent events. It shows a lot of activity from the second half of 2025 on, making it an actively developed project.

Similar to GenHTTP and Sisk, SimpleW aims to enable developers to quickly develop web applications with minimal code. However, in direct comparison to these frameworks, it may provide a less clear API and documentation - which is likey due to its strong integration with the controller pattern. For the functionality being provided, SimpleW has a pretty small code base, alas advanced features such as Open API support or SSL headers are missing. In contrast to the other frameworks in this list, SimpleW has explicit support for telemetry.

As with GenHTTP and Sisk, SimpleW runs on .NET 8 onwards. Support outside of the GitHub repository is not provided, and only HTTP/1.1 is implemented.

Originally based on NetCoreServer, SimpleW is currently undergoing efforts to add its own engine, yielding impressive 71% in TechEmpower's FrameworkBenchmark, and therefore being faster than Minimal APIs on ASP.NET Core.

In essence, SimpleW is suitable for developers who prefer a controller-based programming model and want to build REST APIs quickly while retaining strong performance characteristics.

Unhinged

Unhinged is an experimental HTTP/1.1 webserver engine that, while being nowhere near production-ready, shows how .NET web servers could once again be among the fastest servers in the future. In TechEmpower's FrameworkBenchmark, Unhinged achieves 98.4%, allowing it to claim the third place overall. It will be interesting to see how this development will influence other web server frameworks, including ASP.NET Core itself.

In essence, Unhinged is primarily of interest to developers exploring the performance limits of HTTP servers in .NET and is not intended for building production web applications.

Watson

Watson has been around for several years, is part of the .NET Foundation and receives large commits approximately once a year.

While providing high-level features such as Open API integration, Watson positions itself more as a low level HTTP server library than a web service development framework, making it more comparable to Unhinged and Wired.IO. For example, Watson expects you to implement chunked transfer encoding of responses yourself, features such as JWT authentication, CORS or compression are not provided and expected to be implemented by the user. Watson uses http.sys to listen for incoming HTTP requests on Windows, providing a managed wrapper around this OS functionality. For Unix, there is Watson.Lite with no dependency on http.sys.

In contrast to other frameworks on this list, Watson supports a wide variety of target frameworks, from .NET 4.6.1 to netstandard2.1 and .NET 10, making it a possible choice for legacy projects or exotic use cases such as embedding into a Unity game. As with the other frameworks, Watson only supports HTTP/1.1. Support outside of the GitHub repository is not provided.

Watson is not included in TechEmpower's FrameworkBenchmark.

In summary, Watson is a reasonable choice for scenarios that require low-level access to HTTP primitives, broad framework compatibility, or integration into legacy or embedded applications.

Wired.IO

Started in December 2024, Wired.IO is one of the youngest frameworks on this list. It provides full control in handling HTTP requests at a low level, up to replacing the HTTP parser with a custom one. In contrast to the other frameworks on this list, Wired.IO provides first-class support for dependency injection and logging.

While Wired.IO allows low-level interactions such as directly writing a HTTP response, it provides several mechanisms to achieve routing, middlewares, JSON serialization, hosting static files and single page applications, making it a modern, production-ready framework for webservice development and a potential replacement for Watson. The documentation is clear and up to date. High level features such as Open API integration or CORS are not provided, but can be seamlessly added using an adapter that allows to plug in GenHTTP modules into a Wired.IO application.

Support is provided via GitHub and a Discord community. Wired.IO requires at least .NET 9, and provides a HTTP/1.1 implementation.

In TechEmpower's FrameworkBenchmark, Wired.IO achieves 76%, with a marginal difference to ASP.NET Core and way faster than Minimal APIs.

In conclusion, Wired.IO is well suited for advanced use cases that require fine-grained control over HTTP request handling while still benefiting from modern abstractions such as dependency injection and logging.

Summary

The following tables provide a high-level comparison of the frameworks discussed above. They are not intended as a ranking, but as a compact reference to highlight differences in scope, focus, and capabilities.

The criteria are intentionally broad and reflect typical requirements when building web services in .NET. Not all criteria are equally relevant for every framework, as some projects deliberately focus on low-level control or a narrow set of use cases rather than comprehensive feature coverage.

Criteria	ASP.NET	GenHTTP	Sisk	SimpleW
Webservices	🟢	🟢	🟢	🟢
Websockets	🟢	🟢	🟢	🟢
Server Sent Events	🔴	🟢	🟢	🟢
Static Files	🟢	🟢	🟢	🟢
SPA Support	🟢	🟢	🔴	🟢
Infrastructure Services	🟢	🟢	🟡	🟡
Dependency Injection	🟢	🟡	🔴	🔴
Documentation	🟢	🟢	🟢	🟡
Performance	🔵🔵🔵	🔵🔵	🔵	🔵🔵🔵🔵
Embeddable	🔴	🟢	🟢	🟢
AoT	🟡	🟡	🟢	🟡
HTTP Versions	`1.1`, `2`, `3`	`1.1` (`2`, `3`)	`1.1`	`1.1`
Frameworks	`>= dotnet6`	`>= dotnet8`	`>= dotnet8`	`>= dotnet8`
Last Release	`12/2025`	`12/2025`	`12/2025`	`11/2025`
GitHub Stars	`37.5k`	`242`	`198`	`81`

Criteria	Unhinged	Watson	Wired.IO
Webservices	🔴	🟢	🟢
Websockets	🔴	🔴	🟡
Server Sent Events	🔴	🔴	🔴
Static Files	🔴	🟡	🟢
SPA Support	🔴	🔴	🟢
Infrastructure Services	🔴	🔴	🟡
Dependency Injection	🔴	🔴	🟢
Documentation	🔴	🔴	🟢
Performance	🔵🔵🔵🔵🔵	`-`	🔵🔵🔵🔵
Embeddable	🟢	🟢	🟢
AoT	🟢	🟡	🟢
HTTP Versions	`1.1`	`1.1`	`1.1`
Frameworks	`>= dotnet9`	`any`	`>= dotnet9`
Last Release	`11/2025`	`12/2025`	`12/2025`
GitHub Stars	`3`	`457`	`35`

Legacy Servers

This section covers web server frameworks that are no longer actively developed. Legacy frameworks may still be viable for maintaining existing systems, but are generally not recommended for new projects due to limited development activity and ecosystem support.

EmbedIO

Embedio was one of the first lightweight web server frameworks for C#. Accordingly, the library has over 1600 stars on GitHub and is still used in legacy software or even for new, simple projects. The last major changes to the server date back to March 2020, and there are increasing difficulties with its use in current technologies. As the engine uses the deprecated HttpListener underneath, EmbedIO ranks 497th out of 520 framework in TechEmpower's FrameworkBenchmark, with only 0.5%.

NetCoreServer

NetCoreServer is a socket library that can also be used for serving HTTP requests. Since end of 2022, there has not been any meaningful activity. NetCoreServer achieves 53% in TechEmpower's FrameworkBenchmark.

Nancy

Nancy was one of the oldest frameworks, with its first release in 2010. It has officially been archived in 2021. In TechEmpower's FrameworkBenchmark, it achieved 14%.

Conclusion

The .NET ecosystem is often perceived through the lens of ASP.NET Core - and for good reason, given its maturity, breadth, and strong industry backing. However, as this overview shows, ASP.NET Core is only one of several viable approaches to building web-facing applications on .NET.

Beyond the mainstream, the ecosystem offers a diverse range of web servers and frameworks that address different priorities: from minimalism and embeddability to low-level control and experimental performance research. These alternatives may not aim to replace ASP.NET Core, but they expand the solution space and enable use cases that would otherwise be difficult or impractical to address.

Choosing the right framework is therefore less about finding a universal “best” option and more about understanding the trade-offs each project makes. By looking beyond the default choice, developers can better align their tools with the specific technical and organizational constraints of their projects - and fully leverage the versatility of the .NET platform.

Cover picture by Markus Winkler

An Incomplete Guide to Product Development

Andreas Nägeli — Wed, 17 Dec 2025 15:11:42 +0000

During the last years, I have seen a lot of companies struggling to setup their processes that allow them to efficiently develop software products and services they can sell to their customers. In this post, we will try to identify the main concerns and responsibilities that need to be adressed for successful product development and provide practical guides on how a possible process structure could look like.

But there is SAFe?

You might argue that we do not need to do this exercise as we already have SAFe (or LeSS, Spotify, OKRs ... you name it). Those frameworks work very well if you control the whole problem space and you can either develop internal products or have other companies developing them for you. But as a company having a dozen or even hundreds of customers, your customers will bring their own frameworks with them, expecting you to be integrated in their processes.

This creates a world where we have one or multiple product contexts as well as a potentially large number of customer contexts. However you will structure your processes and teams, the different, often conflicting needs the existence of those contexts implies will be there - if you address them or not.

So - What are the Needs?

To get a clearer picture of what we actually would like to solve, let us have a look at the different stakeholders in the overall process:

Stakeholder	Needs and Expectations
Customers	They want a solution to their problem, and they want it cheap and right now. They expect you to understand their internal wording and to align with their processes. They do not care whether you are developing a product or a customized solution for them - in fact, they would prefer a custom solution, as long as it is cheap.
Your Management	They want happy customers that are willing to pay a lot more than the costs you produce. They want an illusion of stability, so please provide a roadmap for the next ten years. Also they will sabotage this roadmap and the identity of your product on first opportunity to get a new customer.
Product Owner	The poor soul that has the responsibility to make customers, the management, the developers, and basically everyone happy. Either they accept that they cannot be perfect or they will quickly burn out.
The Team	They are mainly expected to give a high throughput of well-designed and high quality features. They are often more interested in their software product than the problems the product should solve. They will annoy everyone in the company about technical debt until their throughout falls below a certain threshold were customers become increasingly unhappy, causing management to dictate a whole rewrite that will block your company for the next three years.

Of course there are additional roles such as architects, project managers, product managers, business analysts, scrum masters, testers, devops and security specialists, UX designers and so on, but for our processual solution we will focus on the very core - be assured that they will find their place in our framework as well.

Separating Concerns

Now that we know the needs, we can start to shape our requirements for our product development process, already bringing us closer to a possible solution. Let us have a look at what we want and how we could address those issues.

The Customer Space

We want someone who understands what the customers wants, how they work and what is really important for them (meaning what they are willing to pay for, and if possible, how much). We are willing to make this experience as pleasant as possible for the customer, so they get the feeling they can come to us with new ideas and opportunities. If they are using SaFE, we are happy to send someone to day-long meetings.

There are a lot of different ways to organize this, usually a combination of responsible sales guys, key accounts and project managers. As you will not have enough resources to flatter all customers in this manner, you will need to categorize and set priorities. This organization is out of scope for this post.

For our process the main considerations are

Provide a space where you can organize your collaboration with the customer the best way possible
Do not expect nor force the customer to understand your company, processes or tooling, it just wastes their time
Do not allow this problem space to infiltrate your product spaces (for example the wording, but never something like release cycles), but ensure to take away the important requirements, time schedules and constraints (we will see how to do this later)

Practical examples would be:

You may want to have a separate Jira project for them, do not allow their input to directly create user stories in your product backlog
Do not force them to join your reviews (mind you, they do not care about your product)
If they prefer phone calls, get on the phone, if they want a status meeting, schedule one
Have your key accounts or project managers join your reviews and they will eagerly tell their customers in a language they understand

The Management Space

This space allows us to align the requirements of our customers with our product strategy and the roadmaps for each product. We want every larger topic to be visible in a unified list, allowing us to prioritize the value the company should provide next. If you have product managers, this is their home base - if you do not, hire some.

As with the customer space, our considerations for the management space are:

Provide a clear view on the next topics that are important for your organization
Specify use and cost for each topic (or even better: a business case)
Keep the topics based on use cases, so do not assign them directly to a product to avoid Conway's Law on this level. Use cases may involve multiple products at once. This also means that there can only be one management space.
Force decision makers to prioritize this list. Avoid priorities outside of this list as much as possible. Embrace conflict instead of avoiding it.
Avoid generating too much overhead to describe and estimate the topics. We do not need detailed concepts for things that will never be implemented (or in two years).
Add some kind of input process that ensures quality of the items as well as a clear communication strategy

This space is crucial for your process to work. Practical considerations:

Management will love this process until there is the first conflict where they cannot get everything they want as soon as they want. Defend this process at all costs and do not allow it to be replaced once a year with a new one that will suffer from the same underlying problem.
Separate the preparation of a topic from the decision. Product managers can prepare cases which then can be decided by management
Define iteration lengths and schedule regular meeting for prioritization. Anything from one to three months is fine.
Break down large topics and use cases into smaller ones, allowing to deprioritize or remove parts without meaningful value to your company. Do not allow topics larger than three months, or people will get impatient and the feeling of low performance arises. If needed, introduce a parent-child relation (such as "Epic" and "Feature" borrowed from SAFe).
Ensure everything that requires large chunks of resources of your development teams to be visible here. Both developers as well as your IT or DevOps platform will try to undermine this process for "technical tasks". Make those topics visible, which requires a clear value to be assigned to the topic. Otherwise management will lose trust in this process, and rightly so.
Small improvements should be able to by-pass this process. Think about defining some criteria (such as size) to determine when a topic needs to be added.
Keep the process simple. The more Jira fields you need to maintain, the less accepted this process will be.
If this process works for you, you can extend it with retros, time tracking, progress indicators etc.

The Product Space

Now that we have customer and management spaces, the life of your poor product owner got way easier. They will still contribute to and communicate with product and project managers, but their team simply can pull the next topics from the unified list, from which the product owner can also forge a product roadmap.

Besides this, there are not many considerations for this space, as we can apply regular Scrum here. We might question how we map solutions with products and technical services (Conway's Law once again), but this is out of the scope of this article.

Bringing Everything Together

To summarize the considerations above, we can sketch basic diagram to visualize the overall dependencies. This is not a process diagram but rather the way we separated our concerns.

The End

If you found this post useful or would like to add your own experiences, feel free to leave a comment below.

Cover picture by Luke Heibert

Quick HTTP File Server for DevOps with a Simple Script

Andreas Nägeli — Mon, 15 Dec 2025 11:17:22 +0000

As a DevOps engineer or system administrator, you might want to quickly spin up a HTTP server that allows to access files from other machines or to test functionality of programs and apps. Doing so would traditionally require you to install and configure a web server such as nginx or Apache, or to run a Docker image with volumes to make your target files accessible.

With .NET file-based apps, we can create script files that are easily capable of using any library hosted on nuget. In this article, we will demonstrate how to use the GenHTTP webserver to serve a local directory via HTTP.

Pre-Requisites

To run the script, you will need the .NET SDK (version 10 or higher) to be installed on your device (see this manual for Linux).

Creating the Script

In a local folder, create a new file named file-server.csx and paste the following content:

#!/usr/local/share/dotnet/dotnet run

#:package GenHTTP.Core@10.2.0
#:package GenHTTP.Modules.DirectoryBrowsing@10.2.0

using GenHTTP.Engine.Internal;

using GenHTTP.Modules.IO;
using GenHTTP.Modules.Practices;
using GenHTTP.Modules.DirectoryBrowsing;

var directory = @"./"; // adjust as needed

var tree = ResourceTree.FromDirectory(directory); 

var app = Listing.From(tree);

await Host.Create()
          .Handler(app)
          .Defaults()
          .RunAsync();

This script will instruct the server to host a simple HTML-based file browser application that serves the current directory. Adjust the path to your target directory as needed.

Running the Script

On Windows, the script can be started in a terminal window by running

dotnet run file-server.csx

On Linux, the shebang allows us to directly execute the file. After marking the file as executable via

chmod +x file-server.csx

we can directly start the server via

./file-server.csx

When started, the server will block until CTRL + C is pressed. You will now be able to list and download the target files via http://localhost:8080 in your browser or from other apps:

Cover picture by Fabien Barral

Mocking HTTP Services in C# with MockH

Andreas Nägeli — Tue, 04 Nov 2025 06:30:20 +0000

In acceptance or integration tests of your .NET application, you probably want to mock external HTTP services so you can focus on testing your implemented logic. For this purpose, you might want to mock your HttpClient or its HttpMessageHandler, which is only a partial solution as it does not run HTTP over the wire. Or you can spin off Docker containers that will return responses you configured beforehand using some API, which requires a lot of boilerplate code and cannot be parallelized well.

MockH is a small library that allows you to do both - run real HTTP requests and configure the responses in code, directly within your test. As it is designed to have no side effects, it can run in parallel and does not mess with ASP.NET Core in any way.

MockH is powered by GenHTTP, a lightweight and fully managed HTTP server framework written in .NET. This allows you to use high-level features such as JSON serialization to reduce boiler plate code required in your tests. Additionally, it can also be used in combination with any testing framework.

The following, minimal example will show you how to spin up a server instance and how to consume it in your code:

using MockH;

[TestMethod]
public async Task TestSomething() 
{
   // start a HTTP server listening on a random, free port
   // servicing the endpoints you define here
   await using var server = await MockServer.RunAsync
   (
       On.Get("/users/1").Return(new User(...)),
       On.Get("/users/2").Respond(ResponseStatus.NoContent)
   );

   // obtain the URL from the server instance to use
   // it in your code as needed
   var url = server.Url();

   // execute your tests here
}

MockH supports various kind of rules that can be passed to RunAsync() to generate your responses:

// return a specific status code
On.Get("/ifail").Respond(ResponseStatus.InternalServerError);

// redirect the client
On.Get().Redirect("https://github.com");

// execute logic and return some simple text value
On.Get().Run(() => "42");

// execute logic and return some JSON
private record MyClass(int IntValue, string StringValue);

On.Get().Run(() => new MyClass(42, "The answer"));

// execute logic asynchronously
On.Get().Run(async () => await ...);

// access query parameters (GET /increment?=1)
On.Get("/increment").Run((int i) => i + 1);

// access path parameters (GET /increment/1)
On.Get("/increment/:i").Run((int i) => i + 1);

// access request body
On.Post().Run((MyClass body) => body);

// access request body as stream
On.Post().Run((Stream body) => body.Length);

With MockH, you can write expressive, parallelizable, and fully isolated integration tests that use real HTTP without complex infrastructure.

Check out the MockH GitHub repository for more examples and advanced features.

Cover picture by Phil Harvey

Loading Certificates on .NET 9

Andreas Nägeli — Thu, 12 Dec 2024 09:15:49 +0000

I've seen a lot of traffic regarding the X509CertificateLoader on my website lately, so I guess people are struggling with fixing the deprecations on the constructor of X509Certificate2 (as I did, too).

So basically:

// from file
var cert = new X509Certificate2("./myfile.pfx");

// from byte array
var stream = new MemoryStream();
var cert = new X509Certificate2(stream.ToArray());

has become:

// from file
var cert = X509CertificateLoader.LoadCertificateFromFile("./myfile.pfx");

// from byte array
var stream = new MemoryStream();
var cert = X509CertificateLoader.LoadPkcs12(mem.ToArray(), null);

There are of course more overloads, but you will get the idea.

Cover picture by Marjan Blan

Server Sent Events in ASP.NET Core

Andreas Nägeli — Tue, 03 Dec 2024 06:26:44 +0000

Server Sent Events (SSE) is a HTML standard with good support by all major browsers that allows your server to push events to connected clients as they happen.

In contrast to websockets, the connection is unidirectional (so only the server can push events), making it easier to be implemented, soley relying on default HTTP mechanisms. On the client side, there is a simple, comprehensible API ready to be used.

ASP.NET Core does not offer an official implementation for Server Sent Events, so there are a lot of tutorials which try to add this functionality by directly writing to the response stream in the format the client expects. This approach works, but adds a lot of clutter to your application code and typically lacks some handy features provided by the standard, such as event types or event stream resumption.

There are other web server frameworks that have a first-class support for server sent events built in, but you probably do not want to change your server framework just for implementing an event source.

Gladly, one of those frameworks - namely GenHTTP - provides an adapter that allows us to plug in their implementation into an ASP.NET Core application. The following example will demonstrate this approach with a simple app that pushes randomly generated stock symbols to interested clients.

First, we create a new ASP.NET Core minimal API project from the terminal (or in Visual Studio):

dotnet new web -o StockEvents

In the generated project, we then add the nuget packages for the provider and the adapter.

dotnet add package GenHTTP.Modules.ServerSentEvents
dotnet add package GenHTTP.Adapters.AspNetCore

In our Program.cs we can then create an Event Source that will randomly generate our stock symbol updates and push them to connected clients. This source can be mapped to any path using the adapter functionality.

using GenHTTP.Adapters.AspNetCore;
using GenHTTP.Modules.ServerSentEvents;

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

var source = EventSource.Create()
                        .Generator(GenerateStock)
                        .Defaults();

app.Map("/stock", source);

app.UseDefaultFiles();
app.UseStaticFiles();

app.Run();

static async ValueTask GenerateStock(IEventConnection connection)
{
    var rand = new Random();

    var stockSymbols = new List<string> { "AAPL", "GOOGL", "MSFT" };

    await connection.CommentAsync("Sending stock data");

    while (connection.Connected)
    {
        var symbol = stockSymbols[rand.Next(0, 3)];

        await connection.DataAsync(rand.Next(100, 1000), symbol);

        await Task.Delay(1000);
    }

}

To test our implementation, we create a wwwroot sub directory in our project and create an index.html file there with the following content (adjust the port of the endpoint as needed):

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Stock Tracker</title>
    <style>
        body {
            font-family: Arial, sans-serif;
        }
        #stocks {
            display: flex;
            flex-direction: column;
            gap: 10px;
            margin-top: 20px;
        }
        .stock {
            padding: 10px;
            border: 1px solid #ddd;
            border-radius: 5px;
            background-color: #f9f9f9;
        }
    </style>
</head>
<body>
<h1>Stock Tracker</h1>
<div id="stocks"></div>

<script>
    // Establish a connection to the server using Server-Sent Events
    const eventSource = new EventSource('http://localhost:5011/stock/');

    // Function to display stock updates
    function updateStock(symbol, value) {
        let stockElement = document.getElementById(symbol);

        if (!stockElement) {
            // Create a new element for the stock symbol if it doesn't exist
            stockElement = document.createElement('div');
            stockElement.id = symbol;
            stockElement.className = 'stock';
            document.getElementById('stocks').appendChild(stockElement);
        }

        // Update stock value
        stockElement.innerHTML = `<strong>${symbol}:</strong> ${value}`;
    }

    // Event listener for general updates
    eventSource.onmessage = function(event) {
        updateStock(event.type, event.data);
    };

    // Event listeners for specific stock symbols
    const symbols = ['AAPL', 'GOOGL', 'MSFT']; // Example stocks
    symbols.forEach(symbol => {
        eventSource.addEventListener(symbol, event => {
            updateStock(symbol, event.data);
        });
    });

    // Error handling
    eventSource.onerror = function() {
        console.error('Connection to the server lost.');
    };
</script>
</body>
</html>

After the server has been started (dotnet run), you can open the endpoint announced by the launcher (e.g. http://localhost:5011) and will see the stock updates ticking in.

Please note that the endpoint you specified in the HTML file needs to match the URL you open in your browser, or otherwise CORS will prevent us from fetching events (so for example you cannot mix HTTP and HTTPS).

This was a brief tutorial to quickly spawn and consume an event source - you can check the documentation of the GenHTTP module to learn more about event types, event IDs, or error handling.

Cover by: Devon Janse van Rensburg

DEV Community: Andreas Nägeli

TechEmpower Framework Benchmarks are now Archived - What's next?

The Start

The Decline

The Future

Conclusion

Beyond ASP.NET: Lightweight Alternatives for C# Web Development

Table of Contents

Actively Developed Servers

ASP.NET Core

GenHTTP

Sisk

SimpleW

Unhinged

Watson

Wired.IO

Summary

Legacy Servers

EmbedIO

NetCoreServer

Nancy

Conclusion

An Incomplete Guide to Product Development

But there is SAFe?

So - What are the Needs?

Separating Concerns

The Customer Space

The Management Space

The Product Space

Bringing Everything Together

The End

Quick HTTP File Server for DevOps with a Simple Script

Pre-Requisites

Creating the Script

Running the Script

Mocking HTTP Services in C# with MockH

Loading Certificates on .NET 9

Server Sent Events in ASP.NET Core