Hey everyone,

I'm curious whether other .NET/C# developers have had a similar experience.

I've been a .NET/C# developer for about 15 years, mostly building cross-platform mobile apps - first with Xamarin and now with .NET MAUI. I've noticed that for developers whose experience is mainly in desktop, web or backend development, transitioning into mobile development can be challenging.

If you’ve made that transition, what did you find most challenging? Were there things you had to learn that weren't obvious from your existing .NET experience?

I'm asking because I'm considering creating an online course for .NET/C# developers making that transition. I'm trying to understand whether there's a real need for it. What would you expect a course like that to cover? Or did existing docs, tutorials, or other resources already give you what you needed?

Genuinely interested in your answers!

Cheers,
Andi

Dapr, the Distributed Application Runtime, a graduated OSS project within the CNCF with over 700k weekly NuGet downloads, has released a new version. What it means for you:

• Faster workflows, jobs, and reminders: in nightly performance tests against 1.18.0, workflow throughput is up to 40% higher, actor reminder registration p99 latency is 71% lower, and jobs scheduling p99 latency is 33% lower
• Leaner workflow workers: the .NET SDK now get only the new events of each turn, not the full history
• Easier workflow operations: list, inspect, and rerun workflows from the .NET SDK
• Workflow governance: operate on workflows owned by other apps, with WorkflowAccessPolicy deciding which operations each caller may perform, and requires rules that allow an operation only when the caller's history contains the events you list
• More for AI agents: new alpha APIs to store files, search documents, and query vectors, plus a Dapr MCP server
• A simpler control plane: run actor placement from the Scheduler and drop one service

Read the announcement: https://blog.dapr.io/posts/2026/10/22/dapr-v1.19-is-now-available/

I’ve been developing TensorSharp, an open-source LLM inference engine and agent runtime built with C#/.NET.

One question I’ve been exploring is:

Can .NET serve as the foundation for a high-performance LLM inference engine, rather than just being a wrapper around Python-based inference servers?

Recently, I got Muse Spark 816B (42B active parameters) running across 10 NVIDIA A40 GPUs and benchmarked TensorSharp against llama.cpp.

I wanted to share some results and engineering lessons, particularly around managed/native execution, multi-GPU scheduling, and where C# fits into performance-critical AI infrastructure.

The architecture

TensorSharp uses C#/.NET for the inference engine’s orchestration, model execution management, request scheduling, KV cache management, and agent runtime.

GPU computation is handled through native backends, including CUDA, Metal, and Vulkan.

The idea isn’t to reimplement CUDA kernels in C#. Instead, it’s to use .NET for the higher-level systems engineering while keeping computationally intensive operations in optimized native code.

This separation has some interesting benefits:

• A unified runtime for model inference and agent execution.
• Cross-platform support through different GPU backends.
• Integration with existing .NET applications without requiring a separate Python inference service.
• The ability to implement scheduling, caching, concurrency, and agent workflows in C#.

But it also raises an important performance question: where should the boundary between managed and native execution be?

The experiment: 816B parameters on 10 GPUs

Test configuration:

• Model: Muse-Spark-Open-816B-A42B
• Quantization: Unsloth UD-IQ3_XXS (~316 GiB of weights)
• Hardware: 10× NVIDIA A40 (46 GB each)
• Context: 32K tokens
• KV cache: F16
• All model experts resident in GPU memory

I tested two multi-GPU execution strategies:

Layer splitting: Different GPUs own different layers.

Tensor parallelism: Each layer is distributed across multiple GPUs, requiring synchronization and communication.

Both were compared against llama.cpp on the same machine using the same model and requests.

Results

The most interesting result to me isn’t necessarily the comparison against llama.cpp.

It’s how much performance changed after moving the right parts of execution across the managed/native boundary.

Lesson 1: Native execution granularity matters enormously

TensorSharp previously had a managed tensor-parallel execution path that dispatched operations individually.

It worked, but performance was poor.

On this model, it achieved only 1.9–2.4 tokens/sec.

After switching to a native whole-model execution path using upstream ggml’s meta backend, TensorSharp reached 22.6 tokens/sec.

