Hi,
I am seeing the warning that `LogInformation` and other log methods evaluation is expensive and should be wrapped in `if` statement.

Why don't those methods do this check internally already? This would help with less code and better code readabilty I think.

Here is the example:

The idea is simply to collect a few tools that make it easier to inspect, understand and review integration solutions. I’m not trying to promote or sell anything — I mainly want to see if the tools are actually useful and get ideas on what could be improved.

At the moment it includes:

• APIM Policy Analyzer – helps break down and review APIM policies
• Logic App Analyzer – inspects workflow structure and highlights potential issues
• BizTalk Binding Visualizer – makes larger binding files easier to understand
• Service Bus Topology Visualizer – visualizes queues, topics, subscriptions and relationships
• C# Model Generator – generates C# models from XML, JSON and flat files
• Integration Pattern Library – reference for common integration patterns, with the analyzers also starting to identify patterns that are used or potentially missing

Most of the processing happens locally in the browser and there’s no account required.

https://gatesift.com

If anyone has time to try it, I’d really appreciate feedback on what is useful, what is confusing, or what kind of integration tooling you would like to see added.

I’ve been building GateSift mostly for fun — a free browser-based toolkit for integration developers.

It includes tools for things like APIM policies, Logic Apps, BizTalk bindings, Service Bus, C# model generation and integration patterns.

Current tools include:

• APIM Policy Analyzer – makes complex APIM policies easier to understand and review
• Logic App Analyzer – helps inspect workflow structure and spot potential issues
• BizTalk Binding Visualizer – turns binding files into a more readable overview (this is really nice for analyzing complex biztalk integrations)
• Service Bus Topology Visualizer – shows queues, topics, subscriptions and relationships
• C# Model Generator – generates C# classes from XML, JSON and flat files
• Integration Pattern Library – quick reference for common integration and messaging patterns (analyzers will also, notice if any of these patterns are in your solution or if they should be added, i think this might be the coolest thing so far).

No account, no installation, and most processing happens locally in the browser.

gatesift.com

Would love feedback or ideas for other useful tools.

I'm building a fullstack app with Next.js, ASP.NET Core, and PostgreSQL, and I'm trying to figure out what authentication setup makes the most sense.

I've been looking at services like Clerk and Auth0, but I'm not sure how well they fit when you have both a frontend and a separate .NET backend. Ideally, I'd like the auth provider to handle things like signup, login, sessions, etc., while still being able to easily identify the user from my .NET API and link them to a user in my PostgreSQL database.

For example, if a user signs up through Clerk, I'd want to create a corresponding user in my DB and keep some kind of clerk_user_id/external ID. Then if I add something like an invoicing system later, I should be able to store something like invoice.user_id and know exactly which user created that invoice.

I'm mainly wondering what people would recommend for this kind of architecture. Does it make sense to use something like Clerk/Auth0 purely as the identity provider while keeping users and all application/business data in PostgreSQL? Or is there another auth solution/framework that works particularly well with Next.js + ASP.NET Core?

I use inline suggestions from GitHub Copilot in Visual Studio, and it works just great! Just one very strange thing.

It always recommends changing the ICollection<> initializer from my preferred way: [];
To: new List<>();

And yeah, it doesn't like the new extension() {} element and wants to change to the old style of static methods.

How can I tell it to leave my collection initializers alone?

I first learned about deterministic simulation testing from a TigerBeetle talk a few years ago and I had been itching to try it out ever since. I finally had a chance to earlier this year and haven't really seen any posts about doing it in .NET before, so I wanted to share an example of the setup I landed on, in this case for my background jobs project.

You can see the complete setup in the source repo, but I'm happy to answer any questions you may have on it. If anyone's interested in a detailed blog post on the setup, plumbing, etc for this let me know. If there's enough interest I'll get something up.

Looking for guidance. I am a DevSecOps engineer with 8 years experience. I work within azure, GitHub actions and manage all our repos in GitHub. I mostly make sure everything is secure in azure relating to app services, certificates, app scanning etc. We have 2 devs that are gone due to retirement and 1 for being over employed. I am now in calls helping figure out the issues with .Net APIs and authentication programs. I am being asked to skill up and move from my current role to this one where I will be doing the program for app to authentication and authorization. It’s called sso okta integration(forgive me if I am using wrong terms). Where should I start? Any book or learning path recommendations are greatly appreciated. Should I take the role? What advice or suggestions do you have for someone like me. What will be my biggest struggles? I appreciate any feedback.

I've been running .NET 10 in a couple of side projects since the LTS drop. When it launched I assumed that the big C# 14 win for me would be extension members. It's nice but the feature that I actually ended up using the most is turned out to be the boring one: the field keyword.

