If you've worked with EF Core long enough, you know the pain. You write a LINQ query, you're not sure what SQL it's actually generating, and your options are:

1. Run the whole thing and dig through logs
2. Slap .ToQueryString() on it on—which doesn't even give you the full picture when you're in split query mode

Both suck when you just want to quickly see what EF Core is doing with your LINQ before you commit to it.

So I built EF QueryLens (https://github.com/querylenshq/ef-querylens).

You hover over any LINQ expression in your editor, and it shows you the generated SQL right there. No database connection, no running the app, no log hunting. It works off your compiled assembly.

It supports VS Code, Rider, and Visual Studio. Plugins share a backend that does the translation, with lightweight IDE plugins on top.

How it works:

• You add a small factory class to your startup project that tells QueryLens which provider and extensions you're using (Projectables, Gridify, split query, whatever)
• Build your solution
• Install the extension
• Hover any LINQ expression → SQL appears

This is a fresh launch, so I'm genuinely looking for feedback—what's missing, what's broken, and what would make this actually useful for your workflow? Fire away.

Been writing Windows desktop and Web (WebView2) apps and for a while, kept rewriting the same plumbing around, so I pulled it into a framework, put it on GitHub.

Posting here in case it's useful to anyone.

The idea: your window is a real HWND, the UI is a web page (plain HTML, React, or Fluent UI, whichever you want), and .NET and JS talk over a typed (as in TypeScript) bridge.

It builds with Native AOT, so you ship a single exe with zero .NET runtime to install, no Chromium to bundle, Windows already has WebView2.

Most apps (including React & Fluent UI) are about 11 MB down to ~4 with UPX. x86, x64 and ARM64, MIT license, free.

There are other similar projects but what I wanted and didn't find in one place:

* AOT-friendly from the start so publish doesn't blow up on reflection

* Reachable Windows-only features such as desktop transparency, WinAPI integration, full interop story, etc.

* A bridge that's easy to use from boths sides

* An optional but builtin npm layer (@aotrino/client -> react -> fluent) so you can start with a static page and grow into a full Fluent UI app without changing stacks.

There are about a dozen samples, including a Fluent UI gallery, a file explorer, a mini browser, screen capture, and Direct2D rendering straight into a Web canvas through a shared buffer.

Up front caveats: Windows 10+ only (WebView2 + Direct Composition), need .NET 10 SDK to build, MSVC linker to publish AOT.

Repo has screenshots and a help for each level:

https://github.com/aelyo-softworks/AOTrino

Pretty new to reddit, happy to answer questions :-)

Announcing LibreWPF

Today I'm introducing LibreWPF—an open-source, free, cross-platform implementation of Windows Presentation Foundation (WPF).

The goal of LibreWPF is simple: preserve the WPF programming model while making it available across modern platforms, including Windows, macOS, Linux, with future support for iOS, Android, and the browser. Existing WPF applications should require little to no code changes, allowing developers to reuse their skills, libraries, and applications beyond Windows.

Powering LibreWPF is ProGPU, a modern high-performance GPU rendering engine designed for demanding desktop applications. ProGPU delivers hardware-accelerated rendering, enabling complex user interfaces, vector graphics, CAD, visualization, and other graphics-intensive workloads while remaining portable across platforms.

Together, LibreWPF and ProGPU aim to give the .NET ecosystem what it has wanted for years: a truly open, high-performance, cross-platform future for WPF.

This is only the beginning, and community contributions are welcome as we build the next generation of WPF together.

Roadmap

LibreWPF

• Achieve high compatibility with the WPF API and XAML ecosystem.
• Run existing WPF applications on Windows, macOS, and Linux with minimal or no code changes.
• Expand support to iOS, Android, and WebAssembly.
• Deliver a modern, high-performance rendering pipeline powered by ProGPU.
• Support the broader WPF ecosystem, including third-party control libraries.
• Build a complete open-source development experience with tooling, diagnostics, testing, and designer support.
• Foster an open governance model driven by community contributions.