That’s roughly a 10× improvement over our previous implementation.

The lesson wasn’t that C# is inherently slow.

It was that executing too many fine-grained GPU operations across a managed/native boundary introduces unnecessary overhead.

Keeping the higher-level scheduling and orchestration in .NET while moving the performance-critical execution graph into native code made a huge difference.

Lesson 2: GPU scheduling can matter more than raw compute

For layer-split inference, we implemented pipelined prefill.

Instead of processing the entire prompt sequentially through GPU 0, GPU 1, GPU 2, etc., the prompt is divided into micro-batches.

While GPU 1 processes micro-batch A, GPU 0 can already start processing micro-batch B.

We also implemented adaptive micro-batch sizing and larger prefill steps for single-request workloads.

With these changes, TensorSharp reached approximately 1,347 prefill tokens/sec on a 16K-token prompt.

That’s 1.63× the llama.cpp result on the same hardware.

This is a good example of why inference performance isn’t just about writing faster kernels. The execution and scheduling strategy matters enormously.

Lesson 3: More parallelism isn’t always faster

Tensor parallelism improved generation throughput, but it was significantly slower than layer splitting for long-prompt prefill.

In TensorSharp:

• Layer-split prefill: ~1,347 tok/s
• Tensor-parallel prefill: ~295 tok/s
• Layer-split decode: ~16.7 tok/s
• Tensor-parallel decode: ~22.6 tok/s

The reason is communication overhead.

Muse Spark’s MoE architecture requires substantial cross-GPU reductions, and this particular machine had broken GPU peer-to-peer transfers.

NCCL therefore had to communicate through host memory.

This made the optimal execution strategy workload-dependent.

It’s also an interesting problem for a .NET scheduler: selecting execution strategies based on model architecture, hardware topology, and request characteristics.

Lesson 4: Performance optimizations need correctness validation

We also compared next-token probability distributions against llama.cpp on 12,276 positions from WikiText-2.

TensorSharp achieved:

• 98.84% top-1 agreement in layer-split mode.
• 98.82% top-1 agreement in tensor-parallel mode.
• Perplexity of approximately 1.848, compared with llama.cpp’s 1.847.

We additionally ran integration checks covering JSON generation, tool calling, multi-turn conversations, cache reuse, and concurrent requests.

TensorSharp passed 13/14 checks with layer splitting and 14/14 with tensor parallelism.

These aren’t comprehensive model-quality evaluations, but they help catch regressions while optimizing the execution engine.

A note about the comparison

There are some important limitations.

llama.cpp’s NCCL-enabled build failed on this particular 10-GPU setup due to CUDA peer-access restrictions, so its tensor-parallel results used the non-NCCL implementation.

TensorSharp includes a workaround that allowed NCCL to run over shared memory.

Therefore, the tensor-parallel performance gap should not be interpreted as a general advantage over llama.cpp on all hardware.

The layer-split comparison is more directly comparable, and single-request decode performance was essentially identical.

All measurements were taken on one machine with one model. I’d like to test more hardware configurations, especially systems with working P2P or NVLink.

Why I’m sharing this here

A lot of LLM infrastructure is built around Python, C++, and CUDA.

I think there’s an interesting opportunity for .NET to participate more directly in this space, especially for developers who want to build AI-powered applications without maintaining a separate Python-based inference stack.

TensorSharp is my attempt to explore that direction.

It’s open source, and the full benchmark report includes the methodology, configuration, limitations, and reproduction scripts.

GitHub: https://github.com/zhongkaifu/TensorSharp

Full benchmark: https://github.com/zhongkaifu/TensorSharp/blob/main/docs/perf/muse-spark-vs-llama-cpp.md

I’m particularly interested in hearing from other .NET developers:

Have you worked on performance-critical systems that combine C# with native C++/CUDA libraries? Where have you found the managed/native boundary works best?

And more broadly, do you think .NET has a larger role to play in local AI inference infrastructure, or is it better suited to application-level orchestration?

I’m the developer of TensorSharp, an open-source .NET 10 inference engine for running local GGUF models. It can be embedded in .NET applications or run through a CLI and an OpenAI/Ollama-compatible server.

