Learn C# with CSharpFritz: Basics of .NET Aspire - Part 1
HTML-код
- Опубликовано: 14 май 2024
- Let's learn the basics of .NET Aspire by building a simple blog website. We'll introduce a blog application that reads from markdown files on disk and start migrating it to use .NET Aspire and its cloud stack features
Links: github.com/csharpfritz/BigBad...
Featuring: Jeff Fritz (@csharpfritz)
#csharp #aspire #cloudNative 
Наука
Impressive .. I am so happy, i haven't spend time looking into this before. This has been 2 inspiring hours. Loved it. Thank you. Looking forward to db part.
This was fantastic! Can't wait for the next episode.
Aspire looks pretty good, and I'm excited to see where it goes.
Your example is excellent if everything is in one solution, but we all know that's not how we develop. What I'd like to know is how to wire up Aspire when your frontend projects and APIs are in separate solutions.
I'll add that as part of an upcoming sample in the series. Thanks for the comment!
took me some time to implement and configure opentelemetry, redis output cache and their respective dashboards with docker-compose. aspire is on another level at orchestration, it takes little or no time to do all these things.
This is a bit of a long comment but hopefully I can get some clarity. Looking to move to .Net Aspire simply because of how it abstracts away configuration. My question is how do we handle environment configuration such as stage, uat & prod? Does .Net Aspire still need config files for each environment or can it just handle those changes. Thanks!
The deployment to those different environments can be handled with separate configuration environments using the AZD tool. If you are deploying and managing local environments, you can use the same tools you are using now, and swap in the different configuration files with configuration settings
You are modifying the Web project by adding aspire nuget packages (for example the stackexchange redis package) and by adding new code lines into the Program.cs. But these changes are only for local dev machine. In a real world example, do you commit those lines and added packages? Even if you would add the code in an if Environment.IsDevelopment branch, you will still end up deploying the aspire packages as application artefacts (bin folder), right?
FYI: This is a 'real world' example, based on my experiences building the aspireify.NET website.
Yes, you do commit the lines and the manifest that Aspire generates is used to point to the live services and containers supported by the hosting provider. I'll be sure to speak towards this in our next episode and I'll move up the CI/CD episode in the series.
I really appreciate the question, thanks!
I was mistaking when calling it “real word”. What I meant to say, is that we have existing WebApis with dedicated deployment scripts for K8s. All these deployment concerns are developed and maintained by a dedicated Platform team. We have 2 running environments until we reach PROD. In this context we do not need the generated manifests from Aspire for the deployment. Hence, the question regarding changes in existing Program.cs, new projects in the solution, etc. We only would take advance when developing locally, so we would appreciate not committing code that is intended only for local development. I am brainstorming about the advantages and disadvantages of aspire in our context. Anyways, I will continue to follow the series and maybe it will become more clearer later. Thanks for the effort you put into the videos and thanks for sharing your expertise. Very appreciated.
Are you wearing those glasses so that you are not exposed to blue light and have a better sleep at night?
I am wearing blue-blocker Gunnar glasses, and I have less headaches after working long days working at a computer screen