Skip to content

Remove hardcoding of TFMs in wasm tests #123155

Description

@ericstj

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.

<_TasksDir Condition="'$(MSBuildRuntimeType)' == 'Core'">$(MSBuildThisFileDirectory)..\tasks\${NetCoreAppToolCurrent}\</_TasksDir>
<_TasksDir Condition="'$(MSBuildRuntimeType)' != 'Core'">$(MSBuildThisFileDirectory)..\tasks\${NetFrameworkToolCurrent}\</_TasksDir>

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.

Activity

  1. added
    needs-area-labelAn area label is needed to ensure this gets routed to the appropriate area owners
    on Jan 13, 2026
  2. ericstj commented on Jan 13, 2026

    @ericstj
    MemberAuthor

    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.

  3. added this to the 11.0.0 milestone on Jan 14, 2026
  4. added
    arch-wasmWebAssembly architecture
    and removed
    needs-area-labelAn area label is needed to ensure this gets routed to the appropriate area owners
    on Jan 14, 2026
  5. ericstj commented on Jan 14, 2026

    @ericstj
    MemberAuthor

    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.

  6. reopened this on Feb 18, 2026
  7. assigned and unassigned on Jul 8, 2026
  8. pavelsavara commented on Jul 15, 2026

    @pavelsavara
    Member

    Is this going to make net12 branching difficult ?

  9. maraf commented on Jul 15, 2026

    @maraf
    Member

    Is this going to make net12 branching difficult ?

    It's just one more place that needs to be updated when branching

  10. akoeplinger commented on Jul 15, 2026

    @akoeplinger
    Member

    I took a stab at the WebAssembly.Pack task here: #130782

    I think we could do the same thing for the other tasks

  11. added a commit that references this issue on Aug 17, 2026
    45ad194
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

arch-wasmWebAssembly architecturearea-WorkloadsWorkloads like wasm-tools

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions