# SIG-Guest Languages - C#/.net Agenda & Notes

Meeting link: https://zoom.us/j/95573248270?pwd=LXFt63RShQbx7xgTl3LsFY26Z2F7oz.1

## August 6th 2025
| | |
| -------- | ------- |
| Attending | Scott Waye, James Sturtevant |
| Note Taker | James |
- Scott: Opened first PR for the Async, it doesn't do much but sets things up
- no c# equivlant to futures, working through how to represent this
- James: release of wasmtime-dotnet
- Scott: made some progress on threads but can't so much until wasi 3+

| | |
| -------- | ------- |
| Attending | Scott Waye |
| Note Taker | Scott |
- Scott: Started c# codegen for the futures.wit test. Have some questions which I will bring up in zulip.

## July 23rd 2025

| | |
| -------- | ------- |
| Attending | Scott Waye |
| Note Taker | Scott |
- Scott: Started c# codegen for the futures.wit test. Have some questions which I will bring up in zulip.

## May 14th 2025

- canceled. no agenda items

## April 16th

| | |
| -------- | ------- |
| Attending | Joel Dice, Timmy Silesmo, Bailey Hayes |
| Note Taker | Joel |

- For future reference, guide to SIG-Guest-Languages account mgmt, calendar, etc: https://github.com/bytecodealliance/governance/blob/main/SIGs/getting-started-guide.md
- Joel: note to self: use correct google account to access [e-mail] google group to retrieve 2-factor codes
- Bailey: SIG-Community shuffling with people changing jobs. Is the monthly meeting still valuable? Yes, sounds like it; need to reboot. Tried rotating time zones but that was more trouble than it was worth (e.g. 9-10pm calls in ET)
- Tim: yeah, had meeting overload
- Bailey: had aspirations about pre-recording and engaging global audience. Engineers prefer live, informal meetings, though.
- SIG-Guest-Language monthly meeting on hiatus. Chairs of individual language subgroups will effectively be chairs of group
- Bailey: working on roadmap based on recent meeting notes. Feeling pressure from board members and other stakeholders, which is why roadmap is important. Doesn't need to be a rosey, optimistic picture, but need something.
- Good news: have GC, exception handling resources, etc.
- Timmy: landed funding at his company :tada:
- Timmy: C# updates
- Need to look at wrapping CM streams in `IStream` type
- Want `System.Text.Json` (de)serialization support for `wit-bindgen`-generated types
- Had issues with read-only constructors
- Issues posted to GitHub, e.g. https://github.com/bytecodealliance/wit-bindgen/issues/1265
- Limited resources, so can't do everything at once
- Joel: still cranking on WASIp3; aiming to get fully upstreamed to wasmtime in August

## April 2nd

| | |
| -------- | ------- |
| Attending | Joel Dice, Timmy Silesmo |
| Note Taker | Joel |

