dotnet / aspire

An opinionated, cloud ready stack for building observable, production ready, distributed applications in .NET
https://learn.microsoft.com/dotnet/aspire
MIT License
3.72k stars 430 forks source link

.NET 9 packages for preview.4? #4254

Open martincostello opened 4 months ago

martincostello commented 4 months ago

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.

mitchdenny commented 4 months ago

@joperezr what was the plan here again?

joperezr commented 4 months ago

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:

  1. Create a file called rollback.txt in your project directory with the following contents:

    {
    "microsoft.net.sdk.aspire": "8.0.1/8.0.100"
    }
  2. with your 9.0 sdk, run: dotnet workload update --from-rollback-file .\rollback.txt

  3. 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.

martincostello commented 4 months ago

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.

joperezr commented 4 months ago

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.

martincostello commented 4 months ago

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:

image

martincostello commented 4 months ago

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)
joperezr commented 4 months ago

Do you happen to have a repro project that I can take a look at?

joperezr commented 4 months ago

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?

martincostello commented 4 months ago

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.

joperezr commented 4 months ago

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:

image

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

martincostello commented 4 months ago

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 👍

joperezr commented 4 months ago

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:

image

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.

joperezr commented 4 months ago

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.

martincostello commented 4 months ago

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)
codymullins commented 3 months ago

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.

mitchdenny commented 3 months ago

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.