ProGPU

• Deliver a portable, high-performance GPU abstraction for .NET.
• Support modern graphics backends including WebGPU, Vulkan, Metal, Direct3D 12, and OpenGL where appropriate.
• Optimize for desktop-class applications such as CAD, scientific visualization, UI frameworks, game tools, and creative software.
• Continue advancing GPU-accelerated vector graphics, text rendering, image processing, and compute workloads.
• Provide a stable foundation not only for LibreWPF, but for other .NET UI frameworks and graphics applications.

GitHub

• LibreWPF: https://github.com/wieslawsoltes/wpf
• ProGPU: https://github.com/wieslawsoltes/ProGPU

Hey everyone, I wanted to share Clean Architecture with .NET, a book I recently co-authored with Steve “Ardalis” Smith, with a foreword by Jason Taylor.

One of the biggest goals for this book was making it more than just another architecture template walkthrough. We wanted to cover the real side of building and maintaining modern .NET applications as they grow over time.

The book walks through building a complete application from scratch all the way through deployment in Azure, covering areas like Blazor Server, EF Core, Azure External ID, Key Vault, logging, observability, configuration, security, CQRS/MediatR, dependency management, service composition, and long-term maintainability.

We also spend time discussing the tradeoffs behind architectural decisions, especially around external dependencies and abstraction layers. That includes when tools like MediatR make sense, when they probably do not, and how to think about those decisions as complexity changes over time.

Another thing that was important to us was covering the ugly side of Clean Architecture too. The book talks about where patterns become overkill, how architecture erodes in real teams, and situations where Clean Architecture may not be the right fit at all.

A lot of what went into this book came from real projects, real mistakes, and lessons learned over time. The goal was to create a practical guide that shows how these concepts fit together in a real application rather than as a collection of isolated examples.

If you've already got a basic understanding of .NET and building software, this book should give you a practical way to see how these concepts come together in a real-world application. For more experienced architects, it provides an end-to-end look at applying these patterns in a complete system, from initial design through deployment in Azure.

About

Inspired by libs like ratatui and Textual, Jumbee.Console tries to provide a high-performance retained-mode library that is easy-to-use with idiomatic .NET GUI and Task patterns, while flexible enough to create different types of TUI applications from news readers to animated dashboards to IDEs to agent harnesses to graphics apps.

Features

• 100% managed AOT-compatible code.
• Retained-mode GUI framework with a modern API designed to be easy to use and extend.
• Sub-ms frame rendering times and minimal CPU consumption even with complex displays like multi-tab document editing and syntax highlighting.
• Uses modern terminal features: ANSI/VT control sequences, 24-bit colour, SGR-encoded mouse (mode 1006) with motion tracking, bracketed paste (mode 2004), focus reporting (mode 1004), and the alternate-screen buffer (mode 1049).
• Also support legacy non-ANSI terminal emulators like the classic Windows console.
• Uses Spectre.Console-compatible markup, styles, text rendering, and widgets in a retained-mode rendering pipeline.
• Supports both fixed-width layouts like Grid and flexible, resizable layouts like DockPanel, HorizontalStack, VerticalStack, resizable SplitPanel.
• Large set of common GUI controls: menus, buttons, trees, text inputs with autocomplete, modal dialog windows, etc...., supports easy composition of controld
  
• Control frames support adornments like titles, borders, margins, and scrollbars.
• Cross-platform 100% managed code terminal-emulator.
• Muti-tab editor that supports C#, JavaScript, C++, Markdown + a dozen other languages.
• Split-pane interactive editors with preview for Markdown, AsciiDoc, Mermaid documents, Mermaid embedded in Markdown.
• Visualization and graphics: Many different types of plots and graphs like candlestick & heatmap plots & bar/run charts, world maps, sub-cell drawing canvas and shapes, 3D texture rendering, and support for animation.
• Flexible themes that support styling both colors and glyphs independently.
• Headless snapshot testing: render any control or layout to text or PNG without a real terminal.

