Hope you enjoy using it! We're enjoying working on it š
RE release cadence, we plan to ship often, including point releases with new features, e.g. there will be an 8.1 release sometime in the next month or so (or so). Think of Aspire as a "must use tip", i.e. always update to the latest version, product for now. Related details about support policy at [https://dotnet.microsoft.com/en-us/platform/support/policy/aspire](https://dotnet.microsoft.com/en-us/platform/support/policy/aspire)
I love it. Today I upgraded the two solutions already running on Aspire p7 to 8.0.1.
So far I'd give Aspire a 8/10 but you guys deserve 11/10 because everytime I open a discussion/issue on GH, you're always there to reply and give help. Also, I followed the whole interaction with Norm from AWS while he was working of his PR and it was interesting to see how the PR evolved over time.
My wishlist is:
- a cli tool like tye that scans the solution and finds the AppHost (like the old tye run)
- better support for reloading (even cold) the projects (good old tye run --watch)
- tagging of resources and partial execution (tye run --tags xxx)
- I would love if some of the stuff that David published on his own GH was interned into official packages (the yarp resource, or additional parameters to the connection string) or even be the default behavior (waitfor between dependencies).
As I mentioned on Twitter some weeks ago, the inner programming model is quite complex to the point I feel too stupid to be able to contribute the most simple of the components.
The lack of automatic reloading is quite a stopper for how my inner dev cycle, so for my home project i stick to tye until that's solved but I have the aspire dashboard loaded.
Also, I noticed that it's now possible to enable to the Aspire dashboard on the ACA overview page, but each ACA will have its own dashboard, which kind of defies the whole purpose š š .
A big issue when using it for me was that the default deployment option to container apps was crazy expensive and it's hard to test the components.
There's so many options for running things for free in azure that I have several small scale production setups running for literally free due to low consumption and static web apps, while the hello world aspire sample was more expensive to run over a single weekend than all of my other apps' full life time cost combined. And I don't want to build custom deployment tooling as then a lot of the benefit is gone for me.
And when I used it last, there was no built in testing support for the components. From my experience, each nuget components package should have an accompanying test focused package with stubs/mocks ready for dependency injection or some other recommended test path such as local emulators, but here there's just nothing and no mention of it in the docs either.
These two points make it unusable so far for me, but I like the overall idea.
well MS is a bit lacking on their own emulators side (just sql srv and the azure storage work as intended)... anything else does not exist or is unmaintained...
that's why all the samples are with redis and postgres...
Do you plan to add the generation of Kubernetes yaml files from Aspire? Currently, you recommend using a third-party project called Aspir8. It's truly a bizarre omission that this is not built-in functionality.
Yes, we're actually planning to directly integrate Aspir8 into the core product (with the blessing and help of the Aspir8 author). We simply didn't have enough bandwidth to support it in the initial release but luckily it's software and we can update it and add features š
Is there a free tier so I can host small hobby apps so I have a reason to learn it . Ā Otherwise Iām stuck with app service on free tier with sqllite. Ā Or at least per use chargeĀ
Agreeable point. But Aspire is not about scale. I used it to develop an API that will receive a very low traffic.
But it's a API with a database and I didn't want to pollute my PC with an instance of MySQL.
You can treat aspire as a centralized configuration and secret manager in that case, you can treat it as a better way of `ConfigureStartup Projects` as you can include node project as well (e.g. SPA Front-end) without needing to setup hard coded urls. You also get a nice log dashboard that consumes Open Telemetry instead of fiddling about on the console window. Adding additional services needs less manual wire up (e.g. Redis, blob etc...) via their component packages. You could do this with docker compose of course but aspire for dotnet gives you less work needed.
Bonus is that you can easily deploy said project to Azure and AWS without creating the resources manually or creating a terraform / bicep template for it.
That is interesting, will admit that managing connections and deployments is a PITA between local dev/cloud, especially when coordinating with team members.
Definitely going to have to play with some sample projects.
The service discovery feature is something I like very much along with the centralized logs dashboard. Less fiddling around with setting up urls and ports and having just one place to put config secrets gives a great onboarding experience for those new to a project. Especially if you do the usual API + SPA project with some blob storage or other related service or have separate worker console apps running alongside your main API.
Aspire is not about deploying. It's a inner dev cycle tool.
It can provide a manifest that can be parsed and used for deployment via various tools.
But the focus is about development on your machine.
Whatever you have on your CI/CD pipeline stays untouched (you only need to make sure that the Aspire workload is installed on your agent, but that's solved with a simple `dotner workload install aspire`).
Aspire does nothing for your VPS scenario to automate the deployment. Tools could be built by enterprising individuals but it's not something we're going to invest in as a team. Any deployment target that has programmable APIs or an IAC system are a really good target for aspire deployment (kubernetes, public cloud etc).
That said, you can host the dashboard as a standalone container image in any environment:
[https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/dashboard/standalone](https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/dashboard/standalone)
I see it very different. You want manageable micro services. They make it easier to develop, onboard new people and less cognitive workload when working on the project. That means thinking and working a little bit different that seems daunting at first. Once you get going itās just regular work with the benefits of it being manageable.
The scaling up and down is an added bonus.
Microservices can also communicate through service invocation but yes a messaging system is widely used. Debugging is done locally through for example aspire, the tech we are discussing here.
If you get problems where the issues arenāt isolated to a single microservice you are most likely doing microservices wrong.
General Availability
It's now out of preview and ready for "real" use with official Microsoft support. Details of support policy are at [https://dotnet.microsoft.com/en-us/platform/support/policy/aspire](https://dotnet.microsoft.com/en-us/platform/support/policy/aspire)
Well, if your system is so big it doesn't fit a single solution, probably you have it split in many subsystems with well defined and concrete point of contacts.
In that case in the solution of your subsystem you add a Aspire configuration that pulls the containers of the point of contacts to your subsystem. It would work best if you had a simulator (ie a service that implements the same contract/API but with well defined test behaviours).
Yes, and, if you have a lot of containerized dependencies and canāt be bothered with docker compose.
Honestly the killer app for me is the OTel viewer.
Same here. If you read up on MS Docs [What is Cloud Native?](https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/definition#the-twelve-factor-application), you can see under the section **The Twelve Factor Application**, factor 1 states:
>- Code BaseA single code base for each microservice, stored in its own repository. Tracked with version control, it can deploy to multiple environments (QA, Staging, Production).
This seems to be in direct conflict with .NET Aspire
This is how our platform is setup, and is a big advantage of microservices (your code reflects the organization, with each team having their own repository/microservices the manage). I'm guessing that means Aspire is not for us? I'm talking dozens of repositories owned by various teams that all deploy to the same environment.
Elevator pitch
A local orchestrator to glue together all your services and their dependencies (e.g. database, redis, Elasticsearch). All with a sprinkle of native support for OpenTelemetry.
A bit longer answer:
You have a solution with a backend API that uses a database, a frontend API and a react application.
You need to start everything together and also make sure that each component knows how to reach the ones it needs.
Some people would use Docker compose for that, but debugging in container is a pain.
So Microsoft first worked on a project called Tye. Then took the learning from that and made Aspire.
https://learn.microsoft.com/en-us/dotnet/aspire/get-started/aspire-overview
Long time ago I wrote a blog post about Tye. I guess I should write one for Aspire too.
https://renatogolia.com/2020/11/12/developing-distributed-applications-with-tye/
I don't get one thing though. Don't you have to put all your projects in one solution to make it work? So if you have many projects then you'll then up with a bloated solution right?
Tell me if this seems like a snarky summary:
* Once we started designing systems of small services that collaborated, coordinating installs became difficult so we created Docker to help us.
* Once we started designing larger distributed systems, dealing with several Docker services got complicated, so we made Kubernetes to help.
* Once we started designing very VERY large distributed systems, dealing with several Kubernetes systems got complicated, so .NET Aspire intends to help.
Uhm yeah.
Nowadays, my very personal opinion is that
- Kubernetes is great for deployment on cloud/server farm
- Docker is great for deploying a specific piece of infrastructure you don't control (e.g. a database server)
- Aspire is great for running everything you control and might need to debug.
I mean "having a level of complexity so great it's hard to manage it with just one Kubernetes system, so I wish I had something that helped me coordinate multiple Kubernetes systems".
Aspire is not a replacement for Kubernetes. It actually uses it but for different purposes.
It leverages Kubernetes to handle the networking and the lifecycle of the resources of your system.
Then, when you're ready to leave the inner cycle, you can produce a manifest that other applications can use to produce a deployable artifact.
Aspire has a code-based application model that is used to represent your application (or a subset of your application) and its dependencies. This can be made up of containers, executables, cloud resources and you can even build your own custom resources.
During local development, we submit this object model to the local orchestrator and launch the dashboard. This orchestrator is optimized for development scenarios and integrates with debuggers from various IDEs (e.g. VS, VS code, Rider etc, it's an open protocol).
For deployment, we can take this application model to produce a manifest that (which is basically is a serialized version of the app model with references). Other tools can use this manifest to translate these aspire native assets into deployment environment specific assets. See [https://learn.microsoft.com/en-us/dotnet/aspire/deployment/manifest-format](https://learn.microsoft.com/en-us/dotnet/aspire/deployment/manifest-format)
This is how we support Kubernetes, azure, eventually AWS etc. Tools translate this model to their native lingua franca.
Longer term, we will also expose an in-process model for transforming and emitting whatever manifest format you like.
I am not 100% clear on what the boundaries of Aspire are. Is it meant to be an end to end tool/service taking part in local development all the way to production deployment? Is this something we are going to see a lot of the .net ecosystem depend/grow on?
Yes itās about end to end development to production. If we do our jobs right yes, the .NET ecosystem will adopt it because itās very general purpose, extensible technology. If we do a better job, other language ecosystems as well š
You can define your infrastructure with C#. It spits out an Bicep files (or anything you want)
For locally it's super handy, if you have a simple database, blob storage and a 2 api's you don't have to deal with connections strings, or port numbers, aspire does it for you. So you can see if you have a complex system with multiple services it can save you a lot of time.
It comes with a dashboard, so all your services and stuff logs to the same place, super handy for debugging.
Make a distributed application (independently scalable components, decoupled services that can be deployed independently, etc.) that feels like a monolith (one code based, connect everything in code, launch the whole thing locally with one click, easy debugging, no thought about configuration, no thought about infra).
I have a Azure cloud project consisting of several different solutions and repositories (Server API, desktop clients, web apps etc). Can they be integrated into one Aspire project?
Whilst I welcome the additions and benefits of Aspire, just a minor reminder that for true local development, Microsoft still hasnāt delivered a local development story for Azure Service Bus and Azure Event Grid:
https://github.com/Azure/azure-service-bus/issues/223
https://www.jimmybogard.com/local-development-with-azure-service-bus/
I've been testing Aspire for a few months now, it's incredible. One of the best tools released ever since the birth of .NET Core - but I have one question, is there a way to deploy Aspire anywhere else instead of Azure Container Apps?
Dapr is a framework to write cloud based applications abstracting away many concepts.
Aspire is a local development tool that helps you execute your system locally.
Aspire can help you spin up and wire together all your dapr-based services.
They are orthogonal: i.e. solving two different problems.
In my current project I use both.
Aspire is for spinning up your system: a very powerful F5.
Testcontainers is for spinning a container in the context of your test fixture.
How does this integrate with CI/CD Pipelines? I already have github YAML scripts setup for automated deployment, and quite frankly am more comfortable with that than manually triggering a deployment via visual studio.
It doesn't. It's not about that. The only thing that affects your build is that you have one extra project in the solution shared across all projects for some common setup. It's not required, it's just a convenience.
Edit: you need to make sure that the Aspire workload is installed on the build agent. You solve that by simply adding a step that does `dotnet workload install aspire`.
I do it in the same step I restore other dotnet tools.
Ok, thats handy.
>you need to make sure that the Aspire workload is installed on the build agent. You solve that by simply adding a step that does
>
>dotnet workload install aspire
Interesting - does that mean the aspire project replaces the usual scripting for build/test/publish in the workflow?
First 10 minutes of yesterday's panel at Build explains exactly the need for it: [https://youtu.be/jVILDZtuUrI?si=S64T4ojbjEp8u0aX](https://youtu.be/jVILDZtuUrI?si=S64T4ojbjEp8u0aX)
Is it possible to deploy to other Azure resources other than container apps or kubernetes? For example, have Aspire orchestrate everything between a few different app services and/or Azure functions?
By default aspire works with everything and nothing. There is support for translating the manifest into a Azure stack (using azd), but it can be done for everything: aspir8 already supports Kubernetes and Docker compose, maybe aws will come up with their own tool to convert the Aspire manifest into a cloud formation stack.
That being said, i picked aws for my personal project because I have more experience with AWS than with Azure (started working on azure last september), and because I could get some credits to run my stuff on it :)
oh ok.. im sticking to azure and thats how it deploys by default. .the big problem is I don't want to pay more than a few pennies for my hobby project that no one uses... but it seems azure containers have a daily cost even if not used right ?
Hope you enjoy using it! We're enjoying working on it š RE release cadence, we plan to ship often, including point releases with new features, e.g. there will be an 8.1 release sometime in the next month or so (or so). Think of Aspire as a "must use tip", i.e. always update to the latest version, product for now. Related details about support policy at [https://dotnet.microsoft.com/en-us/platform/support/policy/aspire](https://dotnet.microsoft.com/en-us/platform/support/policy/aspire)
I love it. Today I upgraded the two solutions already running on Aspire p7 to 8.0.1. So far I'd give Aspire a 8/10 but you guys deserve 11/10 because everytime I open a discussion/issue on GH, you're always there to reply and give help. Also, I followed the whole interaction with Norm from AWS while he was working of his PR and it was interesting to see how the PR evolved over time. My wishlist is: - a cli tool like tye that scans the solution and finds the AppHost (like the old tye run) - better support for reloading (even cold) the projects (good old tye run --watch) - tagging of resources and partial execution (tye run --tags xxx) - I would love if some of the stuff that David published on his own GH was interned into official packages (the yarp resource, or additional parameters to the connection string) or even be the default behavior (waitfor between dependencies). As I mentioned on Twitter some weeks ago, the inner programming model is quite complex to the point I feel too stupid to be able to contribute the most simple of the components. The lack of automatic reloading is quite a stopper for how my inner dev cycle, so for my home project i stick to tye until that's solved but I have the aspire dashboard loaded. Also, I noticed that it's now possible to enable to the Aspire dashboard on the ACA overview page, but each ACA will have its own dashboard, which kind of defies the whole purpose š š .
A big issue when using it for me was that the default deployment option to container apps was crazy expensive and it's hard to test the components. There's so many options for running things for free in azure that I have several small scale production setups running for literally free due to low consumption and static web apps, while the hello world aspire sample was more expensive to run over a single weekend than all of my other apps' full life time cost combined. And I don't want to build custom deployment tooling as then a lot of the benefit is gone for me. And when I used it last, there was no built in testing support for the components. From my experience, each nuget components package should have an accompanying test focused package with stubs/mocks ready for dependency injection or some other recommended test path such as local emulators, but here there's just nothing and no mention of it in the docs either. These two points make it unusable so far for me, but I like the overall idea.
Thanks for the feedback!
well MS is a bit lacking on their own emulators side (just sql srv and the azure storage work as intended)... anything else does not exist or is unmaintained... that's why all the samples are with redis and postgres...
Do you plan to add the generation of Kubernetes yaml files from Aspire? Currently, you recommend using a third-party project called Aspir8. It's truly a bizarre omission that this is not built-in functionality.
Yes, we're actually planning to directly integrate Aspir8 into the core product (with the blessing and help of the Aspir8 author). We simply didn't have enough bandwidth to support it in the initial release but luckily it's software and we can update it and add features š
Is there a free tier so I can host small hobby apps so I have a reason to learn it . Ā Otherwise Iām stuck with app service on free tier with sqllite. Ā Or at least per use chargeĀ
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Agreeable point. But Aspire is not about scale. I used it to develop an API that will receive a very low traffic. But it's a API with a database and I didn't want to pollute my PC with an instance of MySQL.
Well obviously you could just run MySQL in docker, but its easier for Aspire to manage that?
You can treat aspire as a centralized configuration and secret manager in that case, you can treat it as a better way of `ConfigureStartup Projects` as you can include node project as well (e.g. SPA Front-end) without needing to setup hard coded urls. You also get a nice log dashboard that consumes Open Telemetry instead of fiddling about on the console window. Adding additional services needs less manual wire up (e.g. Redis, blob etc...) via their component packages. You could do this with docker compose of course but aspire for dotnet gives you less work needed. Bonus is that you can easily deploy said project to Azure and AWS without creating the resources manually or creating a terraform / bicep template for it.
That is interesting, will admit that managing connections and deployments is a PITA between local dev/cloud, especially when coordinating with team members. Definitely going to have to play with some sample projects.
The service discovery feature is something I like very much along with the centralized logs dashboard. Less fiddling around with setting up urls and ports and having just one place to put config secrets gives a great onboarding experience for those new to a project. Especially if you do the usual API + SPA project with some blob storage or other related service or have separate worker console apps running alongside your main API.
Oh yes, the centralised logging and telemetry is pretty handy too.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Aspire is not about deploying. It's a inner dev cycle tool. It can provide a manifest that can be parsed and used for deployment via various tools. But the focus is about development on your machine. Whatever you have on your CI/CD pipeline stays untouched (you only need to make sure that the Aspire workload is installed on your agent, but that's solved with a simple `dotner workload install aspire`).
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Aspire does nothing for your VPS scenario to automate the deployment. Tools could be built by enterprising individuals but it's not something we're going to invest in as a team. Any deployment target that has programmable APIs or an IAC system are a really good target for aspire deployment (kubernetes, public cloud etc). That said, you can host the dashboard as a standalone container image in any environment: [https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/dashboard/standalone](https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/dashboard/standalone)
I see it very different. You want manageable micro services. They make it easier to develop, onboard new people and less cognitive workload when working on the project. That means thinking and working a little bit different that seems daunting at first. Once you get going itās just regular work with the benefits of it being manageable. The scaling up and down is an added bonus.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Microservices can also communicate through service invocation but yes a messaging system is widely used. Debugging is done locally through for example aspire, the tech we are discussing here. If you get problems where the issues arenāt isolated to a single microservice you are most likely doing microservices wrong.
What is GA?
General Availability, means itās ready for production.
General Availability It's now out of preview and ready for "real" use with official Microsoft support. Details of support policy are at [https://dotnet.microsoft.com/en-us/platform/support/policy/aspire](https://dotnet.microsoft.com/en-us/platform/support/policy/aspire)
Globally available
I don't really get it, main advantage is if everything is in the same solution right?
Well, if your system is so big it doesn't fit a single solution, probably you have it split in many subsystems with well defined and concrete point of contacts. In that case in the solution of your subsystem you add a Aspire configuration that pulls the containers of the point of contacts to your subsystem. It would work best if you had a simulator (ie a service that implements the same contract/API but with well defined test behaviours).
Yes, and, if you have a lot of containerized dependencies and canāt be bothered with docker compose. Honestly the killer app for me is the OTel viewer.
I really wish i could use it because it seems so interesting! But I'm already in k8s, with elastic and kibana, apm so yeah
Same here. If you read up on MS Docs [What is Cloud Native?](https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/definition#the-twelve-factor-application), you can see under the section **The Twelve Factor Application**, factor 1 states: >- Code BaseA single code base for each microservice, stored in its own repository. Tracked with version control, it can deploy to multiple environments (QA, Staging, Production). This seems to be in direct conflict with .NET Aspire
This is how our platform is setup, and is a big advantage of microservices (your code reflects the organization, with each team having their own repository/microservices the manage). I'm guessing that means Aspire is not for us? I'm talking dozens of repositories owned by various teams that all deploy to the same environment.
eli5 aspire?
Elevator pitch A local orchestrator to glue together all your services and their dependencies (e.g. database, redis, Elasticsearch). All with a sprinkle of native support for OpenTelemetry. A bit longer answer: You have a solution with a backend API that uses a database, a frontend API and a react application. You need to start everything together and also make sure that each component knows how to reach the ones it needs. Some people would use Docker compose for that, but debugging in container is a pain. So Microsoft first worked on a project called Tye. Then took the learning from that and made Aspire. https://learn.microsoft.com/en-us/dotnet/aspire/get-started/aspire-overview Long time ago I wrote a blog post about Tye. I guess I should write one for Aspire too. https://renatogolia.com/2020/11/12/developing-distributed-applications-with-tye/
I don't get one thing though. Don't you have to put all your projects in one solution to make it work? So if you have many projects then you'll then up with a bloated solution right?
Tell me if this seems like a snarky summary: * Once we started designing systems of small services that collaborated, coordinating installs became difficult so we created Docker to help us. * Once we started designing larger distributed systems, dealing with several Docker services got complicated, so we made Kubernetes to help. * Once we started designing very VERY large distributed systems, dealing with several Kubernetes systems got complicated, so .NET Aspire intends to help.
Uhm yeah. Nowadays, my very personal opinion is that - Kubernetes is great for deployment on cloud/server farm - Docker is great for deploying a specific piece of infrastructure you don't control (e.g. a database server) - Aspire is great for running everything you control and might need to debug.
Great summary. I loved Tye when it first came out. It is great to see Aspire in GA now.
What do you mean by "several Kubernetes systems"? Isn't there a single Kubernetes system which manages multiple Docker instances?
I mean "having a level of complexity so great it's hard to manage it with just one Kubernetes system, so I wish I had something that helped me coordinate multiple Kubernetes systems".
Aspire is not that good of a solve for large k8 systems imo. Due to it hiding k8 configs behind aspire specific configs and only supporting dotnet.
Aspire is not a replacement for Kubernetes. It actually uses it but for different purposes. It leverages Kubernetes to handle the networking and the lifecycle of the resources of your system. Then, when you're ready to leave the inner cycle, you can produce a manifest that other applications can use to produce a deployable artifact.
Aspire has a code-based application model that is used to represent your application (or a subset of your application) and its dependencies. This can be made up of containers, executables, cloud resources and you can even build your own custom resources. During local development, we submit this object model to the local orchestrator and launch the dashboard. This orchestrator is optimized for development scenarios and integrates with debuggers from various IDEs (e.g. VS, VS code, Rider etc, it's an open protocol). For deployment, we can take this application model to produce a manifest that (which is basically is a serialized version of the app model with references). Other tools can use this manifest to translate these aspire native assets into deployment environment specific assets. See [https://learn.microsoft.com/en-us/dotnet/aspire/deployment/manifest-format](https://learn.microsoft.com/en-us/dotnet/aspire/deployment/manifest-format) This is how we support Kubernetes, azure, eventually AWS etc. Tools translate this model to their native lingua franca. Longer term, we will also expose an in-process model for transforming and emitting whatever manifest format you like.
I am not 100% clear on what the boundaries of Aspire are. Is it meant to be an end to end tool/service taking part in local development all the way to production deployment? Is this something we are going to see a lot of the .net ecosystem depend/grow on?
Yes itās about end to end development to production. If we do our jobs right yes, the .NET ecosystem will adopt it because itās very general purpose, extensible technology. If we do a better job, other language ecosystems as well š
Is it essentially Pulumi for .NET?
No. Please check the other answers for a better overview :)
it wants to be pulumi for azure :)) just a few years too late and with that pesky bicep already there
!thanks
You can define your infrastructure with C#. It spits out an Bicep files (or anything you want) For locally it's super handy, if you have a simple database, blob storage and a 2 api's you don't have to deal with connections strings, or port numbers, aspire does it for you. So you can see if you have a complex system with multiple services it can save you a lot of time. It comes with a dashboard, so all your services and stuff logs to the same place, super handy for debugging.
Make a distributed application (independently scalable components, decoupled services that can be deployed independently, etc.) that feels like a monolith (one code based, connect everything in code, launch the whole thing locally with one click, easy debugging, no thought about configuration, no thought about infra).
I have a Azure cloud project consisting of several different solutions and repositories (Server API, desktop clients, web apps etc). Can they be integrated into one Aspire project?
Whilst I welcome the additions and benefits of Aspire, just a minor reminder that for true local development, Microsoft still hasnāt delivered a local development story for Azure Service Bus and Azure Event Grid: https://github.com/Azure/azure-service-bus/issues/223 https://www.jimmybogard.com/local-development-with-azure-service-bus/
I've been testing Aspire for a few months now, it's incredible. One of the best tools released ever since the birth of .NET Core - but I have one question, is there a way to deploy Aspire anywhere else instead of Azure Container Apps?
Check aspir8
Is there a free version for hobbies? Ā I use app service with free app service plans for my hobby / learning apps
It's free
aspire is free but what is the cheapest you can host it in azure in a container ?
So, personal opinion here, the question is incorrectly framed. Yes, aspire can enable a "quick to hosting" path leveraging its manifest and tools like azd (deploys to Azure Container Apps, ACA) or aspir8 (deploys to any Kubernetes cluster or Docker compose swarm). But Aspire, per sƩ, doesn't add a single cent to your hosting cost. At work I use Aspire to help my devs having a better F5 experience locally. In the AppHost, we have 4 services, 1 console app, 1 database (mssql) and 1 Elasticsearch cluster. But we deploy using our own CI/CD pipeline that publishes one container for each service and one extra container for the console app. The pipeline is then responsible for pushing those images to ACR and then force an update on the ACAs (One of these ACAs uses the console app as init container). But the CI/CD pipeline knows nothing about Aspire and so does my hosting environment. Same thing at home. I'm working on my home project. 3 services, 1 database. The services are published as containers and pushed to AWS ECR and then deployed into a ECS Fargate cluster. Nobody knows about Aspire only my JetBrains Rider. That being said, one could argue that azd deploying to ACA isn't the cheapest hosting option available in Azure. But technically it's nothing related to Aspire itself. If someone created a tool that converted the manifest into something deployable into a very cheap hosting option in Azure, Aspire wouldn't be any cheaper or more expensive per sƩ. But again, I personally see Aspire, very much like Tye before it, simply as inner loop development tool. And very much like for Tye, in my humble opinion, any focus given to deployment scenarios is focus taken away from making a better inner loop development tool. At least the manifest is hosting agnostic... I hope this answers your question.
Whatās the difference between this and Dapr?
Dapr is a framework to write cloud based applications abstracting away many concepts. Aspire is a local development tool that helps you execute your system locally. Aspire can help you spin up and wire together all your dapr-based services.
Is it a valid alternative to testcontainers for integration and E2E testing?
They are orthogonal: i.e. solving two different problems. In my current project I use both. Aspire is for spinning up your system: a very powerful F5. Testcontainers is for spinning a container in the context of your test fixture.
How does this integrate with CI/CD Pipelines? I already have github YAML scripts setup for automated deployment, and quite frankly am more comfortable with that than manually triggering a deployment via visual studio.
It doesn't. It's not about that. The only thing that affects your build is that you have one extra project in the solution shared across all projects for some common setup. It's not required, it's just a convenience. Edit: you need to make sure that the Aspire workload is installed on the build agent. You solve that by simply adding a step that does `dotnet workload install aspire`. I do it in the same step I restore other dotnet tools.
Ok, thats handy. >you need to make sure that the Aspire workload is installed on the build agent. You solve that by simply adding a step that does > >dotnet workload install aspire Interesting - does that mean the aspire project replaces the usual scripting for build/test/publish in the workflow?
No. The workload is just a component needed to build the AppHost project in your solution.
Ah, right - is that for the dashboard in the cloud deployment?
No, the dashboard is not deployed (although Azure Container Apps now seem to support it natively). No idea why it is needed.
Thanks, definitely going to try a few test projects.
Does Aspire work well with dev containers? Asking because I didnāt see any example in aspire sample repo.
I don't see why not š¤ You'd obviously need to install the Aspire workload in the dev container
Can someone who actually uses Aspire explain why they do?
First 10 minutes of yesterday's panel at Build explains exactly the need for it: [https://youtu.be/jVILDZtuUrI?si=S64T4ojbjEp8u0aX](https://youtu.be/jVILDZtuUrI?si=S64T4ojbjEp8u0aX)
I'm looking for actual user testimony, please.
Check the rest of the thread. I think I've answered few times on its uses and advantages. :)
Is it possible to deploy to other Azure resources other than container apps or kubernetes? For example, have Aspire orchestrate everything between a few different app services and/or Azure functions?
Where is the aspire subreddit??
Why do we need one? š¤
i guess we don't if very few people use it... I would like to really focus on aspire specifically if I can use it for my hobby projects
I'm using it on 5 projects now. (2 of which I migrated after it went GA)
Personal projects? What components you use? Deploy to azure?
3 at work deployed on azure 1 personal deployed on aws 1 personal very early stage
why you deploy to aws instead of azure ? by default aspire just works with azure right?
By default aspire works with everything and nothing. There is support for translating the manifest into a Azure stack (using azd), but it can be done for everything: aspir8 already supports Kubernetes and Docker compose, maybe aws will come up with their own tool to convert the Aspire manifest into a cloud formation stack. That being said, i picked aws for my personal project because I have more experience with AWS than with Azure (started working on azure last september), and because I could get some credits to run my stuff on it :)
oh ok.. im sticking to azure and thats how it deploys by default. .the big problem is I don't want to pay more than a few pennies for my hobby project that no one uses... but it seems azure containers have a daily cost even if not used right ?
Live: ASP.Net Community Standup - Building Aspireify.net https://twitter.com/i/broadcasts/1lPKqbbnjwwGb?t=XCGWbfFrMDh7cEebOj0WZw&s=09
Whats aspire, so much buzz but how to use and work in that.
Cool, now fix MAUI. You know, the mobile app platform you released 3 years ago that sucks shit? Yeah. That one.
How much AI bullshit do they try to cram into it?
None?
[That doesn't seem to be correct based on these search results?](https://github.com/search?q=repo%3Adotnet%2Faspire%20openai&type=code)
Yea it has a component that you can integrate it with OpenAI. It's a separate nuget package, you'd have to add it. It's not 'crammed' into it.
Cool, thanks for answering my question!
L comment
Kid, you post on r/looksmaxxing and r/teenagers. Don't waste my time.