.NET Sample & Extism 0.4.0 -> thread panicked about extism

[zshipko]

Thanks for the report! I think this should be fixed on the main branch after #301

Are you seeing this using the latest release or from git?

[christophwille]

code.wasm was from main 9e57369. And as can be seen in https://github.com/christophwille/ExtismHello/blob/c21f4c1eeb0bdaf54a273b0d61260505df0253e1/src/ExtismHello/ExtismHello.csproj#L11 I am using NuGet latest.

[bhelx]

@christophwille #301 is a change to the runtime which is unreleased. You're on the release 0.4.0. you can pull down the runtime and re-compile from source using this command: https://extism.org/docs/install#build-from-source

though I'm not sure it if it will work for windows or not. If you're having trouble we can publish a new version for you. Just let us know!

[bhelx]

You could also, maybe, try downgrading to 0.3.0

[bhelx]

@christophwille Actually, i just realized that there are 2 dotnet libraries. One that embeds the runtime and one that doesn't. Which one are you using?

https://www.nuget.org/packages/Extism.Sdk
https://www.nuget.org/packages/Extism.runtime.win-x64

[christophwille]

I have included both as per the documentation https://extism.org/docs/integrate-into-your-codebase/dotnet-host-sdk/ as I am on Windows.

[christophwille]

Btw, is this is a point-in-time thing that Windows behaves differently? I am using Wasmtime (.NET) someplace else, and that comes with batteries included no matter which platform I am on (Sqlite behaves very much the same, just to throw in another native dependency NuGet).

[bhelx]

Hmm are both meant to be installed? My understanding was that runtime.win-x64 one comes with the libextism runtime embedded in the library where the other one expects the shared object to be somewhere installed on the machine.
I bring it up because the fix is in the runtime: #301

Perhaps @mhmd-azeez can chime in

[mhmd-azeez]

Hello @bhelx, if you use the runtime.win-x64 nuget package you won't need to install extism on windows.

But I think @christophwille is saying (please correct me if I am wrong) that .NET wrappers for other native libraries (e.g. sqlite) ship native libraries for all platforms as nuget packages while extism only ships it for win-x64.

[mhmd-azeez]

@bhelx I just realized I had misread your question. Yes, if you want to deploy your host on Windows, you should reference both the SDK nuget package and the runtime nuget package. The runtime nuget package only contains the native binaries and its release schedule is tied to extism itself.

The libraries that publish nuget packages for all platforms (i.e. runtime.all) that references the individual platforms. If we had that, then the SDK nuget could have taken dependency on runtime.all and users would't have to know about the runtime nuget packages at all. But it doesn't make much sense in our case because we only publish windows-x64 binaries as a nuget package

[christophwille]

Ignoring the original error for a second and getting back to the packages (I don't have my Air M1 nor my Surface X ARM64 on me at the moment) - given my original project referencing both NuGets:

• This works on Windows x64 (obviously, except of course the error that prompted this issue)
• On my ARM64 Windows machine, it won't. Given the runtime x64 NuGet, and no ARM64 runtime NuGet atm.
• On my Air M1 - what will happen there? Will it complain about the Windows x64 runtime NuGet? (never tried that) Or simply ignore it? And will it somehow tell me I am missing something else to make it work? (.NET Devs do expect that NuGets work across architectures)

What I am getting at here is the developer experience - do I need csproj gymnastics to make it work on multiple platforms, and if so, which ones? Is this a point in time thing, or will this always be the case?

Bonus question: why netstandard2.1? Which downlevel platforms really make this a necessity? (anything but 6.0 is out of support on the Core side of the house, netfw full never was supported for netstandard2.1, Xamarin is dead, Mono more or less too, and that old version of Unity?)

[mhmd-azeez]

@christophwille

This works on Windows x64 (obviously, except of course the error that prompted this issue)

This bug should be fixed once a new version of the Extism runtime is released, the fix is already merged #301

On my ARM64 Windows machine, it won't. Given the runtime x64 NuGet, and no ARM64 runtime NuGet atm.

Currently, Extism only publishes binaries for win-64, so win-86 and win-arm64 don't have any published binaries, but I am guessing you can build them from source. Maybe @bhelx can comment on whether we will start building binaries for them too.

On my Air M1 - what will happen there? Will it complain about the Windows x64 runtime NuGet? (never tried that) Or simply ignore it? (.NET Devs do expect that NuGets work across architectures)

The Extism.runtime.win-x64 package basically contains the runtime DLL and copies it to the correct output folder. It doesn't affect the app when running on mac in any way. So you can safely ignore it if you intend to run the host on mac. Instead, you can install extism on the mac itself and it should work fine: https://extism.org/docs/install/

We had a long discussion on #119 and ended up with the current solution. Basically the idea is, for all other SDKs, the expectation is that the you install the Extism runtime on the machine. But because there is no straightforward way to install the runtime on Windows and Windows is an important target for .NET developers, we decided to publish the win-x64 runtime as a nuget package. I don't know if this will change in the future or not.

[mhmd-azeez]

Bonus question: why netstandard2.1? Which downlevel platforms really make this a necessity? (anything but 6.0 is out of support on the Core side of the house, netfw full never was supported for netstandard2.1, Xamarin is dead, Mono more or less too, and that old version of Unity?)

There was someone who was experimenting with using Extism in Unity. And I didn't want to unnecessarily exclude .NET Core versions. .netstandard2.1 has Span<T> which was all that was necessary for a performant wrapper

[christophwille]

I updated to 0.5.0 https://github.com/christophwille/ExtismHello/blob/7b7c9c633d994040454662fb6ef1ba8a778a5bde/src/ExtismHello/ExtismHello.csproj#L11 just now (had to add an empty HostFunction[] https://github.com/christophwille/ExtismHello/blob/7b7c9c633d994040454662fb6ef1ba8a778a5bde/src/ExtismHello/Program.cs#L7)

However, I still get

{"count": 3}
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74\library\std\src\thread\mod.rs:1458:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[christophwille]

I had a look around the filesystem - and instead of doing a Clean, I also decided to delete bin folder directly in Explorer to make sure I didn't screw up. But:

Note the file date - it says mid-March, and it has no version information (Extism.Sdk.dll does). Could it be that native is shipping the wrong binary?

[christophwille]

Looks like https://github.com/extism/extism/blob/main/.github/workflows/release-dotnet-native.yaml is downloading "some" artifact - and that might not be 0.5.0 (yes, please, there should be a version information in the .dll, not only the NuGet package)

[bhelx]

I pushed out a dotnet release so we can release host functions support. We still have not released the runtime which has the fix need.

…

On May 2, 2023 at 3:08 AM -0500, Christoph Wille ***@***.***>, wrote: Looks like https://github.com/extism/extism/blob/main/.github/workflows/release-dotnet-native.yaml is downloading "some" artifact - and that might not be 0.5.0 (yes, please, there should be a version information in the .dll, not only the NuGet package) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[christophwille]

https://www.nuget.org/packages/Extism.runtime.win-x64#versions-body-tab both the SDK and the runtime were published to 0.5.0

[bhelx]

both the SDK and the runtime were published to 0.5.0

I think the runtime publish was a mistake on my part. Fixing our docs. We will get a new runtime release out this week though. And I'm working on automating more of our release process so we can do it more often.

[bhelx]

@christophwille we pushed changes to the runtime and hosts. I think the upgrading the runtime (version 0.6.0 of this one https://www.nuget.org/packages/Extism.runtime.win-x64) should fix the problem. If not feel free to re-open or let us know