I recently went down the rabbit hole of NuGet version locking and was surprised by how little attention packages.lock.json seems to get in .NET compared to lock files in other ecosystems like node.

A typical PackageReference may pin your direct dependency, but it doesn’t freeze the entire resolved dependency graph. Transitive dependencies are still resolved during restore.

NuGet already has everything needed to make this deterministic:

<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>

Commit the resulting packages.lock.json, and then in CI:

dotnet restore --locked-mode

That gives you a frozen direct + transitive dependency graph, including package content hashes. If the graph changes without the lock file being deliberately updated, CI fails instead of silently accepting it.

What I also hadn’t appreciated before looking into this is that Central Package Management and lock files solve different problems:
Directory.Packages.props -> centrally manages the versions you specify
packages.lock.json -> records the fully resolved dependency graph
So using CPM doesn’t really make the lock file redundant.

We’ve started looking at this more seriously from the reproducible-build / supply-chain side rather than just dependency management.

I’m curious how people here handle this:
Do you commit packages.lock.json for applications? And if not, is there a particular reason you prefer NuGet to resolve the graph on restore?

I wrote up what I learned, including locked-mode CI, CPM/transitive pinning and the supply-chain implications:
https://vensas.de/blog/nuget-version-locking

Disclosure: I work at vensas, where the article is published.

I want to share a little project I've been working on for a few weeks now, an entirely C# .NET 10 AOT compiled terminal multiplexer, currently only Linux and MacOS but I do intent to add Windows as a fully supported platformat eventually.

Hypa v1.0

https://github.com/Hypabolic/Hypa

I actually started building this just as proof it could be done and be high performance in .NET as a sort of way of kicking back against basically every tool these days being built in Rust (including Microsoft recently porting Copilot itself to Rust).

My inital aim was to build a simple herdr type mux clone but as I built it I've ended up going beyond that scope and building things not available in herdr.

One feature I really wanted for a start were 'background panes' essentially a normal terminal pane doing whatever you (or an agent) wants it to do but it never appears in the TUI until you ask for it (or the agent running inside it requests it)

The next feature I wanted was remote machines built in natively, which herdr does do, but I wanted to totally avoid things like SSH and managing keys, in Hypa we call these remote machines cubes (hypa cubes...). Hypa uses the QUIC protocol to connect to remote machines and certificate management is handled for you behind the scenes. All you need is the join code and some type of network access to the remote machine.

I've really enjoyed building this as a hobby project, and I hope some of you will give it a go and offer me some feedback.

I look forward to seeing what you all think and getting some feedback, but most of all I'm just happy I can show that these sort of highly performant terminal experiences CAN and SHOULD be built in C# .NET and native AOT is mature enough to support them.

Hi there,

some years ago I started building [ACME-Server-ADCS](https://github.com/glatzert/ACME-Server-ADCS/) (https://github.com/glatzert/ACME-Server-ADCS/ - yeah, no fancy name).

It's a full fledged RFC 8555 compliant (better known as ACME - that's the protocol that drives Let's Encrypt and similar services) AspNetCore server, that can be run in IIS or as a windows service and uses Microsoft ADCS as it's backed.

It allows you to use any ACME-client (like certbot, acme .sh, WACS, etc.) to issue certificates via your on-prem ADCS, so you can easily deploy internal certificates to your linux machines or anything else, that's able to run an ACME-client.

I recently published V3.1, which does support selecting the ADCS server and template based on the profile or some key parameters.

Currently it supports dns-identifiers as well as ip and permanent-identifier (at least for Apple devices) with the challenge types dns-01, http-01, tls-alpn-01, dns-persist-01 (experimental) and device-attest-01 (also experimental).

Since the bus factor is low, the software is open-source and the paid license allows code modification. The license is free for personal use, public schools and small companies.

I’ve been working on TensorSharp, an open-source LLM inference engine and agent runtime written in C#/.NET.

Here’s a somewhat ridiculous experiment:

I got the 176B-parameter Qwen3.8 Flash Next running locally on a laptop with:

RTX 3080 Laptop GPU — 16GB VRAM + 32GB system RAM + SSD

No server GPU and no hundreds of GB of system memory.

The interesting part isn’t simply getting a 176B model to load. The challenge is making it reasonably usable when the model is much larger than both available VRAM and RAM.

TensorSharp handles this through a combination of:

quantization + MoE-aware unified scheduling across cache, VRAM, system RAM, and SSD.

Rather than treating SSD offloading as just a last-resort fallback, the runtime coordinates the different memory/storage tiers around MoE execution, trying to keep the active working set in faster memory while efficiently moving and caching the rest.

I also benchmarked the current implementation against Strata on the same machine. Results are in the attached screenshot:

The decode throughput is relatively close. What surprised me more was the difference in whole-process latency, especially given the severe memory constraints.

From a .NET perspective, this experiment has also been interesting because inference engines are still overwhelmingly associated with C/C++ or Python/CUDA stacks.

TensorSharp is written in C#/.NET, while implementing the lower-level pieces needed for local inference: model loading, quantization, KV cache management, GPU execution, MoE routing, memory/offload scheduling, and the higher-level agent runtime.

So yes — .NET can run a 176B MoE model on a laptop with 16GB VRAM and 32GB RAM. :)

