First, you'll be able to use Aspire 9 with .NET 8 and .NET 9! It will no longer require a call to dotnet workload install, and instead uses an MSBuild SDK. This should simplify CI/CD integration and getting started immensely! All you need is NuGet!
#dotnet #aspire
Next is the first-class addition of "WaitFor". You can now wait for dependencies to start, be healthy or to be complete before running your resource.
This is much like "depends_on" in docker compose, but with the ability to write health checks in C#.
@JamesNK has been posting about the most requested feature being the ability to start and stop services. If you have the debugger attached it will re-attach on restart š¤Æ!
Adding start/stop wasn't enough, you can expose your own commands with a little bit of C#!
Another highly requested feature was to the ability to make containers persist beyond the lifetime of the app host project. Now you can make containers persist to improve those slow startup times!
Another ability aspire gained is the ability to use an existing container. This makes it easier to incrementally adopt and interact with existing containers. Just pick the right container name and it will automatically attach!
Another blocker people hit when migrating from docker compose was the inability to use simple host names when using container to container communication. We now create a default container network when using aspire with both podman and docker. This solves many of the networking issues from aspire 8.
Where code > YAML is built reusable patterns used by your projects (and others). We have a new eventing system that allows you to subscribe to various resource events and run C# logic. Want to run code after the resource spins up, easy!
Another highly requested feature was integration with Azure functions projects. This first-class integration will make development, testing and deployment of azure functions project a breeze. @captainsafia, @codesapien and crew have been working hard on this.
A highly requested deployment feature was the ability to modify the container app resource when deploying to Azure Container Apps without dropping to bicep. Now you can use the new Azure CDK, which is integrated into Aspire's Azure resources (the syntax is not final).
There are lots more improvements and small bug fixes, including lots of UX improvements in the dashboard.
- Responsive design, you can look at the dashboard on mobile devices
- Filtering added to distributed traces and improved for structured logs.
We're just getting started! If you haven't used aspire before 9, definitely check it out then! We ship Aspire 9 .NET 9 in November.
ā¢ ā¢ ā¢
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.