Repository navigation
Remove hardcoding of TFMs in wasm tests #123155
Description
Activity
- addeduntriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner
on Jan 13, 2026 - addedneeds-area-labelAn area label is needed to ensure this gets routed to the appropriate area ownersAn area label is needed to ensure this gets routed to the appropriate area owners
on Jan 13, 2026 Having a look at the use of GetFilesToPackage in all the task projects - https://github.com/search?q=repo%3Adotnet%2Fruntime%20GetFilesToPackage%20path%3A%2Fsrc%2Ftasks%2F**&type=code they choose to include framework version in the path, but this can all be removed for a version-less path.
The targets mentioned above are responsible for selecting which is used. Those can have version removed.
The tasks which hardcode these versions can either remove the versions (as others) or leverage the targets.
- removeduntriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner
on Jan 14, 2026 - addedarea-WorkloadsWorkloads like wasm-toolsWorkloads like wasm-toolsarch-wasmWebAssembly architectureWebAssembly architectureand removedneeds-area-labelAn area label is needed to ensure this gets routed to the appropriate area ownersAn area label is needed to ensure this gets routed to the appropriate area owners
on Jan 14, 2026 This was also a problem in the product targets - dotnet/dotnet#4205 is where we missed updating a TFM. We should remove the versions from the paths, and also have the runtime tests import the built props so that they can test we get it right.
Is this going to make net12 branching difficult ?
Is this going to make net12 branching difficult ?
It's just one more place that needs to be updated when branching
I took a stab at the WebAssembly.Pack task here: #130782
I think we could do the same thing for the other tasks
- added a commit that references this issue
on Jul 16, 2026 - added a commit that references this issue
on Aug 17, 2026
One case was discussed here #123100 (comment)
This could be removed by ensuring that props in the SDK define the path of the tasks, and those props get imported by the test-generated project. This TFM in the path to the folder containing tasks is completely unnecessary coupling to the framework version. The product itself only ever cares about two frameworks and only selects between those two.
runtime/src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Sdk/Sdk.targets.in
Lines 4 to 5 in f7c4c8c
There is probably more hardcoding that can be removed. If necessary we could have a source-generator flow MSBuild properties into the test sources, but ideally we can just make the tests do things that users would (or closer to what users would) and not need to "know" too much about the shape of the product's internal paths.