When you’re angry, take a breath, take your time and then talk. So I did after I tested .NET Aspire yesteday. I hoped it could be a decent tool for local development with a decent synergy to Marten and Wolverine. Unfortunately, I think that Aspire is not even usable for local development. Unless you go full Windows + Visual Studio. The setup is overcomplicated. You need to add two additional projects, one for the host and the other for “defaults”. You need to have all projects in a single solution. And reference all startup projects to the .NET Aspire Host (or provide the relative paths to them). Ah, and add default project to all of them. That could be fine for a small monolithic solution but unrealistic for a bigger system. Plus, cherry on top: I didn’t manage to configure the local environment on Ubuntu after spending a few hours on it. Aspire tries reinventing the wheel instead of adapting to existing standard tools like Kubernetes. They came up with their own Control Plane, which you cannot just use by adding a NuGet package or running a Docker image. Nope, you need to install that on your local dev with “dotnet workload install”. Yes, there’s such a command. I don’t see myself as a total noob, but rather as an “average Joe”, but I didn’t manage to properly install Aspire tooling on my PopOS (Ubuntu-based) distro. Some may say that I just don’t know how to use it properly, but if that’s true, then that’s also true for most devs. Anthony Simmon made a great job investigating and describing how bizarrely Microsoft Developer Control Plane works internally. Martin Thwaites experimented and created the NuGet package that self-hosts .NET Aspire Dashboard. Which is how it should be done since the beginning. Yet, it’s unknown if .NET team will take this direction. If they don’t, we all know how using frameworks in unintended way always ends up. Of course, I could try it on my Windows machine, but if the DevOps tool doesn’t work easily on non-Windows boxes, that speaks a lot. It means that it’s not production-ready. I could probably spend more time trying to hack it, but then I’d need to consider how to make it repeatable on other people’s machines, automated setup in CI/CD, etc. That’s the opposite of what I’d expect from such a tool. Documentation is far from great, and the only way to troubleshoot is to try to skim through the source code, and hey, only part of it is open; the rest is closed. I wasn’t a fan of Tye project, whose successor is Aspire. For me, it was too bold to try to replace already established and working standards with something else. Unsurprisingly, it failed. And no, it wasn’t an experiment as it’s pictured now. I remembered how it was presented, the same way as Aspire now. It seems that the .NET team took some lessons but made similar general mistakes. Unfortunately, it looks like a demoware and project detached from the current development standards. I still have some (but small) hope that the .NET team will learn from the feedback and change it. Still, based on the current state, it would need to change fu