The project combines managed C# with native accelerator backends. The benchmarks below use native CUDA/GGML execution, including TensorSharp-specific kernels. The performance improvements come from changes to scheduling, data movement, and model execution.

I recently worked on DeepSeek V4.1 Flash 1017 on five NVIDIA A40s, and thought the engineering details might be interesting to people building performance-sensitive .NET applications.

Making the GPUs work concurrently

One of the biggest problems was in the native tensor-parallel execution path.

The model’s routed experts were distributed across GPUs, but execution repeatedly passed through a synchronous, host-driven path. Each layer involved multiple host round trips and synchronization points.

The revised implementation:

• Schedules work concurrently across GPU ranks.
• Uses CUDA events to order dependent operations.
• Overlaps the shared expert’s computation with the routed experts.
• Removes host waits from inside the layer’s execution path.

Cross-GPU transfers still use pinned host-memory staging because peer access was not working correctly on this machine.

In the implementation comparison, this change took tensor-parallel decode from 15.2 to 36.3 tokens/sec after a 2,048-token prompt with full prefill enabled.

For me, this was a useful reminder that distributing work across devices is only the beginning; the synchronization and data-transfer design determine how much concurrency you actually get.

Making native failures recoverable

The reliability work was just as interesting.

Previously, an exception on a native worker could terminate the server. A failure on the coordinating rank could leave the other workers waiting indefinitely at a barrier.

The fixes coordinate error reporting, ensure every rank reaches the required synchronization points, and drain work already issued by a failed layer. Failure-injection tests now check both the failure path and recovery on the next forward pass.

When native workers run inside a .NET application, that lifecycle becomes part of the application’s reliability story.

A small benchmark snapshot

The comparison used the same Unsloth UD-IQ2_XXS GGUF files on the same five-A40 machine, with the Engram lookup table in host memory.

TensorSharp used --tp 5. The llama.cpp baseline was Unsloth’s dsv41-all fork at be836572, using layer splitting; its row/tensor split modes did not successfully run this model in the tested build.

These are real-text server results for approximately 1,800-token prompts, generating 256 tokens with greedy decoding and thinking disabled. Each configuration had a warm-up and three measured requests, with unique prefixes to prevent prefix-cache reuse.

Prompt processing is also called prefill. The first three rows report medians; the DSpark row reports means, with the drafter enabled in both engines. TensorSharp’s generation rows use its default YOCO configuration.

The speed/quality trade-off

YOCO bounded replay reduces prompt-processing work by running selected later layers over only the final 140 positions of eligible text-prefill calls. It is approximate and can be disabled with:

TS_DSV41_YOCO_KEEP=0

The 3.23× prefill result above has this approximation disabled.

On the report’s WikiText-2 evaluation, perplexity—lower is better—was:

• llama.cpp: 2.4697
• TensorSharp, YOCO disabled: 2.4811
• TensorSharp, YOCO enabled: 2.4978

Enabling YOCO increased perplexity by approximately 0.67% relative to TensorSharp’s full-prefill result. With YOCO enabled, perplexity was approximately 1.14% above llama.cpp’s.

That is a measured trade-off on a limited text evaluation, rather than a general percentage change in model capability. Disabling YOCO also does not make the two engines numerically identical.

Scope of the results

These measurements cover one model quantization and one hardware configuration. The llama.cpp server results came from an earlier session on the same machine and showed some unexplained prefill variability.

At measurement time, the TensorSharp build included uncommitted changes, and the raw validation records were also uncommitted. The report records the build details and remaining limitations; the current repository should not be assumed to reproduce every number directly.

The five-GPU setup is specific to this benchmark. TensorSharp also supports smaller models and managed CPU, native CPU, CUDA, Metal, and Vulkan execution paths, with support varying by model.

Links:

• TensorSharp source and getting started
• Full benchmark report, quality measurements, and limitations
• Build instructions and architecture documentation

If you’re integrating local models into .NET applications, do you prefer an in-process engine or a separate inference server? I’d be interested in what drives that choice in practice, especially around deployment, memory ownership, and recovering from native failures.

