Add versioned workload aliases to Current manifest

[Copilot]

Current manifest lacked versioned workload aliases, making major version transitions require manifest updates. Added versioned aliases (e.g., wasm-tools-net11) that extend base workloads.

Changes

• Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest: Added 14 versioned aliases for all workloads (wasm-tools, wasm-experimental, wasi-experimental, mobile-librarybuilder, and runtime-specific workloads)
• Microsoft.NET.Workload.Emscripten.Current.Manifest: Added versioned alias for microsoft-net-sdk-emscripten
• Fixed typo: "tooing" → "tooling" in WASI description

Pattern

Versioned workloads use extends to inherit from base definitions:

{
  "workloads": {
    "wasm-tools-net11": {
      "extends": [ "wasm-tools" ]
    },
    "wasm-tools": {
      "description": ".NET WebAssembly build tools for net11.0",
      "packs": [ "..." ],
      "extends": [ "microsoft-net-runtime-mono-tooling", "microsoft-net-sdk-emscripten" ]
    }
  }
}

This allows referencing wasm-tools (backward compatible) or wasm-tools-net11 (version-specific) as needed during transitions.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[workloads] Add versioned workload aliases to manifest</issue_title>
<issue_description>To make it easier to transition workloads across major version updates the Current manifest should provide a versioned workload name in addition to unversioned workload.

for example the Current manifest should define both wasm-tools as an alias wasm-tools-${NetVersion} in the json so that when updating major versions we can reference the versioned workload when updating current.

One this is complete in sdk the net10 test manifests here should be fixed to reference the net10 version</issue_description>

Comments on the Issue (you are @copilot in this section)

@lewing https://github.com//pull/52031#issuecomment-3620986939 @lewing @rolfbjarne @joeloff we should discuss what correct way to do this is to satisfy any VS rules. @rolfbjarne > [@rolfbjarne](https://github.com/rolfbjarne) [@joeloff](https://github.com/joeloff) we should discuss what correct way to do this is to satisfy any VS rules.

I don't know about any VS rules, but I would think just providing new workloads that offers the same as the existing workloads shouldn't cause much trouble?

{
    "workloads": {
		"microsoft-net-runtime-ios-net11": {
			"extends": [
				"microsoft-net-runtime-ios"
			]
		},
		"microsoft-net-runtime-ios": {
			// existing stuff
		},
	}
}

(famous last words of course...)</comment_new>

• Fixes [workloads] Add versioned workload aliases to manifest #52516

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[joeloff]

@lewing this might cause problems for VS, unless we're careful to remove the downlevel alias. For example, we'll now end up with wasm-tools-11 that extends wasm-tools. When we produce the 12.0 workloads, we need to ensure that the wasm-tools from 11.0 is renamed as wasm-tools-11, so that wasm-tools extends wasm-tools-12. Each workload becomes a component in VS and we can't have duplicate wasm-tools components.

[lewing]

oduce the 12.0 workloads, we need to ensure that the wasm-tools from 11.0 is renamed as wasm-tools-11, so that was

would flipping the aliasing be enough?