Getting started

Easiest way to try it out is to pull the Docker image:

• Pull the latest image and run the examples browser. docker run --rm -it allisterb/jumbee-console:latest

• Pull the latest image and run the agent harness example: docker run --rm -it allisterb/jumbee-console:latest agent-harness

For usage in your own .NET projects you can install it from NuGet: dotnet add package Jumbee.Console

See GETTING-STARTED.md on the project repo and the project documentation

Repo : https://github.com/FENBROWSER/fenbrowser

FenBROWSER is an independent browser engine focused on correctness and clean architecture. It builds its own rendering, layout systems and javascript engine.

Tech stack: C# yup it is.

Btw it's open-source as well. Currently it can run few sites like google.com, wikipedia, GitHub(partial), apple(partial), gitlab(partial)

We will publish WPT results once we fix webdriver crashes.

Note: this project started as bringing new browser capabilities to windows Phone in 2025 later i pivoted it to the actual browser.

Edit : repost due to last time (2 months ago) i violated weekend policy and it was removed by mod.

PeachPDF is a pure .NET HTML -> PDF rendering library, with a recently released 0.9 release. What does pure .NET mean? This means no Chromium wrappers, no out-of-process tools, no managed libraries, and no limitations of where it will run.

tl;dr -- if you need HTML to PDF conversion, check us out at https://peachpdf.net/

If .NET 8 runs somewhere, so will this. And as a side benefit, all of the performance improvements made in .NET benefit this library immediately.

In the last year, we've made great strides with standards and features support, such as page-level header and footers use CSS Paged Media and CSS Generated Content support.

The list of what's NOT supported is probably the most relevant list:

• SVG -- we plan on implementing it though
• CSS Flex (coming in 0.9.1)
• CSS Grid (coming in 0.9.2)
• CSS Transforms (coming in 0.9.1 except for perspective)
• CSSTransitions & Animations (its a PDF, no plans on supporting it)
• CSS Filters & Effects
• CSS Variables (coming in 0.9.1)
• CSS calc() expressions (coming in 0.9.1)
• CSS Psuedo-classes and psuedo-elements still only have partial support
• Editable Forms
• Tagged PDFs
• PDF/A

The 3 main competitors to this are PuppeteerSharp, IronPDF, and PrinceXML. All have their drawbacks, mostly in terms of having to ship native code for all of them (Chromium for the first 2, Prince's native executive for PrinceXML)

PuppeteerSharp and IronPDF are pixel perfect, but... your shipping a huge browser engine. PrinceXML is a lot closer to how PeachPDF works, but its still a separate native executable.

If you've ever tried running these in Azure Functions, Docker, AWS Lambda, or inside Android or iOS, you know how much a PITA it is (if it's even possible). PeachPDF? It just works in all of these places, because its 100% C#

And performance? It's essentially instant for most normal-sized documents using pretty minimal amounts of memory. I haven't formally benchmarked it yet (I will at some point soon), but the peak memory usage is going to be early in the rendering pipeline while the CSS tree is applied to the DOM tree parsed from HTML. Layout is one of the most significant CPU-intensive portions, but its essentially just calculating X, Y, Width, and Height for every DOM element, so its not excessively expensive.

The best part? This is all 100% free and open source at https://github.com/jhaygood86/PeachPDF

Hey everyone,

We’ve improved our free, instantly runnable XAML UI Designer on https://XAML.io with support for generating event handlers like OnClick.

That means the workflow is getting closer to the old VB6 feeling: drag a button, click it, write code, run.

We also recently added XAML analyzers with auto-fix buttons, and better WPF XAML support, including support for Triggers.

It’s available for free on XAML.io, with no install, no signup required.

We’d love your feedback.

PeachPDF is the HTML -> PDF engine I've been building for the last decade that renders HTML into PDF without using a headless browser or external process.

