[wasm] Changing DllImport does not result in a new wasm module

[silesmo]

Description

Rebuilding a project targeting the wasi-experimental workload when changing the arguments in the DllImport attribute doesn't result in a new wasm module to be built.

I have built this tool that you can use to see all the imports and exports easily directly in the browser, that can hopefully assist when checking the produced wasm: https://wa2.dev/

@lewing

Reproduction Steps

Build module using nightly targeting wasi-experimental workload

Example function:

    internal static class Float32ParamInterop
    {
        [WasmImportLinkage]
        [DllImport("foo", EntryPoint = "float32-param")]
        internal static extern void wasmImportFloat32Param(float p0);
    }

Then change the EntryPoint to "float32-param-test":

    internal static class Float32ParamInterop
    {
        [WasmImportLinkage]
        [DllImport("foo", EntryPoint = "float32-param-test")]
        internal static extern void wasmImportFloat32Param(float p0);
    }

Rebuild using dotnet build -c Release
Observe that the import name hasn't changed.

If I delete the bin folder and run dotnet build -c Release then all the files except the wasm module is created in bin/Release/net9.o/wasi-wasm/AppBundle

It's not until I delete the obj folder that it actually builds and produces the new wasm module as expected.

Expected behavior

That the module is rebuilt and produces a new wasm module with the correct import module and function name.

Actual behavior

Doesn't produce a new wasm module without deleting the obj folder.

Regression?

Related to: #94615

Known Workarounds

Delete obj folder and rebuild.

Configuration

No response

Other information

No response

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Rebuilding a project targeting the wasi-experimental workload when changing the arguments in the DllImport attribute doesn't result in a new wasm module to be built.

I have built this tool that you can use to see all the imports and exports easily directly in the browser, that can hopefully assist when checking the produced wasm: https://wa2.dev/

@lewing

Reproduction Steps

Build module using nightly targeting wasi-experimental workload

Example function:

    internal static class Float32ParamInterop
    {
        [WasmImportLinkage]
        [DllImport("foo", EntryPoint = "float32-param")]
        internal static extern void wasmImportFloat32Param(float p0);
    }

Then change the EntryPoint to "float32-param-test":

    internal static class Float32ParamInterop
    {
        [WasmImportLinkage]
        [DllImport("foo", EntryPoint = "float32-param-test")]
        internal static extern void wasmImportFloat32Param(float p0);
    }

Rebuild using dotnet build -c Release
Observe that the import name hasn't changed.

If I delete the bin folder and run dotnet build -c Release then all the files except the wasm module is created in bin/Release/net9.o/wasi-wasm/AppBundle

It's not until I delete the obj folder that it actually builds and produces the new wasm module as expected.

Expected behavior

That the module is rebuilt and produces a new wasm module with the correct import module and function name.

Actual behavior

Doesn't produce a new wasm module without deleting the obj folder.

Regression?

Related to: #94615

Known Workarounds

Delete obj folder and rebuild.

Configuration

No response

Other information

No response

Author:	silesmo
Assignees:	-
Labels:	arch-wasm, untriaged, needs-area-label
Milestone:	-

[lewing]

Sounds like something isn't doing incremental builds correctly for the table generator correctly right now in the wasi targets, @radical can you take a look. You if you haven't already, please try adding <WasmBuildNative>true</WasmBuildNative>, it's possible that will resolve the issue but I haven't tested it.

@silesmo thanks for the report, we ceased wasi work somewhat abruptly last year and the targets still have some very rough edges that we've mostly forgotten about since. Apologies for the mess and thank you for helping us find the problems. Do you have a sample csproj? I can probably offer some suggestions (dotnet publish and WasmSingleFileBundle=true) to make things smoother while we clean things up.