.Net PDK - Developer Environment Setup - wasi-sdk issues! Unable to build plugin!

[Simonl9l]

It would be great to have a short guide on dev end setup that is a tad more detailed. I'd suggest generally, the .Net crowd may not be as comfortable as others with getting going here, and within that the MacOS subset to some degree and Windows to a larger degree.

I'm developing under MacOS Apple Silicon/Arm - but have team members on linux and windows.

It seem that current there is a dependency on wasi-sdk v16 from June 2 2022, whereas the latest seem to be v21.

I'd initially installed the latter; but is seem (guess) that perhaps the wasi-experimental workload requires the former and expects to find it in /Users/{profile}/.wasi-sdk/wasi-sdk-16.0 that in the /opt/wasi-sdk per the install instructions, and the use instructions notes:

The --sysroot=... option is not necessary if WASI_SDK_PATH is /opt/wasi-sdk.

As such one needs to set WASI_SDK_PATH = /Users/{profile}/.wasi-sdk/wasi-sdk-16.0

However all this done, and with the basis template setup per here, I get the following error:

0>Wasi.Sdk.targets(102,3): Error MSB4062 : The "Microsoft.WebAssembly.Build.Tasks.WasmResolveAssemblyDependencies" task could not be loaded from the assembly /usr/local/share/dotnet/packs/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk/8.0.2/Sdk/../tasks/net8.0/WasmAppBuilder.dll.  Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
0>------- Finished building project: WasiInterfacePlugin. Succeeded: False. Errors: 1. Warnings: 0

the requisite file is where it's supposed to be:
/usr/local/share/dotnet/packs/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk/8.0.2/Sdk/../tasks/net8.0/WasmAppBuilder.dll

I did find this closed issue - with no resolution dotnet/runtime#81136

I have the following workloads installed:

Installed Workload Id      Manifest Version      Installation Source
--------------------------------------------------------------------
wasi-experimental          8.0.2/8.0.100         SDK 8.0.100        
maui                       8.0.6/8.0.100         SDK 8.0.100        

Any help in how to fix this would be greatly appreciated!

I see that there is a Wasi.SDK nugget package, could this also be a viable option (if updated) such that is is far easier to have a self contained dev environment, and would also potentially make DevOps pipelines easier to setup?

[mhmd-azeez]

Hello @Simonl9l

I transferred the discussion to the extism/dotnet-pdk repo so that others might be able to benefit from the discussion in the future. The extism/extism repo is mostly for the Rust SDK/runtime.