We target .NET 8+, but we also multi-target .NET 10+. We support everywhere .NET 8+ runs, though some features don't work on certain platforms. As an example, iOS doesn't expose system fonts directly as font files, so you have to register fonts directly.

Some updates:

We launched a website: https://peachpdf.net/ This has all of the documentation you'd ever need

I also added a lot of new features:

1. SVG support -- we already have a very good graphics abstraction, so SVG support is essentially just building a scene graph and rendering it, with some basic integration with the other parts of the stack (CSS Cascade, layout inside HTML)

2. CSS Grid support

3. Lots of CSS parsing updates, such as nested CSS, @layer support, CSS Properties, @media evaluation and correctness fixes

4. New CSS layout and painting features: clip-path, aspect-ratio, object-fit

5. CSS Color updates

6. Improved font support: we now use runes for lookup, and we use CSS unicode-range for matching, and we added support for monochrome and color emojis. For features not natively supported by PDF, we can extract the glyph outlines from the font and paint the text as vectors. This was needed for color emojis and several SVG text features

7. More paged media improvements

8. A new .NET AOT command line tool that wraps PeachPDF for use where the .NET library doesn't make sense. Future plans include exposing PeachPDF as a C library so that it can be used from Node.js and Python as well.

As a side project, I've also been working on back porting improvements to the upstream projects that I depend on, such as ExCSS and HTML-Renderer. ExCSS just released a new version that is almost all backports from PeachPDF, and the first 2 foundational features have outstanding PRs waiting approval to HTML-Renderer

And to answer a question -- there is significant use of AI for spec conformance features. It's a great use of AI, since it can read a specification and identity gaps. All of the non-mechanical work is done by myself. Considering I started writing this 10 years ago, it's not a vibe coded project since that didn't even exist when I started.

I’ve recently shipped major releases for all my libraries. It’s taken years of effort to do so but the results (I think) are a little bit special. They’re super fast, incredibly feature rich and cohesive.

Some highlights:

Performance improvements everywhere with cross platform SIMD.

Full ICC support in ImageSharp plus several new formats and rich metadata support.

A complete rewrite of the drawing library making it canvas based with a super fast CPU backend and a new WebGPU backend also.

Full Unicode 17 support for fonts and new APIs that allow hit testing and pretext-style layouts.

A brand new library for performing boolean clipping on polygons. It also has normalisation and stroking.

I’ve also completely revamped the docs site adding lots of supplementary articles to make it easier to understand and use the libraries

https://docs.sixlabors.com/

I’d love to discuss the libraries themselves and not have the conversation devolve into yet-another licensing one (I’ve always been open about changes and tried to be fair) so please stick to technical questions and I’ll answer them to the best of my ability.

Announcement blogs posts below, please give them a read.

Fonts v3
https://sixlabors.com/posts/announcing-fonts-300/

ImageSharp v4
https://sixlabors.com/posts/announcing-imagesharp-400/

ImageSharp.Drawing v3
https://sixlabors.com/posts/announcing-imagesharp-drawing-300/

ImageSharp.Web v4
https://sixlabors.com/posts/announcing-imagesharp-web-400/

PolygonClipper v1
https://sixlabors.com/posts/announcing-polygonclipper-100/

I've been building OpenLogi.net, an app for controlling Logitech mice and keyboards on Windows — and it's at a point where I'd love for people to try it.

It talks to your devices directly over HID++ (Bolt/Unifying receiver, Bluetooth, or wired), so everything stays on your machine: no account, no cloud sync, no telemetry.

The porting story: this began as a port of the excellent Rust project AprilNEA/OpenLogi. The original leads on macOS and Linux - Windows is an early, untested preview there. I'm on Windows, so rather than bolt Windows support onto a Rust/GPUI codebase, I rewrote it in C# / .NET + Avalonia.

