Real-world Aspirification experience

[willdean]

This is an account of adding Aspire to a real-world application - it's not a complaint, but there were a series of paper-cuts which it may be possible to improve, though they mostly involve stuff beyond the Aspire team. I thought I'd write it up, because the pain of these things is minor and soon-forgotten - but there are only limited opportunities to capture first-time experience.

The app I added Aspire (9.2) to is a very long-estabilshed (but not "legacy") mixed-tech (API/MVC/Razor Pages/Blazor) app. It runs on NET8.0 and uses central package versioning.

The steps go something this:

1. Create an AppHost project using dotnet new within the project - this fails (or fails to complete) because it creates a net9.0 project under a net8.0 globals.json and you cant't build that. Easy fix to edit the project file to change the target.
2. Try building it again (obviously one must not re-run dotnet new because it only half failed) - now it fails because of the central package versioning. There's only one package reference in the AppHost project, so this is a simple bit of cut-and-paste up into the central version file.
3. The app host now builds and runs and it's straightforward to add a reference to our application project.
4. Of course, the app isn't really linked to Aspire at this point, we want to add the Service Defaults project to get the otel and health checks.
5. dotnet new on the defaults project fails for the same reason as step 1
6. It then fails again for the same reason as 2 - quite a few more packages this time so much more of the fiddly cut-and-paste into the central version file - nuget really could have made that easier...
7. Now to call AddServiceDefaults(), etc, in our app to get the OTEL and health checks configured, etc. Except we can't because we have the wrong kind of startup/hostbuilder/etc. This was because when we went from 5.0 -> 6.0 the migration instructions said we didn't need to redo all that so we didn't bother and it's never mattered since.
8. So, refactor startup.cs and the host builder, etc. (Not difficult and probably worthwhile for other reasons anyway)
9. Success with Aspire!
10. But failure with the next EF migration we tried to add, because if you do step 8 wrong you break the EF tools. Do a bit more of step 8.
11. Success all around!

So this is not a failure by any means, and nothing was hard to get sorted, but it might not be the smooth experience Aspire is aiming for.
Given that you guys have some of the the loudest voices on .NET, you might be able to get the templating system improved to help with some of this. I know that the central package management issue is already tracked. The out-of-date host building problem is not really fixable other than perhaps people should be pre-warned that they can't use Aspire ServiceDefaults unless they have the right kind of host builder.

[danmoseley]

thanks @willdean ! For #1 -- you can pass framework version to dotnet new, right -- did you try that? I don't think the template machinery can look for the global json.

[willdean]

Thanks @danmoseley - I didn't know about that option, though tbh editing the csproj is probably about the same effort as looking-up the option next time I need it!

I don't know if the template machinery has any understanding of TFMs beyond simple text substitution, but I do feel like it wouldn't need to know about global.json - because dotnet.exe has alredy done the global.json stuff and selected the .net8 version of dotnet new. In my example, it was the net8.0 version of dotnet new which rendered a net9.0 csproj (that it couldn't build).