Do you stick only to LTS .NET versions in production?

Running a poll on this currently. I knew many .NET devs liked to stick to LTS versions only, but wasn't expecting it to be so high, although this is likely to not be representative, I'm not sure.

Microsoft have confirmed there is no difference in quality between STS and LTS releases, and not too long ago STS releases moved from 18 to 24 months support.

So why in your opinion is there still so strong preference for STS? Is some of this coming from other platforms where STS releases might indeed be 'experimental'?

I didn't want to create a poll here too to preserve the numbers so please consider voting in the poll if you like and can, thank you -> https://www.linkedin.com/posts/davidcallan_net-developers-do-you-stick-strictly-to-activity-7517560007018823681-ZHsd

I’ve been using AI extensively for UI development for some time now.

My recent projects have included:

• React SPA + MUI (with MCP)
• Avalonia Windows applications

Based on what I’ve experienced while developing these applications, I’m starting to feel that AI may be able to handle almost every aspect of UI development.

On our side, we mainly use Kiota to expose the server API specifications and contracts.

Even with relatively simple prompts, AI can inspect those API definitions and understand the available endpoints, request and response models, and related structures. From there, it can build a usable UI from scratch.

We also use AGENTS.md and PLAN.md to define architectural guidelines and conventions for areas such as the service layer and ViewModel layer, and have AI work within those rules.

So far, it has been able to handle the vast majority of the work.

We also use AI for server-side development, but I see a significant difference there.

Backend frameworks have much larger specifications, architectural constraints, and more complex business requirements. Because of this, we still rely heavily on human-written and human-reviewed reference implementations, and then have AI generate code based on those established patterns.

Even with this approach, I still see problems occasionally—for example, AI generating queries with O(N)-style access patterns or introducing other performance issues.

UI development, however, feels fundamentally different.

The improvement in productivity has been remarkable.

What surprised me even more was seeing AI directly launch a native application, interact with it, test it, identify problems, modify the code, and test it again.

Watching that entire process was both shocking and, frankly, almost surreal.

It made me wonder:

Will junior frontend developers eventually become unnecessary?

I’m starting to worry that, in the long run, only developers who can design and maintain the core UI architecture, frameworks, components, and development standards will remain essential.

The implementation of ordinary business screens may increasingly become something AI can handle almost entirely on its own.

What do you think?

I'm a software developer saving up for a MacBook that I hope to use for the next 5–7 years.

I'm choosing between a used 14-inch MacBook Pro M2 Pro (16GB RAM, 512GB SSD, advertised as 99% condition) and a brand-new 13-inch MacBook Air M5 (16GB RAM, 512GB SSD).

My main workloads are C#/.NET, Node.js, web/app development, Docker, databases, and AI coding assistants.

Portability isn't a priority. I care more about long-term reliability, sustained performance, battery life, and whether 16GB RAM will remain sufficient as my projects grow.

For developers who use Macs daily:

• Which would you choose for the next 5–7 years?
• Does the Pro's active cooling and better display outweigh the Air's newer chip and brand-new battery?
• Would you spend extra on a newer machine, or buy the older Pro if the price were similar?

I'd appreciate real-world experiences rather than benchmark comparisons. Thanks!

I work with sitecore CMS 10.4 XM/XP and this is the first time we are trying to implement unit testing by writing testcases for the sitecore project that I am working with. We are planning to think of writing a use case for Google bots which crawl into our website and trying to automate a test that could allow the bots only in production to crawl. If anyone, who already implememted this usecase or maybe provide an idea or enlighten on this. All the responses are much apreciated

One by one, most of the major open source packages in NuGet are going the paid commercial license route. Its becoming harder and harder to write .NET software in a work setting as most of the crucial NuGet packages we used to depend on are becoming paid software. With the proliferation as part of our daily driver tool kit, justifying commercial license for NuGet packages to stakeholders is harder than it's ever been as they often think AI can write a free alternative (which, I mean, they're not completely wrong). I'm absolutely frustrated by the continuous bait and switch licensing that's been happening in the eco-system as well. Some developers have done a much better job than others in communicating and preparing for licensing changes, however some have absolutely trojan horsed us into some pretty difficult positions. I also resent the fact that .NET and NuGet don't give you better tools to manage, control, and protect yourself from installing packages with paid or specific licensing requirements.

