As usual, there are a boatload of new APIs coming in .NET 6. Most of these are driven by custom requests. Lets talk about some of them. #dotnet#aspnetcore
In .NET 6, there's a new low-level API to enable reading/writing of files without using a FileStream. It also supports scatter/gather IO (multiple buffers) and overlapping reads and writes at a given file offset.
There are a couple of new ways to access a process path and process id without allocating a new process object:
Generating random numbers from a CSPNG (Cryptographically Secure Pseudorandom Number Generator) is a little easier:
We finally added Parallel.ForEachAsync, a way to schedule asynchronous work that allows you to control the degree of parallelism:
We added a helper to make it easier to throw if a required section of configuration is missing:
There's a ton of new LINQ methods as well. It got lots of love in this release. Here's a new helper to chunk any IEnumerable<T> into batches:
Don't keep bit math in your head? Me neither, here are some new helpers for working with powers of 2:
There's now a much easier (and properly implemented) way to wait for task to complete asynchronously. The following code will yield the await if it hasn't completed in 10 seconds. The operation might still be running! This is for un-cancellable operations!
More LINQ! There are now MaxBy and MinBy methods:
We added an entirely new metrics API based on @opentelemetry in .NET 6. It supports dimensions, is *super* efficient and will have exporters for popular metric sinks (prometheus etc).
OK that's it for now! Enjoy playing with .NET 6 previews and we love you feedback.
OK one more (I posted this a while back). Native support for Posix signal handling. We also emulate a couple of signals on windows.
Oh wait this is one coming in preview7 I should mention. You can all delete your helper methods that do this now 😅.
If you feel like using C APIs to allocate memory because you're a l33t hacker or you need to need to allocate native memory, the look no further. Don't forget to free!
Last but not least, a modern timer API (I think this is the 5th timer API in .NET now). It's fully async and isn't plagued by the types of gotchas the other timers are plagued with like object lifetime issues, no asynchronous callbacks etc.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Here's some code that is on the hot path on your application and you want to optimize it. This is what a typical C# developer would write (actually copilot wrote this). It's pretty clear, but suboptimal. How could you go about improving it? #dotnet #csharp
There are lots of allocations here: 1. The string[] splitting up query string parts by & 2. Each key value pair string[] splitting each part by = 3. The List<string> of new results 4. The final string
One more assumption you can make: The instanceId will only occur once or 0 times in the input querystring.
Discrete events masquerading as a workflow should be expressed as such. Consider the following event-based model: #dotnet
The game has 3 events:
- GameStarted
- GameEnded
- OnQuestion
The order of execution should be obvious from the naming...
The application doesn't control the event loop, the event loop will trigger the events at the appropriate time. Storing state across events means understanding the order in which they fire, the thread safety of such events and more (do they fire concurrently? can you block?)
Currently designing how this trivia game will work on multiple servers. I have 3 architectures in mind (Twitter can help me pick one, but I have a preferred one). Both clients are part of the same game. Games are ephemeral and last a maximum of 2 minutes.
Architecture 1 - Using Redis as the game state storage and SignalR backplane.
Architecture 2 - Use Orleans grains as the SignalR backplane and state storage for a game.
It's Friday so time for spicy opinions. Every single sample ASP.NET Core project I see uses CQRS and the mediator pattern or CLEAN architecture. I'm over the over engineering 🙃. #dotnet
I lean very heavily towards YAGNI and readable code with minimal abstractions until needed. I appreciate that every situation is different, but like anything it's hard to appreciate the benefits when the "scale" problem isn't evident.
Blindly applying patterns bugs me ALOT. I don't subscribe to the dogma, I don't write code that way...
Another cool tye feature is networking support between containers and processes on the host. This nginx configuration is referring the process running on the machine by host name "sample" but that application isn't running in a container.
It manages all of the tricky ways to communicate between containers and local machine using (host.docker.internal) etc. This lets you run and debug your processes normally and run what needs to run as containers in your inner loop.
It creates an environment that looks like this behind the scenes.