[workloads] Add prerelease version to workload manifest location

[lewing]

We can avoid problems in the future by making sure prerelease workload manifests don't end up in the stable band directory and we should do this before net8-preview 1

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[lewing]

@dsplaisted what do we need to do here on the authoring side?

[dsplaisted]

The version band is already included in the package ID, for example 7.0.100 in Microsoft.NET.Workload.Mono.ToolChain.net6.Manifest-7.0.100. So you should update the package IDs to include the preview band, for example Microsoft.NET.Workload.Mono.ToolChain.net8.Manifest-8.0.100-preview.1.

Does that help?

[radical]

The version band is already included in the package ID, for example 7.0.100 in Microsoft.NET.Workload.Mono.ToolChain.net6.Manifest-7.0.100. So you should update the package IDs to include the preview band, for example Microsoft.NET.Workload.Mono.ToolChain.net8.Manifest-8.0.100-preview.1.

Does that help?

This workload depends on Microsoft.NET.Workload.Emscripten.*. Would the manifests for that also be installed with the same sdk-band - 8.0.0-preview.1?

I'm having some trouble with adapting our tests for this. For our Wasm.Build.Tests, we do:

1. install the latest 8.0 sdk
2. Install (copy) the locally built Microsoft.NET.Workload.Mono.ToolChain.Manifest*nupkg manifest
3. Install its dependency (Microsoft.NET.Workload.Emscripten*) manifests by using the same sdk-band, but a different package version.
4. Install packs using dotnet workload install ...

This process is breaking down for me at (3). For a local build:

a. I get SdkBandVersion=8.0.0-dev (with https://github.com/dotnet/runtime/pull/79184/files#diff-50e91c82311ea26f2a73202525dfdf2b0a89c178ee666b2bf3ad4c84ac4c06dcR96-R97)
b. our msbuild task finds, and installs the Microsoft.NET.Workload.Mono.ToolChain.Manifest-8.0.100-dev.8.0.0-dev* from artifacts
c. The task tries to now find the Emscripten manifest also, and builds up the package name using SdkBandVersion=8.0.100-dev - Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100-dev. But that package doesn't exist, for obvious reasons.

What is the expected behavior here? Does the workload resolver expect to find all the manifests in the same sdk-manifest/8.0.100-dev? Should the emscripten manifest be installed to the same band, somehow?

[radical]

@dsplaisted ping

[steveisok]

@radical if I understand this correctly, I think the band in the sdk-manifest folder path should be 8.0.100. The manifest inside that folder will contain prerelease info in the name.

[dsplaisted]

@radical if I understand this correctly, I think the band in the sdk-manifest folder path should be 8.0.100. The manifest inside that folder will contain prerelease info in the name.

This is not correct. The folders under the sdk-manifests folder are the version bands, and may include the prerelease specifier.

What is the expected behavior here? Does the workload resolver expect to find all the manifests in the same sdk-manifest/8.0.100-dev? Should the emscripten manifest be installed to the same band, somehow?

The resolver does not need all of the manifests to be in the same band. If a workload is listed in IncludedWorkloadManifests.txt, then the resolver will first look for the manifest in the current band folder, but if it's not found there will fall back through the earlier version bands in the sdk-manifests folder.

The task tries to now find the Emscripten manifest also, and builds up the package name using SdkBandVersion=8.0.100-dev - Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100-dev. But that package doesn't exist, for obvious reasons.

Why doesn't the package exist? Is Emscripten using different preview specifiers that runtime is? If so you may have to have some way for the tests to have a way to find the Emscripten band to use.