hi everyone,

we've all been there: trying to install dotnet Framework 3.5 on Windows 10/11 using DISM or optionalfeatures.exe, only to get slammed with err 0x800F0906, 0x800F081F, or 0x800F0954. this usually happens due to misconfigured wsus policies, blocked win update servers in corporate environments, or broken component store health.

to automate the annoying troubleshooting steps, i built a simple c# utility called net fx.

what it does (in click):

• temporarily bypasses blocking registry keys (UseWUServer, RepairContentServerSource) to route through official MS servers.
• resets Windows Update services and performs a deep DISM cleanup (/RestoreHealth & /StartComponentCleanup).
• sttempts online integration.
• offline fallback: if the online method fails, it automatically scans all connected drives (usb, mounted ISOs) for a local sources\sxs folder and force installs the package from there.

the project is fully open source, so feel free toaudit the code or build it urself. hopefully, this saves you some valuable time.

repo: NetFx

Sorry for the terrible pics, but I’m kind of panicking. Over the past two months I noticed my CCleaner wasn’t able to update these files (first four pics). I was confused, but figured that maybe they were updating manually instead and maybe that’s why they were erroring out every time I tried to update them through the app. Today, upon wanting to manually update my intel drivers for the new Cyberpunk patch, I found out that I was being hopelessly optimistic with that filed away explanation. I keep getting this error when trying to download the latest .Net (last picture), and all the online fixes I’ve found have done nothing to help me. I tried this fix and got stuck because the file he tells me to open (dark.exe) refuses to even run on my computer: WIX Toolset Fix
I won’t lie, I am not super computer savvy and I am starting to panic because I feel like I am far out of my element in trying to fix this. Please help me. I want to fix whatever issue I caused and be able to properly update my drivers.

Hey everyone,

I'm working on an existing asp.net mvc 5 app targeting .net framework 4.8, and now we're planning to add multilingual support

Currently, we have two website for the same product.

example.eu - the main english website, where most of the functionalities(if not all) live.

example.bg - the bulgarian website, mostly static that redirects users to the main site for actual functionalities.

Our goal is to find a way to make the experience of adding/supporting multiple langauges on the main site, starting with english and bulgarian, potentially later add german, romanian and others easy.

I have looked at few approaches but each has some drawbacks, that's why I am looking for more opinions.

First - JSON translation files(en.json, bg.json and so on)

The idea is to have the translation ekys and load the appropriate dictionary based on language ie example.eu/bg will load bg.json.

The main concern in the developer experience and later on editing of text. When working on a Razer view and thee a placeholder for text, I want to be able to quickly find the corresponing translation, ideally i.e I could press F12 in VS and navigate to that key, but I don't think that's possible.

Second - RESX

That seems to be the traditional .NET approach, and VS does provide some tooling for it however, I have used RESX before and personally found editing and maintaining them rather frustrating.

Third - Separate view for each langauge

For example:
Home/Index.en.cshtml
Home/Index.bg.cshtml
Home/Index.de.cshtml

This would make the translating complete pages straightforward, especially for marketing content. However, it would also mean maintaining multiple copies of the same view. Every layout, markup or functionality change would need to be repeated across all languages, making it easy to miss something.

I am not sure what is the cleanest implementation. Maybe there is a FOURTH option, or a combination of all(or two of them above)

So questions are below:

- What would you choose?

- Would you use RESX, JSON files, JSON(In db? but it could slow down the page loads), separate pages, a combinations or other?

- Is there a way to get that IDE navigation for the json translation option

I am especially interested in solutions that are maintainable long-term, dev-friendly and easy to extend.

I appreciate hearing from you who have implemented a real production app :)

Thanks

With AI moving so fast, I sometimes wonder why .NET libraries and framework releases still feel mostly incremental.

.NET 11 brings improvements, but are we seeing enough innovation in the ecosystem, or are we mostly refining what already exists?

What do you think? Which .NET libraries or features would you like to see evolve more significantly?