[main] Fix MonoToolchain.Current naming and Update dependencies from dotnet/emsdk and dotnet/sdk

[lewing]

Update dotnet/emsdk dependency with new workload prerelease naming (and add a comment about the incoming mono name change)

[lewing]

waiting for dotnet/runtime#80401

[lewing]

this should be mergeable in the current form now and the I'll update toolchain swap once the pr lands

https://github.com/dotnet/runtime/blob/main/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Manifest/WorkloadManifest.json.in#L4 won't be satisfied if we do

We don't need to wait for dotnet/runtime#80401 the current runtime workload dependency is on the net7 pack that does exist in both builds.

[lewing]

@dsplaisted for dotnet/darc packages is there some reason we can't just assume the feature band from the package version instead of the package name, setup a fallback order where release/rtm > rc > preview > alpha/beta and do the right thing automatically? Getting the darc flow corrent and renaming all the variables for each branding change seems unmaintainable and we still end explicitly setting the band even when it is in the name.

cc @marcpopMSFT @mmitche

[lewing]

or we could flip the naming convention and use the nuget version unless there is a -<label>.<iteration> (with some ordering) in the package name which would resolve the issue for runtime and continue to work for maui

cc @steveisok

[lewing]

opened #15367

[lewing]

This isn't 100% correct since it is encoded in the package name and could be different from the sdk PreReleaseVersion* setting but I can't use the package version for the same reason and using the package name here would break intent of the prerelease setting. #15367

[lewing]

At least this way it will fail if there isn't a package that satisfies the conditions required to make it mostly work

[lewing]

System.IO.DirectoryNotFoundException : Could not find a part of the path 'D:\a\_work\1\s\artifacts\bin\EndToEnd.Tests\Debug\net7.0\Tests\EndToEnd.Tests\ItCanPublishArm64Winforms\bin\Debug'.


Stack trace
   at System.IO.Enumeration.FileSystemEnumerator`1.CreateDirectoryHandle(String path, Boolean ignoreNotFound)
   at System.IO.Enumeration.FileSystemEnumerator`1.Init()
   at System.IO.Enumeration.FileSystemEnumerable`1..ctor(String directory, FindTransform transform, EnumerationOptions options, Boolean isNormalized)
   at System.IO.Enumeration.FileSystemEnumerableFactory.DirectoryInfos(String directory, String expression, EnumerationOptions options, Boolean isNormalized)
   at System.IO.DirectoryInfo.InternalEnumerateInfos(String path, String searchPattern, SearchTarget searchTarget, EnumerationOptions options)
   at System.IO.DirectoryInfo.GetDirectories(String searchPattern, EnumerationOptions enumerationOptions)
   at EndToEnd.Tests.ProjectBuildTests.ItCanPublishArm64Winforms(String TargetFramework) in /_/test/EndToEnd/ProjectBuildTests.cs:line 112
   at InvokeStub_ProjectBuildTests.ItCanPublishArm64Winforms(Object, Object, IntPtr*)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

No idea why this pr could be causing a wpf failure, but those are the only failing tests.

[mmitche]

or we could flip the naming convention and use the nuget version unless there is a -<label>.<iteration> (with some ordering) in the package name which would resolve the issue for runtime and continue to work for maui

cc @steveisok

You could probably keep have package name shift, but construct the package ref in here based on this repo's feature band/major version. This would work as long as the version of the package always remains the same as another that does have a stable name.

[joeloff]

We'll need to remember to update the VS authoring once an SDK with this change is inserted.

[mmitche]

@mmitche I made the MonoToolchain workload dependency flow from sdk still since that is where it has been coming from but we should probably do the same in emscripten. Or we could in theory let the workload flow directly which would mean they aren't at the bottom of the stack but it has other risks I suppose

Because runtime as a dependency on emsdk, flowing them directly doesn't result in a coherent product until runtime gets the same update and flows through. So coherency tying them is the right thing to do.

Note that you need to add the dependency to sdk for the coherency tie to work predictably.

[lewing]

#15370 test failure is unrelated to the workload changes

[lewing]

@joeloff we're hitting signing issues on hashed msi names now

[lewing]

Updated the signing exclusions, hopefully that is the last thing

[lewing]

/backport to release/8.0.1xx

[lewing]

Awww, isn't backport in arcade now?