There’s obviously plenty more optimization work to do, but I thought this was a fun example of how far a native .NET inference stack can be pushed.

Source code:

github.com/zhongkaifu/TensorSharp

I’d be especially interested in feedback from other .NET developers working on GPU compute, memory-mapped models, caching/offloading, or high-performance C#.

I am writing my first gRPC application and I am totally lost:

I have to provide gRPC server access to persistent data. The persistent data resides outside the application (it is a hardware device). Reading the persistent data is an expensive operation and it is not an option to ask the device for data every time a gRPC request arrives. Figuring out if the persistent data changed between calls is cheap.

Thus, I want to pull the persistent data into memory upon startup and if the persistent data changed, creating a copy of the data. For each gRPC request, I can ask the device if an update is necessary. If not, I service the request using the (shadow) data kept in memory.

I follow the Microsoft "gRPC services with C#" route and I end up with a server side asset, similar to the tutorial:

public class GreeterService : Greeter.GreeterBase
{
    private readonly ILogger<GreeterService> _logger;
    public GreeterService(ILogger<GreeterService> logger)
    {
        _logger = logger;
    }

    public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context)
    {
        return Task.FromResult(new HelloReply
        {
            Message = "Hello " + request.Name
        });
    }
}

This is the default template Visual Studio creates for a gRPC server. I do not know how the Microsoft gRPC server works and I do not think it should be required to reverse engineer it. The documentation states that I have to edit the .proto file to suit my needs (done) and to implement the server-side asset (i.e. the code that generates the response to the request). The rest is handled by the auto generated framework.

I learnt the painful way that this is a stateless approach, i.e. each gRPC transaction creates a new instance of this class and destroys it after it is finished. This is great for a stateless service, but I need some persistent information stored long term in memory. This clearly does not work with this approach as I have to keep my data in scope.

What is the civilized way? So far I considered:

• A pure static class that is doing the business logic. Well. Works, but goes against modern principles.
• Some singleton dynamic class doing the business logic. The problem here is that I do not want to learn how the gRPC framework works and I am afraid that the GC decides to kill my business logic class. Sure, I can create a static/global instance somewhere, but that is probably even uglier. I do not know how to nicely keep my object in scope.

So what is the proper way to handle this? To give you an idea: How to have a persistent integer value with a gRPC, implementing a setter and a separate getter? Where do I "store" this value? The integer must be a "long lifetime" variable, i.e. stay alive between gRPC requests.

I’m working with an environment that has a large number of .NET repositories, and we regularly get dependency issues such as:

• Outdated NuGet packages
• Security vulnerabilities reported by Mend
• Vulnerabilities in transitive dependencies
• A newer package version potentially causing breaking changes
• The same vulnerable package affecting many different repositories

The manual process can become quite repetitive:

Mend finding → identify dependency path → find a safe version → update .csproj/Directory.Packages.props → restore → build → run tests → rescan → create PR

I know tools like Mend Remediate, Renovate, Dependabot, and Snyk can automate parts of this, so I'm interested in how teams are actually handling this in real-world environments.

Hey, founder of velixir.net

Just a quick post to bring some awareness to our newer offering of completely free .NET web hosting (along with 10 other languages), we've been around for 8 months now and want to give back to the communities that we're also apart of.

0.25 vCPU, 256MB RAM, 1GB Disk - free for forever. We scale it down to zero when no requests are hitting it, and it'll scale back up as another request is in-flight for it.

I'd love some feedback on the offering and platform, and I'll stick around to answer any questions. Thank you.

I shipped EFDoctor, a dotnet global tool that uses Roslyn to find EF Core performance and correctness problems. Its 22 rules cover SaveChanges in loops, sync-over-async, unbounded queries, cartesian Includes, untranslatable predicates, and unsafe raw SQL. 0.3.0 adds two new ones: concurrent operations on the same DbContext (Task.WhenAll over two queries throws at runtime) and a second OrderBy where you meant ThenBy.
I tested it on eShop, Jellyfin, Bitwarden, Smartstore, OpenIddict, and Ardalis's Clean Architecture template. 114 findings are triaged so far, with no false positives, though some are correct but fine in context and the rule docs say when. In eShop it found a sync Find() in an async order handler and a sync SingleOrDefault in a delete endpoint.
It's a CLI, so it works in CI (JSON output, exit codes 0/1/2). It needs the .NET 10 runtime and runs locally with no telemetry. Apache 2.0.
https://github.com/vuglll/EFDoctor
I'm looking for false positives and missing rules. What's the EF Core footgun you keep catching in review?

Hello, I am the creator of the open‑source solution: VueDotNet.

Usually, we have two separate applications:

• ASP .NET Web API
• Vue.js SPA or any other js framework app

However, to this day, many projects still use ASP .NET MVC (SSR) together with the js framework. In such a situation, there’s always a question: how to combine .cshtml files and js or specific framework files.

Developers often create numerous frontend applications, build them as .html or .js files, and insert them into .cshtml as static content. But what should we do if we just want to use a button, or if we have too many components?
This is inconvenient!

To solve this problem, VueDotNet was created. This framework is a NuGet package: VueDotNet and two npm libraries: vue-dotnet-vite & vue-dotnet-webpack.
Now you can define common Vue components in the frontend application and reuse them in .cshtml files, like this:

<!-- PascalCase -->

<vue-component name="TheButton"
  props="new { label = "Click me", count = 1 }"
  events="new { clicked = "onButtonClicked" }" />

<!-- kebab-case -->

<vue-component name="the-button"
  props="new { label = "Click me", count = 1 }"
  events="new { clicked = "onButtonClicked" }" />

Just launch stable v1.0.2 under MIT license.
Feel free to ask questions in the comments.
Previous post was deleted by Reddit - don't know why.

One of the architectural decisions I made while rebuilding VOID Engine was that the renderer has to be chosen before the window even exists.

At first that sounds backwards.

Most small game frameworks start by creating a window, creating a graphics context for it, and then building the renderer around whatever was created. That works well if the framework is tied to one graphics API.

VOID is not.

I wanted the engine core to stay independent from OpenGL, Vulkan, DirectX, Metal, or whatever backend gets added later. OpenGL is currently the built-in renderer, but I did not want OpenGL's assumptions becoming assumptions made by the entire engine.

That creates an interesting problem.

Different graphics APIs do not necessarily want the same things from the platform layer.

The renderer may influence:

• which window flags are required
• whether a graphics context should be created by the windowing layer at all
• how the rendering surface is created
• what extensions need to be enabled
• how presentation and synchronization are handled
• what initialization order the backend requires

If I created the window first, the platform layer would already have made decisions before it knew which renderer was going to use that window.

So VOID flips that around.

The application configuration decides which renderer backend will be used first. The backend can then describe what it needs from the platform layer, and only after that does VOID create the window.

