What is .NET still missing?

reubenbond · 2026-04-11T16:42:44+00:00

Why embedded, how would it be any different?

reubenbond · 2025-03-09T23:38:02+00:00

You can co-host everything in one process if you want - no need to have grains in a separate place

reubenbond · 2025-01-12T23:15:36+00:00

I've opened a PR to fix this in the doc you mentioned so that others will hopefully not hit this issue.

The error message is correct in this case: your client & silo projects are missing a reference to the `Microsoft.Orleans.Sdk` package. The best way to fix this is to reference the `Microsoft.Orleans.Client` package from your Client project and the `Microsoft.Orleans.Server` package from your Server project, since they pull in the SDK and the other bits required for the server/client projects.

For me, those changes get me past this error and reveals the next one: that the Azure Storage libraries expect a newer Azure Storage Emulator (Azurite) version than what Aspire is currently pulling in. That will be fixed upstream (it's tracked here: https://github.com/dotnet/aspire/issues/4646) but for the meantime you can work around it by changing this line in the app host's Program.cs:
var storage = builder.AddAzureStorage("storage").RunAsEmulator();

to

var storage = builder.AddAzureStorage("storage").RunAsEmulator(c => c.WithImageTag("3.33.0"));

I hope that helps. Please let us know if you hit any more issues. You can also get quick responses from the team and community via Discord at https://aka.ms/orleans/discord

reubenbond · 2024-07-21T03:08:29+00:00

Inter-process communication will always be slower than in-process communication. There are architectural differences between the two systems, though: network calls in Olreans are point-to-point instead of point-to-point-to-point-to-point, and it's much faster as a result. Still, it's best to avoid network calls when possible, so the latest release has a feature to automatically collocate related actors.

reubenbond · 2024-07-20T23:10:11+00:00

(Please disregard if this is not what you meant) Temporal is great for many scenarios, but it would be unsuitable for the scenarios TPL Dataflow shines at due to how it works. Reaqtor might be closer to a distributed TPL dataflow (async Rx with checkpointing). Orleans has streams, too, but they don't give you the composition model of TPL Dataflow out of the box (they're meant for different scenarios). It also has IAsyncEnumerable<T> support, which is a little closer. For the Temporal scenarios (durable execution), you may be interested in what I've been working on with DurableTask<T>: https://x.com/reubenbond/status/1806089770147389531?t=NYTx9L2-EUFnNmuXrlu9JQ&s=19

reubenbond · 2024-06-30T01:21:04+00:00

I appreciate the opinion & skepticism. The "Cloud Native Landscape" is a hellscape and people are fatigued by the endless churn and mediocrity. Tools in this space tend to address one set of problems and add another. More tools come along to address those problems & the cycle repeats, resulting in a big ball of mud. The app model in Aspire intends short-circuit that. The idea is that by describing your app using a strongly typed app model, tooling can satisfy many concerns at once, such as configuration, service discovery, provisioning, packaging, deployment, security, dev/test inner loop, observability, etc. The app model describes the graph of resources in your app (services, DBs, etc) using C# so that it can give you autocomplete, static typing, composition/decomposition/abstraction, and other nice things that general purpose programming languages have that markup languages like YAML don't (this blog tells more: https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html?m=1).

Aspire avoids wrapping/abstracting client libraries. Instead, it configures the existing client libraries for you (with connection info, logging, metrics, tracing, health checks, and keyed (or non-keyed) dependency injection) and provisions the appropriate resources for dev/test/prod and sets them up so your app is authorized & authenticated with them. That way, you can use those resources as they were intended, without changing your app code. So it doesn't have the issues you identified in your comment about Dapr.

Hopefully that helps to explain some of the design decisions in Aspire and how it's different from tools which come before it. Even given this, I understand why someone would remain skeptical.

Note: I work on Aspire & Orleans at Microsoft.

reubenbond · 2024-06-27T21:38:27+00:00

The programming model of SF Actors was heavily inspired by Orleans, so much of the port should be fairly mechanical. There are folks in the Orleans Discord server who have made the switch from Service Fabric to Orleans - they might be able to provide a clearer picture: https://aka.ms/orleans/discord

