Hi all. It was just me and James at today's C#/.NET SIG-Guest-Languages meeting. We chatted a bit about next steps for WASIp3 support in .NET and would like to schedule a meeting for sketching out a high-level design that encompasses the wit-bindgen C# generator, runtimelab support, wasi-libc, etc.
I had suggested that we devote the next C#/.NET meeting (two weeks from now) to that, but just realized that I'll be at an offsite event then and won't be able to make it. So we could either do it four weeks from now or or schedule something sooner if people are eager to get started. Let me know if you have a preference.
Personally, I think aiming for four weeks from now might make sense because it will give me time to add support for async/futures/streams to the C binding generator and use that to prototype WASIp3 support in wasi-libc. Knowing how all that works will help inform our discussion.
cc @Timmy Silesmo @Pavel Šavara
I'm stuck working features for dotnet on browser, so I would not be able to help coding it in next few months. That said I'm interested to stay in the loop and provide support/comments. Regarding the meeting, I'm afraid I lost the invite again.
I've also lost the invite; I just set a recurring alarm on my phone, and when the alarm happens I go to https://calendar.google.com/calendar/u/0/embed?src=events@bytecodealliance.org to get the link. Maybe someone else can point us to the proper way to add ourselves to the meeting.
Ah yes now I remeber, there is some google group that you can join to receive that calendar on your Google account.
Anyway, 4 weeks from now that's Feb 19, right?
Correct, Feb 19
Works for me, I not be able to make the meeting on Feb 5th either
Our system for managing invitations on the events@bytecodealliance.org calendar is via the sig-admin Google Group, which Joel and James are on. Generally, though, we don't add invitees directly to those invitations but you can subscribe to the events@ calendar on your personal calendar and so see all the various meetings and their associated details. (Originally SIG-Guest-Languages had its own separate Google calendar and group as Pavel mentions but I think mostly has moved away from that.
Happy to help you sort this out -- DM me if you like.
Anyone else have a problem with function.rs ? I get this error
C:\github\wit-bindgen>cargo test -p wit-bindgen-csharp -- flags
Compiling wit-bindgen-csharp v0.38.0 (C:\github\wit-bindgen\crates\csharp)
error[E0716]: temporary value dropped while borrowed
--> crates\csharp\src\function.rs:271:37
|
270 | let exception_name = match exception_name {
| -------------- borrow later stored here
271 | Some(type_name) => &format!("WitException<{}>", type_name),
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-
| | |
| | temporary value is freed at the end of this statement
| creates a temporary value which is freed while still in use
|
= note: consider using a `let` binding to create a longer lived value
= note: this error originates in the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info)
I'm working your angle as much as I can, @Pavel Šavara
@Scott Waye I am not getting that error on main:
wit-bindgen on main [$] via 🦀 v1.83.0
❯ git rebase upstream/main
Successfully rebased and updated refs/heads/main.
wit-bindgen on main [$] via 🦀 v1.83.0
❯ cargo test -p wit-bindgen-csharp -- flags
Compiling wit-bindgen-core v0.38.0 (C:\Users\jstur\projects\wit-bindgen\crates\core)
Compiling wit-bindgen-csharp v0.38.0 (C:\Users\jstur\projects\wit-bindgen\crates\csharp)
Compiling test-helpers v0.0.0 (C:\Users\jstur\projects\wit-bindgen\crates\test-helpers)
Finished `test` profile [unoptimized + debuginfo] target(s) in 10.52s
Running tests\codegen.rs (target\debug\deps\codegen-83f28110c7a79423.exe)
running 1 test
test flags ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 78 filtered out; finished in 6.85s
wierd, I can workaround it for now.
Joel Dice said:
Correct, Feb 19
Works great for me as well!
As mentioned a couple of weeks ago. I do have the bandwidth to do the implementation for async on the C# side.
I understand there is no meeting today, so just to inform you that there appears to be a gc hole or something similar with web sockets. This is probably not isolated to web sockets, but more likely interop in general. In case you hit strange errors with longer running programs.
Thanks for the heads up.
Last updated: Dec 06 2025 at 06:05 UTC