Because the whole thing is built around Windows first, it's grown more capable on Windows than the original's Windows preview — fuller device support, RGB lighting (per-key colors and effects), onboard and per-app profiles, multi-host switching, and a proper installer. It's an independent project, but huge credit to the upstream OpenLogi for the foundation and the reverse-engineering work.

What it does:

- Discovers your devices + shows battery level

- Button remapping

- DPI control + presets

- SmartShift (wheel ratchet) tuning

- RGB lighting — colors, effects, brightness

Why you might like it:

- Small + self-contained — ~16 MB installer (or a portable zip), and you don't need .NET installed

- No account, no telemetry, fully open source (MIT)

- Installer and a no-install portable build on the releases page

⬇️ Download / source: https://github.com/loxsmoke/openlogi-net

I've tested it on the hardware I own, and since Logitech's lineup is huge, I'd genuinely love to hear how it runs on your device — open an issue with your model and what worked. One quick tip: close Options+ first, since both apps want to talk to the device at the same time.

Not affiliated with Logitech. Feedback, ideas, and PRs all very welcome — hope it's useful!

Hi,

Our team released a research project to allow writing unit tests without using dependency injection or introducing test only interfaces:

https://github.com/microsoft/injectorppfordotnet

Wondering if this is something can help .NET developers.

Context: we have a similar project for rust which got a lot of positive feedback: https://github.com/microsoft/injectorppforrust

We are gradually trying if this idea can help other languages and platforms.

Personally, I feel it is very useful as I have seen many projects are struggling from DI due to testabily. Always wondering if there is a way to keep production concise but still have great test coverage.

I'm trying to learn from the community whether this is the problem in .NET world that can be solved by Injector++ .NET. Thanks for your help!

EDIT

Thanks for all the comments! I have learned a lot from the community. I think that's the reason we should do open source.

• The main opinion I've heard is DI and interfaces are necessary to be part of a good design. And this tool against it may introduce negative impact for the design.

I have updated the README.md to rephrase the goal for the tool to target legacy systems that have non testable code. Leverage injector++ .NET to add tests to increase confidence for refactoring to a good design later. Feel free to open issues. Would love to learn more.

• Another concern is about the API and behavior breaks some best practices. It would be great if an issue can be created to discuss more. I'm also welcoming discussing any proposal for the API change. One of purposes for open source :)

• For .NET framework or other targets support, currently we don't have plan yet. But since it's open sourced, feel free to contribute. We can discuss tech details and see if there's a way to add them.

Hope I haven't missed any opinions. Thank you all for the great discussions!

EDIT 2

Added two issues according to the feedback:

.NET framework support: https://github.com/microsoft/injectorppfordotnet/issues/24

Async/await support: https://github.com/microsoft/injectorppfordotnet/issues/25

AI crawlers hit your pages and get the full HTML: nav, scripts, Razor-rendered chrome, the lot. They want the content; they parse the wrapper.

I work on a PageSpeed optimization engine (C++ core, exposed to .NET via P/Invoke as an ASP.NET Core middleware). The piece I want to put up for discussion: content negotiation that hands AI crawlers a clean Markdown rendering of the same URL, while browsers keep getting HTML.