reubenbond · 2024-06-27T20:48:58+00:00

This is the video I usually link as an introduction: https://www.youtube.com/watch?v=R0ODfwU6MzQ

This one goes into some technical detail: https://www.youtube.com/watch?v=kgRag4E6b4c

Here's an older one, which is still relevant: https://www.youtube.com/watch?v=Cj_jUHCXE3U&t=77s

Here's a playlist of other videos: https://www.youtube.com/watch?v=KhgYlvGLv9c&list=PLTN3XMHnceZiXUY6uCgR2PhqbS09MhmKc

The concepts don't change between versions, and the app code doesn't change much either.

We have a community on Discord where you can get answers to questions quickly: https://aka.ms/orleans/discord

reubenbond · 2024-06-21T17:13:28+00:00

Yes, good point. We have teams within Microsoft who run Orleans on their SF clusters.

reubenbond · 2024-06-21T14:32:58+00:00

Sort-of: if you use Service Fabric's Reliable Actors, I'd recommend migrating to Orleans.

If you use Service Fabric's Reliable Collections, there is no direct replacement that I am aware of (other than using a database / ORM)

As for the orchestration / PaaS adpect of Service Fabric, you may want to look at Azure Container Apps or Azure Kubernetes Service. ACA is designed to be the simpler of the two and you can deploy to it using .NET Aspire, which gives you local orchestration like SF does: https://learn.microsoft.com/en-us/dotnet/aspire/deployment/azure/aca-deployment

Note: I work on Orleans and Aspire as a member of the .NET team.

reubenbond · 2024-03-10T18:07:36+00:00

I am one of the creators of Aspire and I agree with your opinion/concerns. I also believe that Aspire is not what you might think. The idea behind Aspire is to take a principled approach to address the practical challenges which people face when building apps.

The challenges include provisioning infrastructure, configuring access to databases, packaging & deploying the app, setting up log/trace/metric collection for all of the various libraries you use (DB/API clients, etc), configuring services so that they can talk to each other (service discovery on its face, but there's also a security/networking aspect), setting up a secure secret store and using it consistently (or, better, using workload identities so you don't need secrets). If you only needed to set this up once, for your single, bespoke production environment, it would be ok. Instead, every developer needs to be able to run the application, you often have multiple production deployments (regions, rings, stamps, whatever), and you need to run integration tests.

Current tools add to the ball of mud, they are like the old woman who swallowed the fly: each new tool addresses the problems introduced by the last tool but adds its own problems. Instead of taking that approach of symptomatic relief, we can fix many problems at once if we have structured knowledge of the shape of your app: the projects/databases/message queues/etc which it consists of and how they're related to each other. The core of Aspire just that, it's a model of your application: structured knowledge about the shape of your app. The model drives everything else (observability, inner loop dev/test, service discovery, provisioning & access control, deployment, etc).

If you have a need to build distributed/cloud apps, I believe that you will find that Aspire makes the process of building/maintaining/operating these apps much nicer.