- Joel: still focused on WASIp3 and Component Model async stuff.
- Alex and I are discovering new work items at roughly the same rate as we are finishing existing ones.
- Currently improving host and guest API ergonomics and fixing spec and implementation bugs.
- Decided to add task cancelation to 0.3.0 (previously had deferred it, but then decided it's more painful to postpone than it is to implement)
- Timmy: busy with life and other work things, so haven't made a lot of progress on C# async support. Hoping to have a demo ready for the next meeting

## March 19th - c#/.net meeting

Canceled - no agenda

## March 5th - c#/.net meeting

| | |
| -------- | -------- |
| Attending |Joel Dice, James Sturtevant, Scott |
| Note Taker |Joel |

- James: working on porting Pavel's tests over from upstream repo. Mono only to start with; _might_ be able to run them on NativeAOT eventually.
- Scott: not currently building Mono in NativeAOT-LLVM branch, so will need to turn that on. Not currently attempting to run tests in that branch on Mono.
- Scott: working on another upstream merge
- James: got wasi-tls prototyping working; will merge host support into Wasmtime
- Timmy (via Zulip): has made some progress on async support for C# guest binding generator
- James: starting to consolidate manual project setup steps into a template-based `componentize-dotnet new` command
- Joel: still working on WASIp3 stuff

## Feb 19th - c#/.net meeting

| | |
| -------- | -------- |
| Attending |Joel Dice, Timmy Silesmo, James Sturtevant, Pavel, Scott |
| Note Taker |James |

- Joel: Started on lib-c async but not as much progress as hoped
- Timmy: Can we are start something in parrallel?
- Joel: Yes, we can work async. Problaly need to grow binding generator and runtime at the same time
- Pavel: Don't need to know much about the how it works, mostly creating the tasks and making sure they are in right state. Interesting part is keeping the
event loop pumping. Is there a prototype?
- Joel: We have some stuff but need to use the branch: https://github.com/bytecodealliance/wasip3-prototyping There are bunch of tests, pick a simple one and try to run it. There is a simple one that takes a string and does a round trip and makes sure things work.
The interesting part is rust uses callback abi, The c# will need to look up the task based on an id and then see if it finished. The ultimate plan for p3 is that there will be two async approach: callback, and intristic task.wait (equevilant for wasi p2 poll, stackfully wait for many tasks). The call back is we want to return execution back to the host and wait for a call back for readiness.
- Pavel: Makes sense to me but make sure Timmy makes it, My team is now taking on more work around webui for blazor so will be just giving advice at this point.Easiest way is to do binding by hand.
- Regarding the callback sencario, do we get one export?
- Joel: You can specify multiple callbacks but in practices you will will re-use that export. The guest can start 5 tasks and say we want any of the 5 completed, before it does that it should save off the tasks ids, and the host will say 3 and 2 are done and the guest would then get all events and return result back to the how and say I am done
- Pavel: This sounds like interop with javascript, js calls us back and we do our thing. In browser, there is an event loop that makes sure things still do stuff, maybe we need sometype of timer. The thing we can not do is blocking which would stop the thread pool. see https://github.com/dotnet/runtime/blob/main/src/libraries/System.Runtime.InteropServices.JavaScript/src/System/Runtime/InteropServices/JavaScript/Marshaling/JSMarshalerArgument.Task.cs, It is bi-drectional can marshal both ways, there are two types in generic and non generic bindings. The wit should give you a way. In javascript, there are no cancelation of promises so will need to work through those detals
- The other thing to share is .net wasi in runtime, the llvm branch will become the location for even for the mono, so we don't get confusion in support. This is not supported so all changes will need to be llvm branch. Consequences is there are lot of tests that we run upstream but no on the branch.
- Scott: blocking on main thread, is that the browser restriction?
- Pavel: This is soemthing that is common in browswer, want to keep it consistent across browser and host. Don't want to break the consistencies
- Pavel: We have prototype of multiple threaded in browswer and that even blocks
- Timmy: starting to get a mental model but I have a few ideas to get started. Will bet started next week. Maybe we can meet next week to go through the rust implementation at highlevel
- Joel: sure, we have some wat based examples in the tests.
- Joel: What do we need to do about the tests?
- Pavel: tests are there but CI is not configured. There are alot of cpu based tests, not sure if they will work NAOT but should work with mono. ITs running upstream right now but might get shut down and I will let you know
- James: What is the infrastructure on llvm?
- Pavel: I don't know much we build the binaries but not sure what the work is. Not to worried so we don't have to many commits going in. Not a huge issue until we get ahead of main to far.
- Do you think mono or naot will be easier to implement?
- Joel: Not sure, if I was working on it I would use naot
- Timmy: Naot is were I am familiar with.
- Joel: start with one of them and transfer one of them

- Joel: Callback approach where what we are doing with sockets and wasi-libc poll. At what point will wasi-libc be the a blocker? We should be able to do a bunch of stuff before we get to sockets. How do we reconcile never block with libc sockets?
- Pavel: not using posix select, use the handles and it never blocks. The loop containers two things
- Joel: big difference is we give controll to the host,
- Pavel: We need to yield but we need to process any timer based things
- Joel: You can return status to yield to the host, you might not need to create the zero length timer
- Joel: Second point there are potnetically mutliple exports calls in progress. The host makes three concurrent call guest and they all call back to host. We should think that there isn't one top level tasks.
- Pavel: The look for preview 2 is going away, there is a new export that will run the thread pool
- Joel: there is nothing that says you have to pump the queue of work on call back you could do it other times too
- Pavel: only the main look will need to be updated. It seems streams are promising bytes but not creating promise object. .net streams create a task when there is no more data
- Joel: explain streams, differnet from p2. Built into component model, there is an intrensic, specify payload and the type. We create stream of u8 and get back handle, its local to guest and get both ends. If you give away the reable end but you keep write end. These are unbuffered, the read end must be read and you will get call back which when the read either reads it or it closes. The unbuffered aspec is important, completion based not readiness. Need to keep that buffer alive.
- Pavel: This might be interesting since many optomications with span are stack based
- Joel: had long disucssion on this in wasi-libc https://github.com/WebAssembly/component-model/issues/441#issuecomment-2622661035. Stack based might be viable. Mabye this is the same thing .net does for iocp
- Pavel: all file io is synchronous
- joel: mostly interested in networking stuff.
- Pavel: finish idea about allocations: when we handle a stream or promise, we will need a hashtable to map back to tasks. Shoudl think through multiple task connected to same handle. Tasks objects is a heap object and expensive, tight loop around stream could allocate a lot of tasks, there is a value type task which might be good for generated code in some scnearios.
- Joel: if it returns right away don't need task at all, Whats the cheapest way to avoid creating a task. Answer is a no? Can we dynmaically
- Pavel: No - not compatible, can convert heap to stack.

## Jan 1st - c#/.net meeting

| | |
| -------- | -------- |
| Attending |Joel Dice, Timmy Silesmo, James Sturtevant |
| Note Taker |James |

- Joel: quick update on async, progressing well. wasi-filesystem could be something someone could work on. getting two implementations wasmtime and jco (jsapi), https://github.com/bytecodealliance/wit-bindgen/pull/1082
- Timmy: when is a good time for c#, maybe after initial wit-bindgen pr merges (maybe this week). Might need some tweaks to core for other langauges.
- Timmy: is interesting in helping out with async
- James: did some work with Result types for exceptions, refactored a few files. Will begin work on returning spans and clean up memory clean up.
- Timmy: should make option default to null
- Joel: that makes sense
- James: wasmtime-dotnet update. Any thoughts on this https://github.com/bytecodealliance/wasmtime-dotnet/issues/329
- https://github.com/bytecodealliance/wasmtime-dotnet/compare/main...jsturtevant:wasmtime-dotnet:code-generation?expand=1
- Joel: common pattern in the rust world, so there is presedent. unfortunate we loose a bit of type info but that is probalby ok
- James: yes, there were some reasons for this desicsion by the tool
- Timmy: generally lgtm
- timmy: Do we gerneate the packages for Mac? Seem to work
- Joel: Can build from source but CI isn't in place, should work though

## Dec 11th - c#/.net meeting

| | |
| -------- | -------- |
| Attending |Joel Dice, Scott Waye, James Sturtevant |
| Note Taker |Joel |

- Scott: SingleAccretion is improving debug situation, e.g. stack traces, displaying values of various types. Scott looking at threading, which requires a separate build with GC.poll calls inserted as appropriate.
- James: Fixed a componentize-net build bug such that stuff wasn't being linked in properly. Also wasn't providing Linux-specific binaries on Linux; current fix is to document need for additional package dependency for that platform. Switched from wasm-compose to WAC. Working on TLS support; not sure how to support TLS server end-to-end; need to implement that to run various existing tests. Shouldn't be prohibitive, but non-trivial.
- Joel: client side is first priority
- James: What's next step for making the wasi draft official?
- Joel: Let's get it on the agenda for an upcoming WASI CG meeting, presenting the success we've had with the .NET implementation.
- Joel: WASIp3 async status: See https://github.com/orgs/bytecodealliance/projects/16. `wasm-tools` and `wit-bindgen` PRs ready for review; `wasmtime` PR needs more work; trying to get it ready by the end of the month. Will do a presentation tomorrow about implementation details.

## Nov 27st - c#/.net meeting

| | |
| -------- | -------- |
| Attending |Joel Dice, Timmy Silesmo, Scott Waye |
| Note Taker |Scott Waye |
- Joel Update on status of sockets, most is in runtimelab, some to come in future merge(s)
- Joel TLS - James is moving this forward and SQL Client prototype works
- Timmy - may have time to help move the TLS proposal forward.
- wasi-crypto not used as its future is uncertain.
- All - Threads, discussed where we are, and what is happening in Wasm and dotnet land.

## Oct 8th - c#/.net meeting

| | |
| -------- | -------- |
| Attending |James Sturtevant, Scott Waye, Pavel Savara |
| Note Taker |James Sturtevant |

Update:
- Scott: Merge to runtimelabs - contains http, needs some reconncile http stuff in llvm branch
- James: working on PR for tls. Will share work in progress later today
- upgrading to llvm 19, there is some work to upgrade in mono generically. AOT in wasi mono is going to be disabled most likely
- Scott: found new bug with llvm: https://github.com/llvm/llvm-project/pull/111278#discussion_r1791711922
- Paval: merged socket PR. looking at improving memory map for mono, maybe it will help with wasi?

## Sept 24th - c#/.net meeting

| | |
| -------- | -------- |
| Attending |James Sturtevant, Matt Fisher, Bailey Hayes |
| Note Taker |Bailey Hayes, James |

Update:
- James: Working SQL client impl, uses this is the issue where we were trying out the ssl implementation: https://github.com/WebAssembly/wasi-sockets/issues/100#issuecomment-2359402103, fork of TLS wasi-sockets proposal https://github.com/dicej/wasi-sockets/tree/ee3fe33c4ac70391d6b538e8ca92ff99704de11a
- Matt - worked on component docs adding c#
- found issue with componentize-dotnet
- Bytecode plummers summit, please sign up!
- https://bytecodealliance.org/articles/our-next-plumbers-summit-event
- We have c# bird of feathers talk/gathering on Friday

## August 27th - c#/.net meeting

| | |
| -------- | -------- |
| Attending |James Sturtevant, Scott Waye, Joel Dice, Matt Fisher, Bailey Hayes |
| Note Taker |Joel Dice |

Update:

- Scott: Got Linux build working in CI; no packages yet, but SingleAccretion will work on that
- Working on / thinking about threads (particularly interaction with .NET GC)
- Joel: Have been working on various sample applications -- primarily AspNetCore apps, including routing, serialization, SqlClient, Dapr, etc.
- Matt: Focusing on Dapr on Wasi
- James: new componentize-dotnet release with OCI support. Doing a demo of that at community call tonight. (https://www.youtube.com/watch?v=SHX3vxOysqM) Now builds WASIp2 components directly. Starting to pull in Mono .NET 9 support. Docs were a bit off, but got past that. Long paths break clang; took a while to figure out. Working around that by shuffling sample folders around. Will add linux support when packages ready.
- https://github.com/dotnet/runtime/issues/106845
- Pavel: regarding bugs in .NET 9 Mono; too late to get anything except critical items into final release. Anything non-critical must be fixed in main / .NET 10
- Still working on WASI pollable stuff. Wrapping that up soon.
- Sockets: for WASIp1, just had stub PAL (platform abstraction layer). Now updating PAL to use wasi-libc sockets. Only major limitation now is no control message support; shouldn't be big deal. Need to replace SocketAsyncEngine threading with single threaded event loop. Need to be able to translate file descriptors to resource handles; using Rust example as reference.
- Motivations: HTTP test server, Mono debug connectivity
- Bailey question: is the Mono debug stuff related to Ralph's demo.
- Pavel: that was a WASIp1 hack (demoware), but better socket support will make it more practical
- Bailey: working on goroutines in TinyGo. Currently using Asyncify, but want to use stack switching when available. TinyGo dwarf is totally broken. Need better solution.
- Pavel: Mono approach assumes an interpeter, so might not apply to TinyGo
- Bailey: concerned that every language pursuing its own option
- Pavel: regarding NativeAOT, Dwarf-based debugging very primitive and awkward so far
- Bailey: vision of lang-independent testing and mocking, plus native compilation of parts of system
- Pavel: does that mean building partially for e.g. x64?
- Bailey: seeing push for debugging in nodejs for JS since that's what folks are familiar with
- Maybe that means shimming/emulating nodejs APIs
- Bailey: BA plumbers summit coming up in Bellvue WA. Ralph planning to bring Brett Canon, plus VS Code, TS team, etc. folks
- Bailey: would Asyncify help with .NET
- Pavel: tried Asyncify with emscripten in browser; performance was unacceptable
- Bailey: highlighting .NET work in community stream, followed by a blogpost. Would like to mention people by name. Thanks to James for volunteering to demo.
- Bailey: Any blockers?
- Joel: Multi threading is a concern, we've avoided it just barely in c# but probably run into it here shortly.
- there might come a time where implemnting green threads or pre-emptive threading via stack switching.
- Making progress on tls interface for wasi-sockets by looking at nodejs and .net. This looks to be a good path forward. please make some comments on repo
- Exception handling in wasmtime would unlock alot of third party apps
- Bailey: Agree on all of these things!
- James: c api blocks .net and a few other languages
- Pavel: concerned about green threading approach (e.g. behavior differences due to lack of pre-emption). Would be confusing to .NET devs.
- Would rather wait for true, preemptive threads and stick with single-threaded async right now
- Still at "hello, world" toy stage now due to limited test coverage
-

## August 13th - c#/.net meeting

| | |
| -------- | -------- |
| Attending |James Sturtevant, Scott Waye, Joel Dice, Pavel Savara |
| Note Taker |Joel Dice |

Updates:
- Joel - worked on spin sdk, used parts of componentize-dotnet but didn't need all the things becuase they use the pre-built wit only needed wasi-sdk install
- https://github.com/fermyon/spin-dotnet-sdk
- May consider creating a wasi-sdk NuGet package along similar lines
- repo was created for this idea: https://github.com/bytecodealliance/cm-dotnet
- Pavel: probably couldn't use third-party nuget in runtime itself. Would be nice to share interface types among multiple packages
- Pavel: curious about C-API for wasmtime components. Interested in sandboxing MSBuild, which would require e.g. component support in wasmtime-dotnet.
- James - regarding wasm components in OCI: cargo has added support for consuming OCIs; James has added same to componentize-dotnet. Pulls from registry, generates code from WIT.
- https://github.com/bytecodealliance/componentize-dotnet/pull/32
- Pavel: would like componentize-dotnet to support Mono
- James: Mono wasn't working for a while, but we do want to support it
- Pavel: issues with DLL imports/exports in Mono, which requires generated C code to address. Should be working now, though
- James: Need .NET 9? Pavel: Yes - use preview 7
- James: currently using preview 4 in CI, but can update
- Pavel: Let me know if there are issues
- https://github.com/bytecodealliance/componentize-dotnet/issues/33
- James: inherited project from Steve Sanderson
- James: am on OS team for Azure; maintain component supporting Wasm in K8s
- James: does Mono/Wasm support Linux?
- Pavel: yes, should work (CI uses it)
- Pavel: eventually plan to support official MS build, e.g. .NET 10. Want to sync LLVM between browser and WASI targets; would enable reuse of static libs across targets. Latest SDK has ARM support.
- Scott: no wit-bindgen work; working on Linux build in CI; conflicts to be resolved
- Working on NativeAOT support for Wasm threads
- James - doing Wasmcon talk about C#/.NET tools
- Pavel: can help with demos
- Joel: looking at wasi-tls, designed with .NET and nodejs APIs in mind
- Pavel: regarding crypto: have implemented subset for browser. Was interested in wasi-crypto
- regarding multithreading: currently using ifdefs for browser to avoid multi-thread support. Have done some work to replace those with runtime exceptions instead in certain cases. Updating sockets API to support only async.
- regarding tls: currently using platform not supported attributes

## July 30th - c#/.net meeting

| | |
| -------- | -------- |
| Attending |James Sturtevant, Scott Waye, Joel Dice |
| Note Taker |Joel Dice |

Updates:
- Scott - NativeAOT-LLVM Linux build working on CI -- needs review, and might need to modify a YAML file to actually produce a package in addition to running the tests
- Joel - WASI-HTTP PR is green and approved; Pavel is working on the last (hopefully) upstream PR -- once that's merged we should be able to rebase Joel's PR and get it merged into runtimelab. Then we'll be able to update componentize-dotnet. Might also take a look at MacOS support in CI.

## July 16th - c#/.net meeting

| | |
| -------- | -------- |
| Attending |James Sturtevant, Scott Waye |
| Note Taker | Scott Waye |

Updates:
- James - wasmtime-dotnet 22 release
- Scott - Still struggling with LLVM build on linux for runtimelab, Joel will help if time allows.

Agenda:
- ended early

## July 2nd - c#/.net meeting

| | |
| -------- | -------- |
| Attending | Joel Dice, Bailey Hayes, James Sturtevant, Timmy Silesmo, Scott Waye |
| Note Taker | James Sturtevant |

Updates:
- Bailey - Community stream - talk about something awesome at next months
- Joel - steady progress on .net wasi http, adding tests to validate. Get by with smoke tests that exercise main use case.
- socket support not as easy as hoping. looking into ways to make it work well enough to test http
- James - wasmtime-dontnet, couple updates to compontize-dotnet
- Scott - working on getting the linux .net build released.

Agenda:
- wit files https://github.com/bytecodealliance/componentize-dotnet/issues/29
- no major objectsions
- make sure intillisense works
- Timmy - seen both ways, be careful with temporary folder as you might have clashes if using across projects
- Joel - making up world names might be able to avoid that scenario since they would be namespaced.
- c api changes for wasmtime embedding
- Might be a tool that genrates dll imports from c header files.
- https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke-source-generation

## June 17 - c#/.net meeting

| | |
| -------- | -------- |
| Attending | Scott Waye, Joel Dice, Bailey Hayes, Dan Chiarlone, James Sturtevant |
| Note Taker | Bailey Hayes |

Updates:
- **Joel**: updating http client in wasip2 compat runtime. Working tests working in wasmtime
- **Joel**: use wasi-libc use the C lib like on any other platform
- **Joel**: stack of wit-bindgen PR's including error handling. **Call to action** for opinions and feedback.
- **James**: Package published for wit-bindgen and the componentize SDK. Chose a namespaced name for that package. Working with David to get that namespace reserved on nuget. Prevents squatting.
- **James**: Tried wasi-http project. Found that it goes by file instead of folder.
- **Joel**: we haven't updated the CI to build/publish for linux yet.
- **Scott**: I started looking at that and updating some of the scripts and updating some of the dependencies. Next thing is updating the tests to run it on the pipeline. I'm happy to carry-on pushing that forward for the linux side.
- **Joel**: Working with Alex to provide arm/linux builds of the wasi-sdk.
- **James**: Once the linux package is available, I'll add that to componentize-dotnet.
- **James**: I'm working on a couple bugs, including exploring using wac instead of wasm-tools compose.
- **Joel**: Any things that wasip2 has but not in wasip1 that is relevant to wasi-libc aka wasi-sockets. For overlap, less priority because we have an adapter. We want the wasip2 target to natively support wasip2, but not the top priority right now.
- **Joel**: Still having trouble with return pointer not aligned error. I re-ran CI but still failed, but never been able to repro locally. The fix was around thread static.

Agenda:
- Wasmtime nuget package out of date and need a maintainer. James to be maintainer.
- **James**: Blog?

## June 4 - c#/.net meeting

| | |
| -------- | -------- |
| Attending ||
| Note Taker | |

Updates:

Agenda:
- componentize-dotnet released: https://github.com/bytecodealliance/componentize-dotnet/releases
- linux support? Does the compiler work on linux? is there a package?
- https://github.com/bytecodealliance/componentize-dotnet/issues/13
- https://github.com/bytecodealliance/componentize-dotnet/issues/7

## June 4 - c#/.net meeting

| | |
| -------- | -------- |
| Attending | Timmy Silesmo, James Sturtevant, Joel Dice, Dan Chiarlone |
| Note Taker | James Sturtevant |

Updates:

- Timmy - working on blog post
- James - Working on component tooling, project moved over to BCA, will need access BCA nuget
- Joel - working on async and await that is more idomatic: https://github.com/dotnet/runtime/issues/102894, can export async functions and it will just work
- will start port of httpclient for wasi
- Dan - looking to contribute again

Agenda:
- More idiomatic C# bindings
- proposal in zulip: https://bytecodealliance.zulipchat.com/#narrow/stream/407028-C.23.2F.2Enet-collaboration/topic/Ideas.20to.20make.20generated.20bindings.20more.20idiomatic/near/441773206
- highlevel langauges that have exception handling could return ok or throw, instead of results<ok> which is clunky in .net
- nested results/options is tricky
- Same for optoins
- (Timmy) - becuase of the nested situation, it is inconsistent so went other day first
- (Joel) - vast majority case it is not nested, make common case as idomatic as possible
- (james) - anyway to provider helper functions?
- (Joel) - option<option> is not used but result<result> is a bit more common
- can take look at python example
- look at wasi-http after this change, it looks alot more idomatic
- (timmy) - could we colapse all errors?
- (joel) - a possiblity but imagine this: result<result<foo, e1>, e2>
- how do you know what level of error are you catching?
- it will only ever throw one error
- (timmy) - lets try that
- (joel) - what if e1 are the same? Does the application code care which level the execption came from?
- (timmy) - you could maybe change interface
- (joel) - if it is wasi then maybe not,
- some cases you might be able to recover from one of the errors
- could maybe have level excpetion and extend the type
- enough of corner case we can iterate
- (timmy) - sounds pretty good, lets try it
- (joel) - record types for results is a bit harder since it is a struct, so probably need to keep it as type
- (timmy) - maybe there is something coming in .net 9? optional type in vnext
- httpclient
- there are some challenges with ssl
- sockets alone are not that useful, you need tls and many times need threads
- wasi doesn't don't have two of these things
- emsdk needed?
- pr is approved, just needs to be approved https://github.com/dotnet/runtimelab/pull/2592
- if targeting wasi not needed, browswer still needed
- (james) - do we need emscripten for the sdk tooling?
- (Joel) - not required
- (timmy) - agreeded
- (james) - can turn off once pr is enabled and see if it is requested

Agenda:

## May 21 - c#/.net meeting

| | |
| -------- | -------- |
| Attending | Timmy Silesmo, Bailey Hayes, Scott Waye, James Sturtevant, Aaron Robinson, Joel Dice |
| Note Taker | James Sturtevant |

Updates:
- Timmy - looking at mono approach again, need same support for initialization as we do on NAOT
- all the issues in c# runtime previous created have been resolved
- Working on blog post

Agenda:
- Bailey is trying to set up example for live stream next week. Make sure using NAOT solution.
- Need a blog post. Timmy is working on blog post showing components in vscode
- Can we do it on next Tuesday?
- Maybe we push it out, lets check in last week

- WAsmcon presentation (jstur)
- Scott/Timmy won't be able to make it
- maybe we have a BCA virtual session in August?
- Tooling Project (jstur)
- appache 2 llvm exception
- can we bring in steves? yes if under that license
- James will take this on
- initialization for mono
- need c component
- (Aaron) there are hooks that will start runtime
- (Scott) that is there an hooked up but there is some other issue around the startup routine re-entrance. Maybe more related wasm runtime
- (Aaron) makes sense we might not be able to solve that
- The issue here is the https://github.com/bytecodealliance/wit-bindgen/issues/777
- https://github.com/WebAssembly/wasi-libc/issues/452
- Getting NAOT running on Mac/Linux
- Joel might be able to help with Mac
- Developer workflows for NAOT
- What does it mean to only do dev on Windows?
- History caused the team to choose which platforms should be run
- Should be able to update some scripts and getting it working if dig in
- system.net http library
- https://github.com/dotnet/runtime/issues/98957
- https://github.com/dotnet/runtimelab/issues/2468

## May 07 - C#/.net meeting
| | |
| -------- | -------- |
| Attending | Timmy Silesmo, Bailey Hayes, Scott Waye |
| Note Taker | |

Agenda:
-

Updates:
-

## April 23 - C#/.net meeting
| | |
| -------- | -------- |
| Attending | James Sturtevant, Scott Waye |
| Note Taker | James Sturtevant |

Updates:
- [Scott] wasmtime dwarf debugging, merging llvm code merge so can test the alignment issue
- [James] starting simple Resource tests
-

## Mar 12 - C#/.net meeting
| | |
| -------- | -------- |
| Attending | Timmy Silesmo, Scott Waye, L Pereira |
| Note Taker | Timmy Silesmo |

Updates:
- [Scott] Bug has been identified in the compiler that causes heap corruption. PR created for Dwarf debugging support, can see integers and line steping. https://github.com/dotnet/runtimelab/pull/2514
-

Agenda:
-

- ## Feb 27 - C#/.net meeting
| | |
| -------- | -------- |
| Attending | Timmy Silesmo, Bailey Hayes, Scott Waye, Aaron Robinson |
| Note Taker | Bailey Hayes |

Updates:
- [Scott] Progress on DWARF work. Ongoing work for converging mono and CLR
- [Timmy] Variants and Results are now in the PR [wit-bindgen#807](https://github.com/bytecodealliance/wit-bindgen/pull/807) potentially bumping into generics bug where the symptom is a return pointer alignment error.
- [Aaron] forwarded Steve's email. We need to respond.
- If the community is interested, please contribute
- [e-mail]
- [Bailey]
- cm-dotnet, componentize-dotnet ready to be bootstrapped
-

Agenda:
-

## Feb 27 - C#/.net meeting
| | |
| -------- | -------- |
| Attending | Timmy Silesmo, Bailey Hayes, Scott Waye, Aaron Robinson |
| Note Taker | Bailey Hayes |

Updates:
- [Scott] Progress on DWARF work. Ongoing work for converging mono and CLR
- [Timmy] Variants and Results are now in the PR [wit-bindgen#807](https://github.com/bytecodealliance/wit-bindgen/pull/807) potentially bumping into generics bug where the symptom is a return pointer alignment error.
- [Aaron] forwarded Steve's email. We need to respond.
- If the community is interested, please contribute
- [e-mail]
- [Bailey]
- cm-dotnet, componentize-dotnet ready to be bootstrapped
-

Agenda:
-

## Feb 13 - C#/.net meeting
| | |
| -------- | -------- |
| Attending | Timmy Silesmo, Scott Waye, Bailey Hayes, L Pereira, Aaron Robinson |
| Note Taker | Bailey Hayes |

Updates:
- [Timmy] out sick but getting back into it and fixing everything for variant.
- [Scott] working on split DWARF, most of the DWARF sits in a separate package. Working on getting that into wasmtime. On the runtimelab, fork for experiments and where native AOT LLVM backend. agrecian doing a lot of work to improve the size of the compiled binary. Most of tests are passing, more than even some of the other targets. Now looking at improving performance.
- .NET team had some reorg. Runtimes are all now owned by a core set of people that are cross-cutting.

Agenda:
- [Timmy] All of the generated types like the Result type, should they be broken out into a separate C# library?
- [Bailey] bytecodealliance/cm-go
- [Scott] would save time and size by not duplicating.
- Options, Result, etc. Could be generic but not right now. Variant has a discrimiant union.
- [Aaron] There is discussion around discrimiant unions being supported.
- This would be really nice to make it interopt with things like WIT. But also aligns with Swift.
- Let's add our use-case to the discussion.
- [Timmy] Many commands and steps to run a component. Gathering and linking the component types... We likely will want a tool to create these components and have it work between native AOT and mono.
- [Scott] Composes components?
- [Timmy] Equivalent to componentize-py but for C#
- [Scott] Some C# code, some wasm code? Not sure how that would fit from a .NET point of view. We can add tasks in a project to do these steps. We don't want this fixed because this can be change (inputs). Fufill the interfaces at tool time.
- [Timmy] .o contains the component types. And right now it's a very manual process of first building the C# code then a Wasm module and then make sure it also runs. Goal: remove that step. If you aren't using wit-bindgen and actually create a project that you want to use, you have to do all this manually. Closest piece to this is the WasmSDK by Steve Sanderson. It runs the tools part of the build.
- We'd love to sync with Steve.
- interop-services part of the core library, the BCL. We put in Objective-C here for example. This could live in the repo and provide the lowest level types that build up this particular scenario. Follow the API and discussion process.
- runtimelabs => create a ancillary DLL/assembly. Everything we do here, this is what we're proposing to move into the runtime.
- Create a separate assembly with the types that we want and remove stuff as it becomes less interesting. Start with a base that is helpful from an architectural perspective and move as appropriate.
- Put another project under the Native AOT/LLVM branch. Under libraries, system runtime interopt services. There is already a JavaScript one there.
- Use a namespace like bytecodealliance.wit as NuGet file. Allows us to make progress and move forward. NuGet packages without Microsoft or other blessed entities.
- Then when we believe this should ship with the runtime, we will transition into the BCL and then deprecate BCA version.

## Jan 16 - C#/.net meeting
| | |
| -------- | -------- |
| Attending | Timmy Silesmo, Scott Waye, Bailey Hayes |
| Note Taker | Timmy Silesmo |

Updates:
- [Scott] Looking into the Options implementation. Can't nest nullables, looking into other ways, generics/ custom types. Merged PR for tuples, records. Looked into splitting out the dwarf into a seperate file.
- [Timmy] Implemented fixes for an additional 8 codegen tests including lists, raised bug reports with mono:
- https://github.com/dotnet/runtime/issues/96853
- https://github.com/dotnet/runtime/issues/96862
- https://github.com/dotnet/runtime/issues/96863
- https://github.com/dotnet/runtime/issues/96864
- https://github.com/dotnet/runtime/issues/96869

Agenda:
- Plumber's Summit
- [Scott] - https://github.com/dotnet/runtimelab/issues/2468
- [Timmy] https://github.com/dotnet/runtime/issues/96853

## Jan 2 - C#/.net meeting
| | |
| -------- | -------- |
| Attending | Timmy Silesmo, Scott Waye, Bailey Hayes, James Sturtevant, Aaron Robinson |
| Note Taker | Bailey Hayes |

Updates:
- [Bailey] 112 views on stream https://www.youtube.com/watch?v=fnAjxzMPPqk
- [Timmy] working on lists, variants, records
- [Scott] merge runtime with runtimelab. Merge upstream into runtimelab is a bit of a headache
- [James] Multi-return support which had tuples in it. Started on Options but needs basics like records. Fixed bug with multiple exports in the rust host library with tests.

Agenda:
- mono

## Dev 5 - C#/.net meeting
| | |
| -------- | -------- |
| Attending |Timmy Silesmo, Scott Waye, Bailey Hayes |
| Note Taker | Bailey Hayes |

Updates:
- [Scott]: PR landed, packages published with wasm import linkage attribute. It's in the compiler but not the runtime libraries. Temporarily we have to include the attribute in our own code.
- Chicken-egg problem for wasi-libc init. Solved via separate c file with a copy of realloc routine. Included as a part of the build as a C# file.
- The codegen when it generates the dll import tag, fills in the module name and adds the tag for the wasm import linkage. Essentially static linking.
- The mono team have been doing a few PR's in the native AOT repo to enable the mono repo to run with all of the browser integration.
- [Timmy]: Implementing the rest of the missing primitives in wit-bindgen. Should have those up and running very soon. Waiting a bit for resources, potentially a week or two project to complete this.
- Goal is to have something working to share by the livestream.
- Can run mono piece in wasmtime with flags: https://bytecodealliance.zulipchat.com/#narrow/stream/407028-C.23.2F.2Enet-collaboration/topic/wasmtime-dotnet.20and.20wasi.20threads/near/408478228 `wasmtime run -Sthreads=y -Spreview2=n`.
- https://github.com/bytecodealliance/wit-bindgen/issues/777 should be fixed
- Should be closable: https://github.com/bytecodealliance/wit-bindgen/issues/778
- https://github.com/bytecodealliance/wit-bindgen/issues/713 => Should be updated soon once primitives changes land.

Agenda:
- wasi-http
- Goal: HTTPClient class to be updated to wasi-http once other workstreams complete(?)
- Integrate bindgen in runtime or some other SDK?
- Specific SDK has been the POC's but we think it would be nicer to upstream.
- `componentize-csharp` ?
- https://github.com/webassembly/wasi-http
- Package manager system for components?
- Would C# provide a component registry and ability to generate?
- [wit-deps](https://github.com/bytecodealliance/wit-deps)
- `cargo component new --reactor --target wasi:http/proxy@0.2.0 --registry https://preview-registry.bytecodealliance.org http-test`

## Dev 5 - C#/.net meeting
| | |
| -------- | -------- |
| Attending | Timmy Silesmo, James Sturtevant, Scott Waye, Bailey Hayes |
| Note Taker | |
Updates:

Agenda:

## Nov 21 - C#/.net meeting
| | |
| -------- | -------- |
| Attending | Timmy Silesmo, James Sturtevant, Scott Waye |
| Note Taker | Bailey Hayes |

Updates:

- [Timmy]: Bringing mono support, should be able to add mono working relatively soon. There is a [patch](https://github.com/dotnet/runtime/pull/94615) waiting to be merged into the .NET runtime. This means we should be able to use attributes of WIT in the AOT native runtime.
- Does this require a release of .NET?
- Yes it's relatively straightforward to target the nightly builds and it has been officially released.
- .NET 9?
- Tagged as .NET 9
- [Scott]: Wasm import attribute, now wasm linkage import. This has been accepted. What this let's us fix from the native ATO and mono side is that we can now specify a different name for the import.
- [James]: Started re-enabling some of the codegen tests, and some parts of return-area for strings.
- One string for each import/export and question if it needs to be unique per string type.
- Re-organized the generation of the CS proj.

Agenda:

Notes:
- https://github.com/bytecodealliance/wit-bindgen/issues/713
- Mono helps by generating C bindings by registering functions that we're able to call to bridge the gap.
- Focused on the wit-bindgen side right now then later
- https://github.com/dev-wasm/dev-wasm-dotnet/tree/main
- To schedule a deep-dive on bindgen and how internals work for strings

Action items:

## Nov 7 - C#/.net meeting
| | |
| -------- | -------- |
| Attending | Timmy Silesmo, Aaron Robinson, James Sturtevant, Sven Bömer|
| Note Taker | James Sturtevant |

Updates:

- first pr merged that adds support
- Scott - runtime tests pr up
- James - verify code gen tests pr up
- timmy - mono runtime strings and numbers tests started
- Aaron - API approval for imports being reviewed today
- https://github.com/dotnet/runtime/issues/93824
- no functional
- post proccessing tooling, triming will remove this attribute at some point
- xml file can be used to remove the attribute

Agenda:

Action items:

## Oct 24 - C#/.net meeting
| | |
| -------- | -------- |
| Attending | Timmy Silesmo, Andreas Söderberg, James Sturtevant, Scott Waye |
| Note Taker | Timmy Silesmo |

Updates:
- [Scott Waye] Syntax for imports are now close to being submitted for review: https://github.com/dotnet/runtimelab/issues/2414https://github.com/dotnet/runtimelab/issues/2414

Agenda:
- Start outlining roadmap

Action items:
- Created a list of things that needs to be implemented: https://github.com/bytecodealliance/wit-bindgen/issues/713https://github.com/bytecodealliance/wit-bindgen/issues/713

## Oct 10 - C#/.net meeting
| | |
| -------- | -------- |
| Attending | Timmy Silesmo, Scott Waye, James Sturtevant, Aaron Robinson |
| Note Taker | Timmy Silesmo |

Updates:

Agenda:
- Discuss the outcome of Github issues discussion of the pros and cons of the different implementation options https://github.com/yowl/WitCSharp, https://github.com/dotnet/runtimelab/issues/2409.

Action items:
- It was decided that we will continue with the wit-bindgen implementation for C# in rust.
- [Timmy Silesmo] Find out if we can start merging the C# bindgen implementation into the wit-bindgen repository. (I spoke with Alex Crichton and we are clear to proceed wit this)
- [Scott Waye] Find and forward information to Aaron Robinson regarding how imports are linked in the native AOT LLVM implementation which is something that will also need to be added to the mono implementation. (https://github.com/dotnet/runtimelab/pull/2410)
- Discussed the potential of using Wizer https://github.com/bytecodealliance/wizer and it seems like a good fit for some use cases, especially for Mono.

## Sep 26 - C#/.net meeting
| | |
| -------- | -------- |
| Attending | Timmy Silesmo, Scott Waye, James Sturtevant |
| Note Taker | Scott Waye |

Agenda:
- Start the discussion for setting the goals of the sub-group

Action items:
- We agreed that the wit-bindgen implementation for C# should cover both Mono and the NativeAOT-LLVM use cases.
- [Scott Waye] Outline some of the pros and cons of the different implementation approarches https://github.com/danbugs/wit-bindgen-cs, https://github.com/Nor2-io/wit-bindgen-yowl (https://github.com/yowl/WitCSharp)