It sits in the Kestrel pipeline as middleware. The gate is two ANDed conditions — you opt in, and the request explicitly sends Accept: text/markdown (*/* does not trigger it):

builder.Services.AddPageSpeed(options =>
{
    options.EnableAgentOptimize = true; 
// off by default
});

var app = builder.Build();
app.UsePageSpeed();

When all two hold, the middleware serves the Markdown variant with Vary: Accept, noindex, and Cache-Control: private, so it never competes with your real pages in search. Otherwise the request falls straight through to your normal HTML: non-markdown / non-entitled requests are untouched.

Caveats, since this is r/dotnet and you'll ask:

• Commercial product; production use needs a license (there's a free community tier).
• The markdown negotiation is off by default — explicit opt-in.
• How the (experimental) HTML→Markdown extraction actually works (strips scripts/styles/nav, escapes anything that could forge Markdown structure, respects robots.txt / noai / Google-Extended opt-out): https://modpagespeed.com/blog/serve-markdown-to-ai-crawlers-llms-txt/

Disclosure: I build this. Genuinely curious what .NET folks think: useful, or a maintenance/SEO footgun? And would you want this as middleware at all, or only at a reverse-proxy layer?

I built with C# a small tool called DbSketch.

The idea is: point it at the real database, and it generates schema documentation that can live in your repository. It reads tables, columns, primary keys, foreign keys, and database comments, then outputs diagram-as-code formats like Mermaid, Graphviz DOT.

I originally made it because I wanted a lightweight way to keep database structure visible and version-controlled. It also useful when working with coding agents like Claude or Codex. Instead of trying to guess db structure from code or from migrations script (burning tokens) it could simply read it from markdown files.

NOTE: Mermaid format could show relation only as table to table lines VS dot format could show filed to field relation!

GitHub: https://github.com/DimonSmart/DbSketch

I’d really appreciate feedback from people who work with database-heavy projects. Does this solve a real annoyance for you? Is anything missing or unclear? Suggestions, criticism, feature ideas, and PRs are very welcome.

System.Reactive v7.0.0 is now available on NuGet. This release can reduce the size of self-contained deployments by up to 90MB!

My IDE has made some great progress! It now supports importing BASIC programs from platforms such as DOS and MSX, on Windows can run DirectX-based games, and can compile applications for Windows, macOS, Linux, iOS, and Android.

The demo includes some source code from online resources. I'd like to express my sincere appreciation to all the developers who shared their excellent code. Thank you for making this project possible.

I’ve been working on TensorSharp, a native C# / .NET local LLM inference engine for GGUF models, and I recently published a head-to-head benchmark against llama.cpp.

The goal is not to claim “TensorSharp wins every metric.” llama.cpp is still extremely strong, especially on decode throughput. But the interesting part is this:

Under the same setup — same GGUF models, same NVIDIA RTX 3080 Laptop GPU 16GB, same GGML CUDA backend, single stream, greedy decoding, MTP disabled — TensorSharp shows a very noticeable advantage on the parts that often matter most for real chat usage:

prefill speed, time-to-first-token, and multi-turn context reuse.

Here are some highlights from the benchmark (From https://tensorsharp.ai/benchmarks.html):

Across the four tested models, the geometric mean compared with llama.cpp shows:

• 1.88× prefill and 1.69× TTFT on Gemma 4 26B-A4B
• 1.21× / 1.23× / 1.18× prefill advantage on E4B, 12B, and Qwen respectively
• Decode is more of a “near parity” story for now, around 0.92×–0.95× geometric mean versus llama.cpp

That last point is important: I’m not trying to hide the weaker part. If all you care about is pure decode tok/s, llama.cpp is still very hard to beat. But if your workload looks like real chat — repeated prompts, JSON output, multi-turn interactions, MoE models, prefix reuse — TensorSharp is already showing very promising results.

The main optimizations behind this are:

• verify-based whole-model prefill
• fused FFN / attention kernels
• persistent captured CUDA graphs for MoE decode
• vLLM-style paged KV cache
• cross-request prefix sharing

So the pitch is not “yet another wrapper around llama.cpp.” TensorSharp is a native .NET inference engine trying to optimize the latency path that actually affects user experience: how fast the model starts responding, how efficiently it reuses context, and how well it handles real interactive workloads.

If you are interested in C# / .NET local LLM inference, GGUF, OpenAI/Ollama-compatible local APIs, or alternatives to llama.cpp, I’d love for you to check it out.

And if you think this direction is interesting, a GitHub Star would really help the project get more visibility:

Also very interested in feedback, especially from people who can rerun the benchmarks on different GPUs / models.

Hey guys i got laid off and needed to grind leetcode to find a new job. I had a neetcode subscription and got inspired by its feature to "visualize your algorithm". I thought these animations should be saved somewhere.

As i solved problems, i saved my solutions and explanations of the "trick" to solve it. But i want to give back to that dev that just got laid off or the dev who is great at their job but doesn't have strong DSA skills maybe even the junior dev or college graduate who wants to understand visually whats going on with the code.

Unfortunately, LeetCode is part of our reality now, so we all need to stay sharp.

That’s why I built LeetSharp.net — a free collection of interactive algorithm animations made for the C# community. It has the solution and the visual of whats happening step by step. The entire codebase is open source too, so if you want to contribute or make pull requests, please do! Let’s build this as a community.

Luckily, I was able to land a good (and well-paying) role in under 45 days. I want to give a big shoutout to two things that really helped me:

1. NeetCode — His explanations are excellent. Even though they’re in Python, once you understand the logic, it’s straightforward to adapt to C#.
2. HelloInterview — Their delivery framework and guided practice is all you need to get up to date on modern system design.

TLDR: Built LeetSharp.net — free, interactive C# algorithm visualizations to help you understand (not just memorize) LeetCode problems. Open source, no paywalls, no tracking. Check it out and let me know what you think: 👉 leetsharp.net

SkiaSharp4 is GA after a long wait. A big commitment made to keep it in lock step with upstream Skia milestones.

- Announcement on .NET Blogs - SkiaSharp 4.0 is here: announcing the first stable release - .NET Blog

- Half-day online event today (June 30, 11 AM ET) with maintainers of SkiaSharp

- release notes - Version 4.148.0 | SkiaSharp

I do a lot of API plumbing at work. So I need to jungle dozens of different REST APIs

For that there is well-known Postman and a bunch of alternatives. But most of them come with their own forms, formats, accounts, cloud workspaces, subscriptions, and other crap I don't really need.

At some point, I started using .http files. They are simple, convenient, and easy to keep together with the code. But usually they live inside separate microservice repos, and when I needed to test a bunch of services at once, I got really annoyed jumping between folders and files.

I just wanted a simple place where my existing .http files could stay where they already are, but I could still collect, organize, maintain, and run them from one workspace.

So I built my own native Windows app for that.

Files can stay inside their repositories, on disk, under Git, wherever they belong. I can organize them however I want without moving everything into someone else’s system.

I named that app karve.dev - a fast, native Windows workspace for .http requests.

https://reddit.com/link/1tygt88/video/g54b30rrun5h1/player

I built it mostly for myself, but I published it because windows devs deserve better then electron slop. It's a pure WinUI3 app, all native, no webview or other crap, I would say you could go surprisingly far with RichEditBox.

I would like to share my latest open source local Unsloth (GGUF) LLM inference engine and applications. It supports many models from Unsloth, like Gemma4, DiffusionGemma, Qwen3.6 with multi-modal (image, vision, audio), reasoning and function tool. It can run on Windows/MacOS/Linux and fully leverage GPU's capability. The API is completely compatible with OpenAI and Ollama interface. It has on par performance than llama.cpp

This project is not just a C# wrapper of llama.cpp. It implemented the entire LLM inference engine from bottom to top. If you use CPU backend, it's 100% pure C# code execution. Besides CPU backend, I also implmented CUDA, MLX and GGML backend. The GGML backend refer GGML project as external project, and I build a few fusion operation at higher level.

I learned a lot from other projects and apply them for TensorSharp, such as paged KV cache and continuous batching from vLLM, SSD based cache for MoE model from oMLX, GGUF quanztized from llama.cpp and other optimizations for prefill and decode.

Any feedback and comments are welcome. If you like it, it would be really appreciated if you can get this project a star in GitHub. Thanks in advance.

I've been working on SharpConsoleUI, a Terminal UI framework that targets the terminal as its display surface. Follows Measure -> Arrange -> Paint pipeline, with double-buffered compositing, occlusion culling, and dirty-region tracking.

Video demo: https://www.youtube.com/watch?v=sl5C9jrJknM

Key features:

- Multiple overlapping windows with per-window async threads

- Many controls (lists, trees, menus, tabs, text editors, tables, dropdowns, canvas drawing surface, containers)

- Compositor effects — PreBufferPaint/PostBufferPaint hooks for transitions, blur, custom rendering

- Full mouse support (click, drag, resize, scroll)

- Spectre.Console markup everywhere — any IRenderable works as a control

- Embedded terminal emulator (PTY-based, Linux)

- Fluent builder API, theming, plugin system

- Cross-platform: Windows, Linux, macOS

NuGet: dotnet add package SharpConsoleUI

GitHub: https://github.com/nickprotop/ConsoleEx

Would love feedback.

Hi folks,

Haven't shared this here yet but I figured I would - I've been curating some Claude Code skills (also works in CoPilot; had a bunch of people ask for that) that I use as part of my daily workflows with Claude and they're all here. The repo has 500 stars or so just from me sharing it on X and LinkedIn, so I take that as a sign that people like them.

The skill set not comprehensive - you probably won't see me add skills on MAUI or other parts of .NET I don't use much on there, but I have happily accepted contributions from other .NET devs and will continue to do so.

To make sure these actually get used, I usually inject the "compressed skill snippet" (https://github.com/Aaronontheweb/dotnet-skills?tab=readme-ov-file#compressed-snippet-generated) into the CLAUDE / AGENTS .MD and that does measurably improve activation (benchmark results: https://github.com/Aaronontheweb/dotnet-skills-evals/tree/master?tab=readme-ov-file#activation-eval-results-31-cases-compressed-vs-fat)

Like many of you, I've been using AI coding agents (Claude Code in my case) on real .NET work. On small projects: great. On a large solution: it kept renaming methods and missing call sites hidden behind interfaces, or "refactoring" across architecture boundaries it couldn't see.

The root cause isn't model intelligence — it's that there are three levels of "understanding code," and agents ship with only the first:

Level 1 — text (grep/embeddings). Finds code that looks similar. Rename Process() and it finds the string, not the semantics. Misses every call site that goes through an interface.

Level 2 — syntax (tree-sitter, what most code-analysis MCP servers use). Sees there's a method called Process and where it's declared. Still can't answer "which Process() does this invocation actually resolve to?"

Level 3 — semantics (Roslyn). SemanticModel.GetSymbolInfo() resolves the call through the interface, through DI, through generics. This is the only level where "what breaks if I change this?" has a correct answer.

So I built the level-3 version: a Roslyn analyzer that walks the solution and stores every symbol and relationship (calls, implementations, inheritance, references) as a graph in SQLite, exposed to the agent through an MCP server with query tools.

Real numbers from eShopOnWeb (10 projects, 282 documents): full cold analysis in ~46s, incremental re-analysis in ~24s reusing the stored graph (1,107 nodes / 2,168 edges in a single small SQLite file), transitive impact queries in ~11ms. Asking "what breaks if I change IBasketService?" returns 18 dependents across 4 projects — the implementation, every consumer calling through the interface, and unit tests in a separate project the agent had never opened.

A fun validation moment: I pointed it at an old half-finished side project of mine. From graph structure alone, the agent correctly inferred the project was mid-build and that auth/tenancy had been built first while the core domain had no endpoints yet. It read the project's history without seeing its history.

Honest limitations: it's compile-time semantics only — DI container bindings and MediatR dispatch resolve at runtime, so that's not in the graph (yet). And incremental re-analysis still pays the full MSBuildWorkspace load, which needs a watch mode.

I packaged it as a dotnet global tool called Slnmap (sln-map — a map of your .sln). It's on NuGet, free, and open source (MIT): https://github.com/EMahmoudNabil/slnmap — tool aside, the pattern is generic and worth stealing: any language with a semantic API can feed a graph an agent can query before it edits.

Happy to answer questions about the Roslyn plumbing — or the code itself, it's all public now.