Open martincostello opened 4 months ago
@joperezr what was the plan here again?
Hey @martincostello, thanks for raising this question. The TL;DR is that we won't be shipping 9.0 previews of Aspire going forward, but you can use 8.0 Aspire in 9.0 SDKs and build 9.0 services that work with Aspire.
The long answer is this: After some discussion, we realized that for several reasons it would be best to only have one "train" for Aspire, as opposed to having both the 8.0 and 9.0 branches to maintain. The most important reason is that Aspire itself ships different than the rest of .NET; We plan on shipping a new version roughly every month, which unlike .NET Servicing, will include new features. For .NET new features are usually just shipping once a year, as opposed to once a month. Because we ship every month, then we will expect most customers to be in that latest build, so there is less incentives to also have a separate train exclusively for 9.0. Another reason is that because most of our focus was (and is) on the next monthly version we are shipping, then we weren't doing enough validation in the 9.0 train which had led to bugs only present in 9.0 previews, and we want to hold ourselves to great quality standards. Finally, having Aspire target 8.0 does not prevent users that already have the 9.0 SDK to write their Aspire services targeting 9.0. This means, you can have Aspire 8.0 installed in your 9.0 SDK, and create an Aspire project that has 9.0 services and that should just work.
Given all of the points above, we decided to stop shipping 9.0 Aspire previews. I the next 9.0 SDK Preview release, you'll see that the version of Aspire that comes inserted will change from 9.0 preview 3 (which is what it currently has) to our latest 8.0 Aspire instead. In the meantime, you can "force" Aspire 8.0 into your 9.0 SDK by following these steps:
Create a file called rollback.txt in your project directory with the following contents:
{
"microsoft.net.sdk.aspire": "8.0.1/8.0.100"
}
with your 9.0 sdk, run: dotnet workload update --from-rollback-file .\rollback.txt
Then run: dotnet workload install aspire --from-rollback-file .\rollback.txt
That should make it so that your 9.0 SDK is now using the 8.01 (latest) version of Aspire. From there, you should be able to create new Aspire projects, and while the individual services will be targeting net8.0, you should be able to update their target frameworks to instead use net9.0 and this should just work.
Let us know if you have any questions/comments/concerns with any of the above.
Thanks - with an earlier preview I had a either (or both) of:
I'll try this out tomorrow with the stable 8.0.x aspire packages with the rest of the solution with 9.0 preview 4 bits and see how I get on.
I wouldn't expect you to hit any of those issues, so if you do, definitely don't hesitate to reach out so we can help you get unblocked. The AppHost can target net8.0 and have services target 9.0, because in the AppHost our projectReferences are treated "specially". Meaning from our AppHost project, we don't really need to fully reference the services it manages, but instead we just need to know where the final executable is located so we can build the project and run it.
In the case where I have the AppHost targeting net8.0 I get this error restoring the workloads:
alexa-london-travel-site on stable-aspire [$] via .NET v9.0.100-preview.4.24267.66
❯ dotnet workload restore
__________________________________________________
Project "C:\Coding\martincostello\alexa-london-travel-site\src\LondonTravel.Site.AppHost\LondonTravel.Site.AppHost.csproj" (_GetRequiredWorkloads target(s)):
C:\Program Files\dotnet\sdk\9.0.100-preview.4.24267.66\Microsoft.Common.CurrentVersion.targets(1879,5): error : Project '..\LondonTravel.Site\LondonTravel.Site.csproj' targets 'net9.0'. It cannot be referenced by a project that targets '.NETCoreApp,Version=v8.0'.
Done building project "LondonTravel.Site.AppHost.csproj" -- FAILED.
Failed to restore workload for project C:\Coding\martincostello\alexa-london-travel-site\src\LondonTravel.Site.AppHost\LondonTravel.Site.AppHost.csproj: Failed to run MSBuild Target _GetRequiredWorkloads.
Things build if I target net9.0 in the AppHost, but then I just get these errors when I start it:
If I do the rollback file steps too, then I get this on F5:
fail: Microsoft.Extensions.Hosting.Internal.Host[11]
Hosting failed to start
System.IO.FileNotFoundException: The Aspire orchestration component is not installed at "C:\Program Files\dotnet\packs\Aspire.Hosting.Orchestration.win-x64\9.0.0-preview.3.24210.17\tools\dcp.exe". The application cannot be run without it.
File name: 'C:\Program Files\dotnet\packs\Aspire.Hosting.Orchestration.win-x64\9.0.0-preview.3.24210.17\tools\dcp.exe'
at Aspire.Hosting.Dcp.DcpDependencyCheck.GetDcpInfoAsync(CancellationToken cancellationToken) in /_/src/Aspire.Hosting/Dcp/DcpDependencyCheck.cs:line 50
at Aspire.Hosting.Dcp.DcpHostService.StartAsync(CancellationToken cancellationToken) in /_/src/Aspire.Hosting/Dcp/DcpHostService.cs:line 67
at Microsoft.Extensions.Hosting.Internal.Host.<StartAsync>b__14_1(IHostedService service, CancellationToken token)
at Microsoft.Extensions.Hosting.Internal.Host.ForeachService[T](IEnumerable`1 services, CancellationToken token, Boolean concurrent, Boolean abortOnFirstException, List`1 exceptions, Func`3 operation)
Do you happen to have a repro project that I can take a look at?
I'm assuming you also changed the references to Aspire related packages to use the 8.0.0 versions as opposed to the 9.0 packages?
Does this repro if you don't go through VS but instead do it via the command line? If so, can you please share your dotnet --info
output so we can take a look?
This is the commit where I rolled back to 8.0.1: https://github.com/martincostello/alexa-london-travel-site/pull/2177/commits/9779aba3d902dc732408e0c48e9f02c35e3724da
I didn't try with the command line I was just using VS, but I can try it out tomorrow.
I just tried this out locally by building and running your dotnet-vnext branch with an SDK that has 8.0.1 of Aspire installed. Things seem to be working just fine for me from the CLI:
From your error log, it seems like you probably didn't fully clean rebuild from VS after installing 8.0 Aspire in the 9.0 SDK
Ok, thanks for looking. I'll try flushing stuff out again tomorrow, but I imagine it's probably working fine and you can close this out 👍
No worries, let's keep it open until you validate that it is working as expected :). For some additional context of what I think it is happening, when Aspire builds your AppHost project, it adds some assembly attributes with locations for where to find things used for launching your app, like the aspire dashboard as well as the location of DCP like you can see here:
The error you are getting suggests that the paths in the attributes used for your app are still pointing to dcp.exe for 9.0 preview 3 workload, but those can't be found after you changed the installation to instead use the 8.0.1 workload. I would expect rebuilding the AppHost with the 8.0.1 workload should fix those paths and get you back into a working state.
Oh, and one thing I forgot to mention, in order for the dashboard to work, you'll want to have the AppHost project still target net8.0 (the rest of the projects can continue to be net9.0)
Or, more accurately, not needed for you to target net9.0 specifically but you will need to have the aspnetcore 8.0.0 runtime installed, as the dashboard executable is targeting 8.0 so it won't work if you don't have that installed.
Yep, that was it - I nuked my artifacts
folder and rebuilt and it worked.
Unrelated, but am I correct in thinking that in Visual Studio, if Docker isn't running when you F5, it's supposed to start it for you? I'm sure that it used to do that, but this morning I got this exception instead (with VS 17.11.0 Preview 1):
Aspire.Hosting.DistributedApplicationException: Container runtime 'docker' was found but appears to be unhealthy. The error from the container runtime check was error during connect: this error may indicate that the docker daemon is not running: Get "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.45/containers/json?limit=1": open //./pipe/docker_engine: The system cannot find the file specified..
at Aspire.Hosting.Dcp.DcpDependencyCheck.EnsureDcpContainerRuntime(DcpInfo dcpInfo) in /_/src/Aspire.Hosting/Dcp/DcpDependencyCheck.cs:line 199
at Aspire.Hosting.Dcp.DcpDependencyCheck.GetDcpInfoAsync(CancellationToken cancellationToken) in /_/src/Aspire.Hosting/Dcp/DcpDependencyCheck.cs:line 99
at Aspire.Hosting.Dcp.DcpDependencyCheck.GetDcpInfoAsync(CancellationToken cancellationToken) in /_/src/Aspire.Hosting/Dcp/DcpDependencyCheck.cs:line 115
at Aspire.Hosting.Dcp.DcpHostService.StartAsync(CancellationToken cancellationToken) in /_/src/Aspire.Hosting/Dcp/DcpHostService.cs:line 67
at Microsoft.Extensions.Hosting.Internal.Host.<StartAsync>b__14_1(IHostedService service, CancellationToken token)
at Microsoft.Extensions.Hosting.Internal.Host.ForeachService[T](IEnumerable`1 services, CancellationToken token, Boolean concurrent, Boolean abortOnFirstException, List`1 exceptions, Func`3 operation)
Not sure if this is the right place to ask.
Some components I'm using have breaking changes (port
--> containerPort
for example) and I'd like to submit some PRs to fix them, but I'm not sure how to test these locally. e.g., Seq.AppHost
targets net8.0, but I'm not entirely sure how to "switch" to the net9 configuration. Any guidance is appreciated.
At the moment don't use the 9.0 packages for Aspire. As some point closer to .NET 9.0 GA we'll start producing 9.0 previews again which will be based on the 8.0 version of the API.
Are there plans to re-publish some "official" NuGet preview packages for .NET Aspire that are compatible with .NET 9 preview 4?
(Sorry to be That Guy™️ 😄)
I'm testing a number of apps with .NET 9 where the version in main with .NET 8 now uses Aspire, and I'm having to stick with the unpublished .NET 9 preview.3 packages in my .NET 9 branches to keep them compiling, and in some cases comment-out code as the breaking API changes made for CosmosDB are missing for .NET 9 comparing 8.0.0/8.0.1 to what was in 9.0.0-preview.3.