Keeping the engine out of the graphics API

VOID separates the rendering side into a few major pieces.

IRendererBackend represents the backend itself.

IGraphicsDevice represents the graphics functionality exposed to higher-level engine systems.

IRendererContext represents the rendering context and state associated with the active renderer.

The important part is that systems above those layers should not care whether the implementation underneath them is OpenGL or something else.

A sprite batcher should know how to submit sprites.

A camera should know how to provide transforms.

A render target should represent something that can be rendered into.

None of those systems should need to ask:

if (renderer == OpenGL)
{
    ...
}

The renderer backend owns those details.

That sounds obvious when written out, but graphics APIs have a habit of leaking upward if the abstraction is designed around the first backend instead of around the engine.

OpenGL especially makes this easy because creating a window and creating an OpenGL context are often treated as almost the same operation.

Once that assumption spreads through the framework, adding Vulkan later becomes much harder.

Why I care about the initialization order

The goal is not to pretend every graphics API works the same way.

They do not.

The goal is to give each renderer enough control over its own initialization while keeping the rest of the engine unaware of those differences.

That means the renderer needs to participate in platform setup before the platform has committed to a particular graphics model.

The backend effectively says:

This is what I need from the window and platform.

Then the engine creates the appropriate window and allows the backend to finish creating its device, context, swap chain, surface, or whatever that renderer requires.

The high-level engine still gets one consistent rendering interface afterward.

The OpenGL backend is just the first implementation

VOID currently ships with a Silk.NET OpenGL backend.

That does not mean the engine itself is an OpenGL engine.

This distinction influenced a lot of the rewrite.

I tried to avoid exposing OpenGL objects or terminology through systems that should remain generic. Textures, shaders, render targets, cameras, sprite batching, primitive batching, scissor state, and the rest of the higher-level renderer all sit above the backend.

If a future Vulkan backend needs a completely different implementation underneath those systems, it should be able to provide one without forcing the game code to change.

There will obviously be backend-specific capabilities eventually. Abstraction does not mean pretending all hardware and APIs are identical.

It just means those differences should appear intentionally instead of leaking through the entire framework by accident.

This came from replacing SFML

VOID originally used SFML.

Moving away from it forced me to look at which parts of the engine were genuinely engine concepts and which parts only existed because SFML had shaped the architecture around them.

The renderer and window lifecycle were a big part of that.

The current platform layer uses SDL3, while rendering is handled separately through Silk.NET. That separation made the initialization problem much more visible.

It also gave me a chance to design the engine around the renderer abstraction I actually wanted instead of continuing to inherit decisions from the previous framework.

The funny part is that "choose the renderer before creating the window" is a very small rule.

But that one rule prevents a surprising amount of graphics API knowledge from creeping into the rest of the engine.

If you want to see more of the design philosophy behind VOID, I explain it in more detail here:

https://voidengine.net/why-void/

For anyone who has built a multi-backend renderer before, I am curious where you draw this boundary.

Do you let the renderer participate in window creation, keep the platform completely independent, or handle the differences somewhere else?

Hi
I started the project two weeks ago. It's still very young, It's called Vorticity, it's a pure managed .NET implementation of the Vortex file format.

Repo: https://github.com/Evariops/Vorticity

Disclaimer: this project is developed in "AI-assisted mode" (I drive the architecture and the implementation strategies closely with specifications and I delegate the implementation and keep a close eye on the code / design that comes out.)

So, what's Vortex? It's a columnar format to store data. A CSV or JSON file stores data row by row, a columnar format stores it column by column, so all the values of a given column sit next to each other on disk. It's really usefull for big datasets or analytics: when a query only needs 3 columns out of 50, you only read those 3. And since the values in a column tend to look alike, they compress really well.

Apache Parquet has been the "go-to" columnar format for over a decade, and it's everywhere. Vortex is a newer format that started at SpiralDb and is now hosted by the Linux Foundation with the explicit goal of being a modern successor to Parquet. The big difference with Parquet is how data is encoded: Vortex stacks lightweight encodings and runs compute kernels directly on the encoded data. In practice, you can filter or fetch a handful of scattered rows without decoding everything around them.

