Bump _NET50RuntimePackVersion to 5.0.1

[lewing]

I'm not entirely sure this is the correct fix but right now if someone installs a 6.x sdk after installing 5.0.101 (or more unfortunately had already installed it) they will end up with a 5.0.0 runtime pack when publishing to a browser-wasm rid. I'm not sure who typically owns this bump but I'd like to avoid it causing more issues for blazorwasm users.

I suspect #9198 could be a similar one-liner, or if there is value in not allowing overrides of the 50Defaults, this can go in after that.

[marek-safar]

This shouldn't be wasm specific, right?

@ViktorHofer @janvorli @mmitche @safern thoughts on long term fix?

[mmitche]

I'm not sure tbh.

[lewing]

This shouldn't be wasm specific, right?

Correct, but I've only verified that case and it especially painful there because the wasm runtime exists only as a runtime pack. It appears that if you've ever installed a development build from https://github.com/dotnet/installer with a version higher than 5.0.101 your packs are pinned to 5.0.0 until you install a new highest sdk version that bumps the net5.0 LatestRuntimePackVersion to 5.0.1 (none do right now).

[safern]

I feel like this should use a property that darc updates... the problem with this fix is that when we service 5.0.2, then this will be outdated and will be pointing to 5.0.1, so it would always be behind. Are we shipping a 5.0.2 browser runtime pack?

It feels like we should do the same thing for the AspNetCore and WindowsDesktop runtime packs. If we service a new runtime pack and then I update to 5.0.2, and publish a self contained app I will get the 5.0.0 runtime pack if these properties are not updated, right?

cc: @ericstj

[safern]

i.e, I think it should use this property:

installer/eng/Versions.props

Line 89 in 42a530b

<MicrosoftNETCoreAppRuntimePackageVersion>$(MicrosoftNETCoreAppRuntimewinx64PackageVersion)</MicrosoftNETCoreAppRuntimePackageVersion>

which points to:

installer/eng/Versions.props

Line 72 in 42a530b

<MicrosoftNETCoreAppRuntimewinx64PackageVersion>5.0.1</MicrosoftNETCoreAppRuntimewinx64PackageVersion>

Which are updated by darc.

[wtgodbe]

i.e, I think it should use this property:

That's in the 5.0 branch - in master that version is 6.0 as it should be. The problem with updating 5.0 versions with darc in a 6.0 branch (or 3.1 versions in a 5.0 branch, etc), is that it connects those graphs, meaning we couldn't complete the 6.0 build until the 5.0 build is done, and we couldn't complete the 5.0 build until the 3.1 build is done. Whereas today we can do all 3 in parallel. The solution we have now is to have devs from product teams push updates to higher-level dotnet/installer branches when they ship new versions of their lower-level branches (I do this now for Aspnetcore - e.g. every time we ship 3.1, I update the 5.0 and master branches of installer).

[safern]

Ah... I thought this was targeting the 5.0 branch. Disregard my comments. Thanks, @wtgodbe for the details explanation.... could this be done as part of the release process (i.e, when we create tags and push packages to nuget for servicing releases)?

[lewing]

I see two problems:

1. That the version hasn't been updated after a servicing release
2. Installing a preview with a higher SDK version completely breaks servicing until you remove the preview or install another higher version SDK with the LatestRuntimePackVersion updated to the servicing release version

[lewing]

This is getting a bit off topic for this one line PR but an example of why 2 worries me:

• Install VS 16.8.3 and build your blazor app from:
  • VS 16.8.3 => 5.0.1
  • VS Code / command line => 5.0.1
• Now Install VS 16.9p2 SxS and rebuild from:
  • VS 16.8.3 => 5.0.1
  • VS 16.9p2 => 5.0.0
  • VS Code / command line => 5.0.0

And the command line will stay that way until you install an sdk version > 5.0.200 with an updated LatestRuntimePackVersion even if you install 16.8.4 with a 5.0.102/5.0.2

[kg]

Admittedly I'm not an expert on how we do our versioning, but why aren't we versioning the wasm runtime pack separately if we have this disconnect issue where .NET previews can effectively downgrade unrelated components? My understanding until this point was that .NET was solving this category of issue in many cases by moving things into nugets (parts of the standard library, etc) where appropriate so they can be versioned separately and get updates. Is there some reason we need to pin the particular runtime pack in use at all instead of just selecting the newest compatible runtime pack nuget to use, and have dependencies set in the nuget package so that a runtime pack requiring .NET 6 isn't selected in .NET 5? Then it at least becomes possible to have a "latest" runtime pack (5.0.100) instead of the runtime pack that shipped with your "latest" dotnet (6.0), as long as it's compatible with your runtime (and wasm runtime pack 5.0.100 would have dotnet 5.0.100 as a requirement, so it would be compatible with both and be selected)

[marcpopMSFT]

Covered in email but we don't keep master up to date except when preparing for previews or after security fixes. Happy to take this change if it helps though you could consider updating windows desktop and aspnet versions as well though it looks like Will was updating the aspnet one here: #9198