On my machine I am using v20 of the WASI SDK on Windows. The only thing I had to do was to download the WASI SDK to a location on my machine and set the WASI_SDK_PATH environment variable to the path of the folder (make sure the path points to the folder that contains the top-level bin, lib, share folders.

So if you extract the archive into /Users/{profile}/.wasi-sdk/wasi-sdk-16.0 make sure /Users/{profile}/.wasi-sdk/wasi-sdk-16.0 contains all 3 folders.

Hope that helps

[Simonl9l]

@mhmd-azeez Thanks - good to know that one just puts the v20 SDK in the /Users/{profile}/.wasi-sdk/wasi-sdk-16.0 folder. Have you tested with v21?

Is it a correct assumption that the /Users/{profile}/.wasi-sdk/wasi-sdk-16.0 folder is determined by the wasi-experimental workload - and odd that is not using/expecting the latest wasi-sdk?

Per the other part of my observation, and this error:

0>Wasi.Sdk.targets(102,3): Error MSB4062 : The "Microsoft.WebAssembly.Build.Tasks.WasmResolveAssemblyDependencies" task could not be loaded from the assembly /usr/local/share/dotnet/packs/Microsoft.NET.Runtime.WebAssembly.Wasi.Sdk/8.0.2/Sdk/../tasks/net8.0/WasmAppBuilder.dll.  
Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
0>------- Finished building project: WasiInterfacePlugin. Succeeded: False. Errors: 1. Warnings: 0

if so, this is then nothing to with the wasi-sdk, and if so it also correct that WasmAppBuilder.dll is part of the wasi-experimental workload?

Given you running on Windows and I'm on arm64 MacOS, is there potenitaly an issue with the wasi-experimental?

I also removed my maui workload so as to ensure there is not other dependency interacting.

I'm at a loss as to how to move forwards here - do you have an other suggestions?

[Simonl9l]

I've opened an issue here dotnet/runtime#98538 (reply in thread) - to see in MSFT can help understand the issue...

What the positioning on using the wasi-sdk v21 with Extism ? - not that that help resolve this but in general?

[Simonl9l]

@mhmd-azeez - The wasi-expeimental workflow folks at MSFT came back to me, and it seems (experimentation) that it appears that one does not need to install the wasi-sdk at all, as this seems to be included/embedded inside the workload. Is this also aligned with your understanding?

If so, then perhaps the setup documentation can be simplified?

I'll now try and hook this up with my .Net host setup....and hope it all works!

[mhmd-azeez]

@Simonl9l hi, you can put your WASI SDK whereever you want. Just make sure you set the WASI_SDK_PATH environment variable to point to it. For example, make sure yours is similar to this:

PS C:\Users\muham> tree $env:WASI_SDK_PATH
Folder PATH listing for volume Dev
Volume serial number is 166D-36BC
D:\TOOLS\WASI_SDK
├───bin
├───lib
│   └───clang
│       ├───16
│       │   ├───include
│       │   │   ├───cuda_wrappers
│       │   │   ├───hlsl
│       │   │   ├───openmp_wrappers
│       │   │   └───ppc_wrappers
│       │   └───lib
│       │       └───wasi
│       └───17
│           ├───include
│           │   ├───cuda_wrappers
│           │   │   └───bits
│           │   ├───hlsl
│           │   ├───llvm_libc_wrappers
│           │   ├───openmp_wrappers
│           │   └───ppc_wrappers
│           └───lib
│               └───wasi
└───share
    ├───clang
    ├───cmake
    │   └───Platform
    ├───misc
    └───wasi-sysroot
        ├───include
        │   ├───arpa
        │   ├───bits
        │   ├───c++
        │   │   └───v1
        │   │       ├───experimental
        │   │       ├───ext
        │   │       ├───__algorithm
        │   │       │   └───pstl_backends
        │   │       │       └───cpu_backends
        │   │       ├───__atomic
        │   │       ├───__bit
        │   │       ├───__charconv
        │   │       ├───__chrono
        │   │       ├───__compare
        │   │       ├───__concepts
        │   │       ├───__condition_variable
        │   │       ├───__coroutine
        │   │       ├───__debug_utils
        │   │       ├───__exception
        │   │       ├───__expected
        │   │       ├───__filesystem
        │   │       ├───__format
        │   │       ├───__functional
        │   │       ├───__fwd
        │   │       ├───__ios
        │   │       ├───__iterator
        │   │       ├───__locale_dir
        │   │       │   └───locale_base_api
        │   │       ├───__mdspan
        │   │       ├───__memory
        │   │       ├───__memory_resource
        │   │       ├───__mutex
        │   │       ├───__numeric
        │   │       ├───__pstl
        │   │       │   └───internal
        │   │       │       └───omp
        │   │       ├───__random
        │   │       ├───__ranges
        │   │       ├───__stop_token
        │   │       ├───__string
        │   │       ├───__support
        │   │       │   ├───android
        │   │       │   ├───fuchsia
        │   │       │   ├───ibm
        │   │       │   ├───musl
        │   │       │   ├───newlib
        │   │       │   ├───openbsd
        │   │       │   ├───solaris
        │   │       │   ├───win32
        │   │       │   └───xlocale
        │   │       ├───__system_error
        │   │       ├───__thread
        │   │       ├───__tuple
        │   │       ├───__tuple_dir
        │   │       ├───__type_traits
        │   │       ├───__utility
        │   │       └───__variant
        │   ├───net
        │   ├───netinet
        │   ├───netpacket
        │   ├───scsi
        │   ├───sys
        │   └───wasi
        ├───lib
        │   ├───wasm32-wasi
        │   └───wasm32-wasi-threads
        └───share
            ├───wasm32-wasi
            └───wasm32-wasi-threads

Notice how I am running tree on the environment variable itself. Which points to D:\TOOLS\WASI_SDK on my machine.

Have you tested with v21?

Yes, v21 seems to work too

if so, this is then nothing to with the wasi-sdk, and if so it also correct that WasmAppBuilder.dll is part of the wasi-experimental workload?

Yes, WASI SDK has nothing to do with .NET. It's a generic SDK that's used by many languages. WasmAppBuilder.dll is part of .NET's wasi-experimental workload

The wasi-expeimental workflow folks at MSFT came back to me, and it seems (experimentation) that it appears that one does not need to install the wasi-sdk at all

After reading the linked thread, it seems they're suggesting you DO need to install it:

Not yet. It's something that will most probably change, but at the moment you need to install wasi-sdk manually and set WASI_SDK_PATH to point to it.