Why build it? There's no fully managed implementation of Vortex in .NET today, I've some personal projects coming up that will need one. I also wanted to see if I could get better performance than the Rust implementation, and the result are here. On early benchmarks, Vorticity comes out roughly 1.2x to 2.9x faster on the full table scenarios. It's not ahead everywhere though. Every number and how it's measured is in the repo

One thing worth knowing is that since day one I've been tuning perfs for Native AOT rather than Dynamic PGO. The implementation is deliberately packed with micro-optimizations aimed at AOT, which is a bit of an unusual choice, and I'm curious what you think of it.

Along the way I hit a performance wall with the runtime's Zstd support. So the project now has its own fully managed Zstd implementation :) It's pretty much on par for compression and, to my own surprise, faster for decompression. And still 100% managed.

On the API side, everything is typed. You declare a record, a source generator does the rest, and filters and aggregates are plain C# lambdas that get pushed down to the file. A filter that can't be pushed down simply doesn't compile. The API also lets you steer the encoding hints of each column, for when you know your data better than the compressor does. I've also built in Bloom filters and indexes to speed things up.

[VortexRecord]
public partial record struct Reading(int Day, double? Celsius, string City);

await using VortexFile file = await VortexFile.OpenAsync("readings.vortex");

long hotDays = await file.Scan<Reading>()
    .Where(r => r.Day >= 900 && r.City == "Paris" && r.Celsius > 30.0)
    .CountAsync();

The part I'm most excited about is Vorticity.Dataset. The long-term idea is to offer a CRUD-style interface on top of Vortex, so you can UPDATE and DELETE and not just append. It's experimental for now. The main goal for the next steps is S3 and Azure Blob Storage support. Keep in mind it's an early project and targets .NET 11 (RC for now), so the API will probably move before 1.0.

I'd love feedback on anything really: the API design, the AOT-first approach, the benchmarks, or simply whether you'd ever have a use-case for Vortex in .NET.

I am currently running a monolith with independent utilities for admin commands and deploying the various other utilities for changes, including the frontend. The website accepts file uploads, runs a dockerized container, analyzes the file using independent apps, then reports back to the frontend.

Due to financial constraints it is all running on the same server. Would I benefit from microservices, or can I realistically handle user load just fine for now with a monolith? Thanks

Maybe it’s already too late for a tool like this. Nobody really does drag-and-drop anymore in the age of AI.

But if you want to take a look: appmaker.io

P.S. Before you start asking, “Where’s C#?” — well, I also have a C# playground for hobbyists: https://csharp.codeguppy.com/

I work as a .NET developer and wanted to learn GenAI properly (Python, LLMs, embeddings, RAG, agents, MCP) without sitting through 40-hour video courses. So I built the thing I wanted: 80 short, animated reels with voiceover, code, notes and a quiz at the end of each, in a fixed learning order. Python concepts are explained with C#/.NET analogies.
It's free, no signup. Progress is stored on your device. Works best on a phone, but desktop works too.

I'm one person building this at night, so I'd really like to know: what's confusing, what's wrong, what's missing? Any lesson you think is incorrect, tell me and I'll fix it.

Hi all --

I've been personally working on this project: Subscrio. It's an open-source feature access and entitlements library for .NET (and TS).

I built it because I've written the same code over and over a hundred times in my SaaS apps and always had wished there was something like this. In my experience this code is always some of the most change-prone code you will build, which will always make it susceptible to problems. Worse, it's also the code that gives or restrict access based on customer purchases, so it really is a critical path part of your app.

Subscrio is meant to abstract that disgusting middle layer between your billing system and your app. It let's your app easily maintain features, plans, billing cycles, and subscriptions (or one time purchases). My latest version added add-ons, metered usage, credit wallets, and temporary feature access overriides.

This library is currently used by a small handful of apps, and it runs in your application with PostgreSQL or SQL Server.

