Move dotnet-helix-service to .NET 8

[chcosta]

Moving this to its own issue from https://github.com/dotnet/dnceng/issues/1430

dotnet-helix-service cannot move to .NET 8 because it deploys to Service Fabric which does not yet provide a .NET 8 runtime.

Service fabric supported versions are listed here

ETA for .NET 8 support is June.

Related to this effort is https://github.com/dotnet/dnceng/issues/2412

Migration to .NET 8 was started, see this commit.

Sample build from the migration changes (the build times out during the deploy to Service Fabric step because of the lack of .NET 8 support) - https://dev.azure.com/dnceng/internal/_build/results?buildId=2418661&view=results

[AlitzelMendez]

@chcosta the deployment to SF could be failing for other reasons, when this is run manually (as it was the build that you shared) the upgrade policy is different (it is the same as when we deploy in production) and it makes really hard to deploy in staging.

For example, the upgrade domain timeout is 11 minutes, and all the application should be healthy, all that is defined here: https://dev.azure.com/dnceng/internal/_git/dotnet-helix-service?path=/eng/deployment/app.bicep&version=GBmain&line=29&lineEnd=30&lineStartColumn=1&lineEndColumn=1&lineStyle=plain&_a=contents

so if we need to test this is staging we need to make sure that we are not monitoredUpgrade

[chcosta]

@AlitzelMendez ,appreciate you, I'll take another look

[chcosta]

Ali was right about why deployment was failing. After temporarily changing the 'monitoredUpgrade' parameter of the deploymentParameters to $false for validation purposes (and retrying a few test failures), we now have a passing helix validation build.

https://dev.azure.com/dnceng/internal/_build/results?buildId=2420208&view=results

However, further validation (from Ali) shows that we do indeed have heavy reliance on the .NET runtime in the apps we run on service fabric and those will fail.

I am leaving my dev branch available for when SF supports .NET 8 runtime - chcosta/move-to-net8-nocg

[markwilkie]

Is there a timeframe that SF says they'll support .NET 8?

---

From: Christopher Costa @.> Sent: Tuesday, April 2, 2024 2:39 PM To: dotnet/dnceng @.> Cc: Subscribed @.***> Subject: Re: [dotnet/dnceng] Move dotnet-helix-service to .NET 8 (Issue #2413)

Ali was right about why deployment was failing. After temporarily changing the 'monitoredUpgrade' parameter of the deploymentParametershttps://dev.azure.com/dnceng/internal/_git/dotnet-helix-service?path=/eng/deployment/deploy.ps1&version=GBmain&line=81&lineEnd=82&lineStartColumn=1&lineEndColumn=1&lineStyle=plain&_a=contents to $false for validation purposes (and retrying a few test failures), we now have a passing helix validation build.

https://dev.azure.com/dnceng/internal/_build/results?buildId=2420208&view=results

However, further validation (from Ali) shows that we do indeed have heavy reliance on the .NET runtime in the apps we run on service fabric and those will fail.

I am leaving my dev branch available for when SF supports .NET 8 runtime - chcosta/move-to-net8-nocghttps://dev.azure.com/dnceng/internal/_git/dotnet-helix-service?version=GBchcosta/move-to-net8-nocg

— Reply to this email directly, view it on GitHubhttps://github.com/dotnet/dnceng/issues/2413#issuecomment-2033144142, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABQKTJKG4TRI5WIWYDGFILTY3MQRTAVCNFSM6AAAAABFRZ4SJ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZTGE2DIMJUGI. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[riarenas]

https://github.com/microsoft/service-fabric/issues/1472 says they are targeting April

https://github.com/microsoft/service-fabric/issues/1472#issuecomment-2016046408 says they are not very optimistic about landing it by April.

[riarenas]

Here's the internal workitem: https://dev.azure.com/msazure/One/_workitems/edit/17509673. It seems to be going along!

[chcosta]

says they are targeting April

I agree with everything Richie said, and I saw something recently that indicated they thought June was likely (I think based on historical data), but I'm not going to hunt it down. Regardless, it is likely that we will be stuck in this state until after .NET 7's EOL.