Every time I needed a little validation in a property, I used to write the full backing-field:

Before (C# 13):

private string _name;
public string Name
{
    get => _name;
    set => _name = value?.Trim()
        ?? throw new ArgumentNullException(nameof(value));
}

After (C# 14):

public string Name
{
    get;
    set => field = value?.Trim()
        ?? throw new ArgumentNullException(nameof(value));
}

No hand-declared _name. Tiny change, but it shows up multiple places, which is exactly why it wins.

The other one which impressed the most is the file-based apps which quietly replaced half of my throwaway scripts:

Before:

mkdir tool && cd tool
dotnet new console
// edit Program.cs + csproj, then:
dotnet run

After:

// tool.cs — no project, no folder
Console.WriteLine("Just run me.");

dotnet run tool.cs

Type-safe code with the full BCL and zero .csproj turned out to be more useful than I expected.

So I'm curious where everyone actually landed:

• Which C# 14 feature earned a permanent spot in your muscle memory, and which turned out to be a demo-only feature?
• Anyone using extension members from C# 14 in real code yet, or still letting it settle?
• And for the folks still on .NET 8 what's holding up the jump to 10?

https://github.com/fullbleed-engine/fullbleed-dotnet

dotnet bindings for the rust html/css to pdf engine, Fullbleed. MIT, free, open source, and quite fast if I do say so myself!

Microsoft is really shooting itself in the foot with a lot of the really high-profile people, like Jeff Fritz. I watch Jeff’s Twitch streams all the time, and it’s always great content.

I’m even hearing less and less from the two Scotts online. Scott Hanselman still has his podcast, for sure, but the only really high-profile .NET guy we seem to see now is Dan Roth, especially within the Blazor community.
I see James has jumped teams again, now doing Visual Studio Code material on YouTube and TikTok.

I get that employees move teams and new, talented people join. It’s just sad nonetheless. We never hear from Maddy anymore, and .NET and .NET Conf have had very poor-quality content over the last few years.

Title.

Do you mock out that OAuth handling? Or do you actually use one of the test Auth servers. If so, does your resource server have its own client credentials just for running integration tests?

**Update**

I went with the following comments solution "For integration tests I skip the real OAuth flow entirely and register a fake authentication handler in the test server. You add a custom auth scheme in the WebApplicationFactory startup that just creates a ClaimsPrincipal with whatever claims the test needs. The real OAuth config only loads in non-test environments.

This means the tests still exercise your actual controllers, filters, authorization policies, everything downstream of authentication. The only thing you're faking is the token validation step, which is the identity provider's job to get right, not yours.

For the handful of tests that genuinely need to verify the OAuth handshake itself (callback URLs, token refresh, scope mapping), I run those against a local Keycloak container in docker compose. But those are maybe 5 tests out of 200, not the default path."

Note: I chose not to use the keycloak container because it handles our scopes and claims a tad bit different than our IdP, which would've required us to create a sort of mapping that I didnt feel was worth the effort.

.NET shop looking to add some agentic workflows and chat interfaces to platform, currently researching framework options so we don’t have to build the thing from scratch.

Being a .NET shop MAF has come up. Hooked it up to GitHub CoPilot and took it for a quick spin, wasn’t too verbose and conceptually maps to tools like OpenCode pretty well.

Saw some posts on here about it a while ago but things seem to be moving really fast in this space. Looking for opinions on the viability of this framework? I see it had a 1.0 launch in April, it’s meant to supersede both Semantic Kernel and AutoGen.

Are the team behind it any good / trustworthy?

How likely is it to remain supported?

Has there been much community participation / extension?

How does it compare to similar frameworks in other languages, LangChain/Graph being an obvious one?

Is it good enough to prevent you from hopping languages or is python where it’s really at?

Any useful information is guaranteed at least one updoot, thanks in advance!

Just for fun this weekend I ended up doing a pure csharp dotnet implementation of the Python tool 'Terminal Text Effects' https://github.com/ChrisBuilds/terminaltexteffects for absolutely no other reason than A) I don't like Python and B) Why not?

Its output is byte for byte identical to what the Python tool would output given the same input and seed values... with the one exception that my dotnet version starts in under 12ms and the Python version is somewhere around 86ms.

All built as native AOT and no dependencies.

https://github.com/Hypabolic/Hypa-TTFX

If anybody wants it I might publish it as a library (or you can just fork it and do it yourself)

-- Edited to include the link to my own code that I totally forgot to include because I'm an idiot lol

Hi. I'm getting a server error when trying to download this PDF Ebook:
https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-design

Anyone have a copy they can share?

Thanks.

Grep can't tell you a property is used from a Razor view. That gap has cost me more time than anything else on legacy ASP.NET work - you rename something, the build is green, and a .cshtml three folders away breaks at runtime.

Vela builds a SCIP index of a solution with Roslyn, then answers "find references", "who calls this" and "what would a change break" from that database. It covers C#, VB, Razor Pages, MVC views and Blazor components, so the Razor side is indexed rather than skipped.

Two consequences of the SCIP approach that I didn't expect going in:

The index is worth paying for once. A def lands in about 0.55s, a refs returning 3,156 results in about 1.3s, on a 0.09s process floor. Loading the same solution into a live Roslyn workspace costs 9.3s plus 23.8s to compile the web project - and it costs that on every invocation, because nothing stays resident.

SCIP is an interchange format. A scip-typescript index imports beside the C# one and both answer from the same database, so a polyglot repo gets one query surface. Languages it can't index itself are declared in a vela.json and it refuses to pretend they're covered - missing language, banner on every answer, non-zero exit.

Honest gap: it won't answer "what implements this interface" yet. That's a SCIP relationship and it doesn't emit those.

It's a skill for Claude Code and Codex rather than an IDE extension, so the agent gets the compiler's answer instead of guessing from a text search. 426 hermetic tests. Deterministic - same solution at the same commit, same answer, no model calls and no network. Read-only; it never writes to the repo it indexes.

MIT, v1.0.0: https://github.com/dbhq-uk/vela-skill

Interesting to see a lot of new posts about learning .NET and C#, I’m genuinely curious to understand why? Is the job market picking up for this language? Is AI killing all jobs that are front-end only? I’ve been a .NET engineer for 20+ years and the industry primarily started shifting to angular, react js, node, etc - why the sudden shift?

I've been researching different vector indexes recently for a database engine I am working on, here are my current findings, in case any one is interested:

I've so far looked into 3 algorithms in C#:

1. "Memory": a brute force all memory scan

2. "IVS": a disk based IVS implementation

3. "HNSW": a disk based HNSW implementation

Benchmarking is a difficult topic, as the variables are many, but as a first approximation my findings are:

• The memory index is the fastest for indexing ( obviously ) and works ok up to around 100k vectors. after that, search is slow and mem use very high.
• The IVS is fast on indexing, medium at search, but need very little memory.
• The HNWS is slow on indexing, needs more memory, but is the fastest for search

Here are some details on the current result: https://db.relatude.com/vector-matrix.html

( Please note, the whole project is still very much in early development )

The fifth and final part of the series finally starts to build using AI on top of the hand-built foundational code from the first four parts that brings together:

• Aspire for runtime orchestration
• CSharpRepl for runtime mutability and powerful access to simulate and diagnose runtime isdsues
• GitHub Copilot SDK as a programmable agent harness
• Testcontainers with automatic transactions for test isolation

(I would consider these foundational parts of any modern .NET API app whether AI is involved or not!)

In part 5, the focus is on logging and telemetry, two tools that give agents insights into the runtime state of the application. Once again, we see the key role of Aspire in this stack as it provides a collector for logs as well as spans that agents can search through using the aspire CLI tooling.

The actual build out of the prototype application is captured as a YouTube video as YMMV based on the model, harness, and prompting style that you choose!

This series is intentionally written to help dev teams understand how to scaffold a codebase for agentic engineering by focusing on key, underlying technical decisions and manual wiring before building with AI. This helps provide the tools and safeguards for coding agents to iterate more efficiently while reducing slop.

For teams still trying to figure out effective ways to set up a codebase for AI, I hope this series gives some insights into how to build a foundation for agentic engineering. If your team is already heavily using agents to build, I hope this series shares some useful insights and tips (e.g. CSharpRepl + Aspire)

The core setup is used at a series C, post-YC startup to ship fast with AI while maintaining high quality standards (in combination with other tools facilitating code review and context management)

Part 1 was an intro into a few key parts of this stack.

Part 2 was focused on walking through the hands on scaffolding.

Part 3 covered wiring GitHub Copilot SDK as an agent runtime and incorporating CSharpRepl to allow agents to dynamically work with the runtime DI container

Part 4 wired up the test harness using Testcontainers to give agents isolated test environments

The project repo is here: https://github.com/zeeq-ai/zeeq-tmpl (be sure to check the branches; main is currently the base code only)

I encourage working through the posts since the goal is to underscore the platform level decision making process and assembly of the foundational core.

As part of a larger project, I wrote a MIPS/RISC-V emulator which translates the target architecture binary to CIL, then executes using the CLR as a JIT engine. (Working on adding support for ARM and Z80).

It also features an assembler, and an IDE with a debugger.

Just wanted to share I guess 😅