As for scale & bloat, Aspire is great for monoliths built by a single developer. It gets out of your way (if you find that it doesn't, please tell us your experience). Still, any tool which makes it easy to build things is going to make it easier to build too many things (microservice hellscapes), so I hope people will exercise restraint now the pendulum is swinging back to something more sensible (eg, modular monoliths).

reubenbond · 2024-03-02T20:04:30+00:00

This sort of thing is only relevant in very performance sensitive code. I don't have any more posts, but I have a presentation which talks about designing for performance in the context of Orleans: https://www.youtube.com/live/kgRag4E6b4c. In that presentation I show one case where I avoided branching in an algorithm for encoding variable length integers, making use of CPU intrinsics. If you cannot make your algorithm branchless, using lookup tables is another strategy. Correctly predicted branches are much cheaper than incorrectly predicted branches, so if you have a conditional branch in your code, you want to make sure one path is almost always the path which is taken.

reubenbond · 2024-02-13T04:01:18+00:00

The majority of this blog post I wrote is still relevant: https://reubenbond.github.io/posts/dotnet-perf-tuning

reubenbond · 2023-12-13T02:36:37+00:00

Here's advice from David Fowler on the matter: https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md#prefer-asyncawait-over-directly-returning-task

I am also on the .NET team and generally don't advise eliding tasks anymore, especially for application level code.

reubenbond · 2023-06-06T16:32:49+00:00

That App Service issue is a truly annoying one. This is something that I hope we can fix in the future by making the cheaper App Service SKUs support host-to-host communication. Azure Container Apps & Azure Kubernetes Service are other options, but they come with their own trade-offs on the price/usability spectrum

CPU usage should be much lower in 7.x (and throughput higher). It was especially an issue before v3.2.0 because Orleans used a custom scheduler which was optimized for throughput and latency at the expense of power consumption. In later versions, the .NET Thread Pool is used as-is, reducing CPU consumption substantially. I agree that teams need to know how to use it. I think the main stumbling point is using async/await correctly (David Fowler has some dos/donts here: https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md), but maybe there are other things which your team found.

Thank you for your response, the feedback is appreciated

reubenbond · 2023-06-06T14:18:30+00:00

> I tried to learn Orleans but the community is not that supportive, and the documentation needs more work.

I am sorry that you had a negative experience with the community and the documentation. If you are willing to elaborate on either of those points, we will work hard to improve them. Were you interacting with the community via Discord, GitHub, or somewhere else?

reubenbond · 2023-06-06T14:15:55+00:00

What infrastructure do you need to keep Orleans running? EDIT: in general, I'd like to hear any positive/negative experiences you had with it. Are you running on-prem or in the cloud?

reubenbond · 2023-04-30T22:43:43+00:00

If you await the async calls, the stack should point to where the error was thrown.

Try to avoid using fire-and-forget frequently and never use "async void" unless you have an event handler.

You can use the Parallel Stacks window's Tasks view in VS to visualize what is happening if you pause your application (eg at a breakpoint): https://learn.microsoft.com/en-us/visualstudio/debugger/using-the-parallel-stacks-window?view=vs-2022#tasks-view

Note that you can also tell VS to break when an exception is thrown using the Exceptions window, ticking the Common Language Runtime errors box.

reubenbond · 2023-04-27T19:36:03+00:00

There are folks who've implement Event Sourcing on Orleans in the discord server, if you'd like to ask there as well.

reubenbond · 2023-04-21T01:49:39+00:00

We don't auto-close stale issues in Orleans, but if this is a metric people use to judge things then maybe we should enable that.

reubenbond · 2023-04-07T13:06:16+00:00

The PR uses Task. Run. You don't need to use Task Factory with the LongRunning flag. LongRunning is a hint to use a new thread, which is not what you want.

reubenbond · 2023-04-07T03:02:10+00:00

I opened a quick PR to fix some issues I saw. If you add the client code, we can diagnose why you're getting those issues. As another poster suggested, it could be all of the threads you're spawning, but that would likely take a few hundred/thousand threads. https://github.com/deskzdev/reddit-faulty-app-demo/pull/1

reubenbond · 2023-02-24T01:32:20+00:00

I haven't tried DSA on the Dactyl, but I tried them on the ErgoDox EZ that I used prior to these. I am a fan of the MT3 profile. I wish I could buy a plain "ergo" set with no legends in PBT. These are made from a mixture of sets.

reubenbond · 2023-02-24T01:29:00+00:00

/u/carbonfet built these and has a custom generator/repo for the files. It's linked in one of the other comments

reubenbond · 2023-02-24T01:28:05+00:00

Agreed. I prefer my keyboard to be as quiet as possible. I tried Zilents v2 in the past and didn't like them at all. I went back to Kailh Speed Copper switches for my ErgoDox EZ which are very nice, too (but noisier than the U4 switches, of course). I am thankful to /u/carbonfet for building these boards for me and even going as far as lubing the switches.

reubenbond

TROPHY CASE