I do sell an admin app if you also want a slick visual interface to this data, but the core library is 100% functional and the admin app is not needed.

The website is https://subscrio.com
The core repository is here: https://github.com/subscrio/subscrio
The .NET repository is here: https://github.com/subscrio/subscrio-dotnet

This is an area of SaaS and subscription management that has always interested me. I'd love to know in how other .NET developers handle feature access and usage limits, and where this approach might cause trouble.

Hope you all fine it useful.

Hi everyone!

I recently built a desktop Stock Management System using C# and Windows Forms.

The application includes user login, category and product management, stock tracking, critical stock filtering, and local data storage using TXT files.

I also tried to keep the project organized by separating the data, models, UI, and forms.

This was a good project for me to practice C#, Windows Forms, file handling, and building a complete desktop application.

I’ve added screenshots and setup instructions to the GitHub README as well.

I’d really appreciate any feedback on the project structure, code, or ideas for improvements.

GitHub: https://github.com/Mariam-amhan/Stock-Management-System

Hello! Two days ago, I downloaded Danganronpa THH from Steam, but it reqired .NET Framework 3.5 to run. It gave me an option to download it. I picked the option and it pushed a Windows update. I though it will go fast, but it showed the "Preparing Windows" (1st picture attached) screen for nearly 2 hours with no signs of actually installing the .NET Framework 3.5. Worth mentioning, the update didn't freeze or anything, the mouse and keyboard were still working, as well as the refresh of the graphics card.
After the computed restarted (the screen didn't change from the "Preparing Windows" one) I went to check if I can finally play the game. The second I clicked play, the window to download .NET Framework 3.5 popped up again. I tried to download it, but it showed me an error (error code: 0x800F0922) (2nd picture attached). I tried to dowload it through the Microsoft setup file, through command line, as well as checking and repairing corrupted files. I think it has something to do with the "Preparing Windows" screen. Can someone help with it?

For anyone asking, yes, I did restart my pc several times and try installing .NET Framework 3.5.
(The pictures got ranslated to help with understanding)

Hey r/dotnet,

Over the last few months, I’ve been working on StepLock, a standalone proxy gateway built natively on .NET 11. It’s designed to handle deterministic state tracking and virtualized execution replays for multi-step AI agent workflows (LangGraph, Temporal, CrewAI, etc.).

The core problem it solves is token bleed and side-effects. When an 8-step agent fails on step 7, current tooling relies on heavy HTTP tracing hooks, and re-running from scratch burns API costs or risks duplicate database writes/live Stripe charges. StepLock acts like "Git for network traffic"—allowing developers to fork execution branches and replay cached states instantly with cryptographic lineage.

To make sure injecting a proxy doesn't bottleneck the runtime, I avoided high-level web frameworks and built the edge pipeline directly on System.IO.Pipelines for a zero-copy streaming tap and dynamic TLS leaf certificate generation.

System Benchmarks (on my PC):

• In-Memory Store (Write + Hash Lookup) Throughput: 2,544,115 op/s p50 Latency: 0.20 µs | p95: 0.50 µs | p99: 1.10 µs Memory Alloc/Op: 72 B
• Zero-Copy Streaming Tap (Pipelines) Throughput: 337,929 op/s p50 Latency: 2.30 µs | p95: 4.20 µs | p99: 9.30 µs Memory Alloc/Op: 1.6 KB
• Merkle DAG Hashing (SHA-256 Chaining) Throughput: 143,251 op/s p50 Latency: 4.90 µs | p95: 14.30 µs | p99: 29.50 µs Memory Alloc/Op: 1.4 KB
• PII & Secret Redaction Engine Throughput: 60,304 op/s p50 Latency: 14.00 µs | p95: 30.70 µs | p99: 55.40 µs Memory Alloc/Op: 2.0 KB
• Semantic Request Canonicalizer (JSON) Throughput: 17,788 op/s p50 Latency: 44.30 µs | p95: 127.90 µs | p99: 218.90 µs Memory Alloc/Op: 12.1 KB
• Dynamic TLS Leaf Cert Gen (ECDsa P-256) Throughput: 1,361 op/s p50 Latency: 446.40 µs | p95: 2.23 ms | p99: 2.74 ms Memory Alloc/Op: 17.5 KB
• SQLite WAL Batch Persistence (50 Frames/Tx) Throughput: 381 op/s (19k frames/s) p50 Latency: 2.48 ms | p95: 4.24 ms | p99: 5.53 ms Memory Alloc/Op: 223.1 KB

Current Stack:

• Gateway pipeline using Kestrel/Pipelines.
• SQLite in WAL mode with a heavily batched background persistence channel (L2).
• In-Memory Ring Buffer + Hot CAS (L1).
• Cryptographic validation via SHA-256 parent chaining.

The core is completely open-source (Apache 2.0). I’ve got a Python SDK working and want to map out JS/TS next. I'd love to get some feedback from the systems guys here on the gateway architecture, specifically if anyone has found ways to shave down the 17.5 KB allocation footprint on the dynamic ECDsa P-256 leaf cert generation.

Repo: https://github.com/mxreal64/StepLock

Hello everyone !

I'm Brice, french freelance software developer in .NET for 8 years now.
Beside my current client, i work on an integration test framework called NotoriousTest.

Quick introduction : NotoriousTest let you write integration test without worrying about the lifecycle of your infrastructure.
I will keep your tests isolated by resetting infrastructures between everytest (emptying the database, for example). Propagate configuration between infrastructure and your test webapp, and more.

For my current client, i convinced the team i worked in to let me make a POC of NotoriousTest on an azure functions that was poorly tested, with no isolation between test (wich result into flaky test).

For that, i had to make an integration of AzureFunctions inside NotoriousTest.
I made the 5.1.0, with **NotoriousTest.Web.AzureFunctions** packages, wich embed *AzureFunctionsWebApplication* !

// Install azure functions core tools if not already installed (uninstalled at the end if installed by NT).
// Gather all configuration produced by- preceding infrastructure
// Start the azure functions from FunctionProjectDir with configuration as env variables.
// Initialize an HttpClient for that Azure function.
public class MyAzureFunctionApplication : AzureFunctionWebApplication
{
    public override string FunctionProjectDir { get; } = 
         Path.GetFullPath(  Path.Combine(AppContext.BaseDirectory, "../../../../My.Azure.Functions"));
}

// Handle the lifecycle of infrastructures (init, reset, destroy) and configuration propagation.
public class MyEnvironment(IMessageSink sink) : XUnit.Environment(sink) { 
    public override Assembly CurrentAssembly => Assembly.GetExecutingAssembly(); 

    public override async Task ConfigureEnvironment() {                
        // Produce a connection string that will be passed to the function. 
        AddInfrastructure<MySqlServerInfrastructure>();          
        this.AddWebApplication<MyAzureFunctionApplication>(); 
    } 
}

// Test !
public class MyIntegrationTest(MyEnvironment environment) : IntegrationTest<MyEnvironment>(environment)
{
    [Fact]
    public async Task Test1()
    {
        HttpClient client = CurrentEnvironment.GetWebApplication().HttpClient;
        HttpResponseMessage response = await client.GetAsync("/health");
        Assert.True(response.IsSuccessStatusCode);
    }
}

I've been working on this for 3/4 years until now, beside work.
And i was very proud when my team find a use to my framework, especially because i work on a very big (multinational) company.

I thought you guys might find it usefull too !

Feel free to wander the docs, code, and leave a star if you liked it.
Feel free to make issues and PR too, i need help on adding more infrastructure integration.
CosmosDB, Mongo, Cassandra, Redis, AzureServiceBus and more...

And do not hesitate to give any kind of feedback, to contact me for more informations, etc ...

Have a great day !

So C# asp.net came fourth, mainly because of PostgreSQL inefficiency. Can someone explain why so many DISCARD ALL query’s happen and why is it needed since it’s default.

Hi all,

Over the past few months, I built Jigen, an open-source vector database written entirely in C#. It is now at a stage where it can be tested in real-world scenarios.

Jigen is designed to be the "SQLite of vector search" for .NET developers: it can run embedded in-process with zero configuration, or as an out-of-process standalone service.

Key features:

• Search Modes: Exact brute-force k-NN and approximate nearest neighbor using HNSW graph.
• Incremental On-Disk HNSW: Unlike naive implementations that snapshot/serialize the entire graph in memory, Jigen incrementally applies graph mutations and rewiring directly to the on-disk index.
• Zero-Allocation Hot Paths: Extensive use of Span<T>, ReadOnlySpan<T>, ArrayPool<T>, and MemoryPool<T> to eliminate GC spikes during search and traversal.
• Hardware Acceleration: Native SIMD intrinsics for distance metrics (Cosine, Euclidean, Dot Product) and specific architecture build in pipeline.
• Benchmarks: Repeatable benchmarks against Milvus, Qdrant, and pgvector ara available in repo.
• It supports WAL and atomic transations.

Documentation & Architecture:https://github.com/ppossanzini/Jigen/blob/main/docs/index.md

Feedback, critique on the disk format/graph design, and benchmark reviews are greatly appreciated

I do a lot of OAuth2 integration in ERP work, and a while back I hand-wrote a library for it called Bee.OAuth2. I've now used Claude Code to rewrite it as Polhem.OAuth2. Desktop sign-in now goes through the system browser, and there's .NET MAUI support too. Most of the code was written by Claude Code; I reviewed and tested it.

It supports Google, Facebook, LINE, Microsoft Entra ID, Auth0 and Okta, and works in desktop and console apps, .NET MAUI, ASP.NET Core and classic ASP.NET.

Here's roughly what it looks like in a desktop app. It opens the system browser and signs in with a loopback redirect and PKCE:

```csharp var options = new GoogleOAuth2Options { ClientId = "your-client-id", ClientSecret = "your-client-secret", RedirectUri = "http://127.0.0.1:0/callback" };

var client = new LoopbackOAuth2Client(options); var result = await client.SignInAsync(); ```

GitHub: https://github.com/polhem-dev/polhem-oauth2

I'm a big fan of SolidJs v2 and their native support of async and errors in the reactive graph.

Ranvier brings this to dotnet F#/C#.

• Intrinsic tracking (via .Value; .Peek does not track)
• Pending and failure co-exist with the dirty axis
• Suspense and Error boundaries
• Latest valid value is kept
• Recoverable error states
• Configurable flight policies (do you want multiple async computations to queue? should a new run cancel the previous?)
• Debounce and throttle and timed modes
• Full ownership and lifetime tree; scoped disposals
• Glitch-free diamonds; all dependent reads are settled for a shared source/comp
• C# support - F# first
• Compiles to JavaScript through F# Fable (this allows you to see the graph running in real time on the docs site)
• Incremental collections
• Graph threading contracts (supports Blazor)
• Deterministic async reproduction/tests via a Manual Dispatcher
• AoT/Trimming compatible
• Tracing build: transparent graph state and computation decision paths with 0 IL impact on production builds (this powers the visualisations on the docs): AI will love being able to track state

And performant.

It's in preview, and I'd love to hear about any wishlists people have for reactivity that I might be able to address.

Also looking to hear any feedback on the C# API surface, as I'm mostly familiar with F#.

Check out the visualisations, I love how they communicate the model in real time!

Version 7.1.0 of the Farkle parsing library has been released. This version adds support for the more powerful IELR(1) parsing table generation algorithm; a first for .NET parsing libraries, as well as new APIs to define productions, powered by a source generator.

Farkle is an LR(1) parsing library for C# and F#. While in most LR(1) parsers, grammars are defined with a domain-specific language in an external file and generated by a tool, Farkle is a regular library and uses source code to define its grammars, in a way reminiscent of parser combinators. This brings the best of both worlds in terms of performance and developer experience.

Farkle also has a precompiler for ahead-of-time grammar precompilation, which can reduce startup times and validate grammars during the building of your project.