►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
C# and Wasm Interface Types: Hands Across the C - Ivan Towlson, Fermyon
Microsoft's .NET WASI preview provides a way to compile C# and F# applications to Wasm. But out of the box it doesn't provide a way to interoperate with Wasm interface types, either exporting interfaces from a component or importing implementations from a host or other Wasm modules. Yet interface types are becoming the standard for hosting and composing Wasm modules. So how can C# developers write components for this ecosystem? And how can platforms and plugin hosts make themselves accessible to C# developers? In this session, Ivan will dive deep into code to show how you can use C code and the .NET embedding API to bridge between a Wasm interface and .NET user code. The session covers both: * How to export a WIT interface from a .NET library, so it can function as a plugin or guest module * How a .NET library can access a WIT interface defined by a host or another Wasm module (written in any language)
A
A
It
was
a
monolith
that
kind
of
got
gradually
priced
apart,
but
always
stayed
pretty
much
tied
to
its
own
proprietary
runtime
and
as
things
like
Java
began
began
competing
with.
It
mostly
wanted
to
do
another
language,
and
they
figured
out
that
if
they
were
going
to
do
that,
they
should
share
a
run
time,
because
then
you
could
have
lots
of
other
languages
on
those
as
well,
and
thus
was
the
common
language.
Runtime
born,
also
known
because
marketing
at
the
time.net.
A
It
was
closed
Source,
but
it
was
a
specification
submitted
to
ecma
and
that
meant
that
other
implementers
could
come
along
the
mono
project
implemented.net
for
Linux
electron,
and
we
don't
like
to
talk
about
this
too
much.
There
was
Silverlight,
which
was
a
cross-platform
implementation
of
a
subset
of.net
to
run
in
the
browser.
A
And
then,
when
Microsoft
began,
embracing
open
source
a
bit
more,
there
was.net
core,
which
is
now
actually
the
primary
development
stream
of.net.
That
is
fully
cross-platform
Linux
Mac
Windows
and
is
a
a
much
smaller
refocused
version
of
the
the
framework.
And
then,
a
few
years
ago,
Steve
Sanderson
from
Microsoft
figured
out
that
they
could
compile
the.net
runtime.
They
could
compile
this
this
this
execution
environment
to
webassembly
and
run
it
in
the
browser
and
that
was
called
Blazer.
A
That's
the
classic.net
model
when
we
take
that
to
Blazer.
All
we
need
to
do.
All
we
need
to
do
is
to
recompile
the
execution
engine
from
targeting
machine
code
from
from
from
from
x86
instructions
to
wasm
instructions,
and
then
you
get
an
execution
environment.
That's
able
to
run
these
IL
instructions
in
the
browser.
A
Now
recently,
Steve
Sanderson
has
added
wazzy
support
via
a
project
called
the.net.
Ysdk
experimental
project
should
probably
stress
called
the.net
was
the
SDK,
and
this
is
going
to
allow
dotted
applications
to
run
to
be
compiled
to
Asm
on
the
the
server.
Now
notice,
once
again,
still
we've
got
the
IL
blobs,
the
dlls,
the
assemblies,
but
now
we've
got
a
wasi
host,
such
as
wasm
time
instead
of
a
browser,
and
it
means
that
the
standard
Library
The
Base
Class
Library,
can
do
things
like
file.
A
What
we
need
is
something
more
like
this,
where,
in
addition
to
the
IL
blobs
talking
to
each
other,
they
can
also
talk
to
services
that
are
export.
They
can
import
Services
exported
by
The
Host
and
they
can
provide
callable
interfaces.
The
host
can
enter
instead
of
just
the
the
start
point,
and
this
is
coming
back
to
Luke's
world's
concept.
The
the
host
now
is
sort
of
it
is
or
implements
a
world
which
the
dotnet
components
live
in
and
satisfy
the
the
contracts
of
so.
A
This
opens
up
additional
potential
because
we
can
now
talk
to
other
components
in
that
same
world
via
their
contracts,
and
that
means
we're
not
limited
to
talking.net.net
or
dot
net
host.
We
can
also
talk
for
example.net
to
job.
We
can
use
the
work
that
Joel
did
to
build,
say
some
business
rules.
We've
got
in
Java
into
a
wasm
module
and
then
we
can
have
our
net
application
using
those
business
rules
via
the
wasm
interface.
A
A
So
that's
the
that's
the
rainbow
dream,
but
there's
always
a
butt.
So
if
we
look
inside
the
Wazi
SDK,
what
we
find
is
that
it's
got
it.
There
was
the
SDK
hijacks.net
compilation.
Instead
of
just
putting
out
a
a.net
dll
an
IL
blob,
it
actually
puts
out
a
it
actually
adds
in
some
C
code,
which
gets
compiled
to
wasm,
and
it's
the
C
code
that
talks
to
that
loads.
The.Net
blobs,
as
opposed
to
the
the
Raw
vs,
so
where's,
the
SDK
exposes
an
underscore
start
or
a
c
main
method.
A
Now,
within
that
export
entry
point,
we
need
to
launch
the
VES
and
that
can
then
launch
the
user
implementation
and
find
the
right
entry
point
for
that,
and
then
those
can
call
back.
We
can
map
c-sharp
libraries,
c-sharp
methods
onto
C
methods,
and
those
can
then
call
back
through
the
the
widget
the
generated
generated,
import
layer.
A
A
A
A
A
You'll
see
it's
exporting
this
function
from
the
Seeker,
that's
going
to
get
compiled
down
to
wasm
and
it's
going
to
become
a
wasm
export
and
inside
that
function
does
some
marshalling
and
then
it
calls
this
function
which,
if
we
were
to
look
through
the
C
code,
we
will
find
that
that
function
was
not
defined
anywhere.
We've
got
to
Define
that
and
to
do
that
we
will
have
some
custom
C
code,
which
I
will
add.
A
There,
so
what's
this
doing
well,
you
can
see
there's
a
bunch
of
hash
includes
of
the
the
mono
Source
there,
so
we're
loading
we're
going
to
be
loading.
The
the
mono
Source
I'll
scroll
down
to
the
the
end
here.
So
this
is
the
missing
function.
This
is
going
to
get
linked
by
the
the
clan
compiler,
which
is
invoked
by
the
wasi
SDK.
A
This
is
going
to
get
linked
with
that
export,
whitbine
gen
export
code,
and
that
means
that
when
our
host
calls
that
export,
we
will
go
through
that
c
marshalling
code,
and
we
will
end
up
here
and
what
does
this
do?
Well,
it
does
some
sorcery.
It
does
some
stuff.
We
prefer
not
to
talk
about
because
that's
supposed
to
be
internals,
but
it
doesn't
work.
A
If
we
don't
do
that
and
then
it
initializes
the
CLR
it
loads,
the
runtime
it
does
some
stuff
called
attaching
internal
calls
which
don't
need
yet
so
we
can
probably
get
rid
of
that
and
it
tries
to
find
an
entry
point
in
the
user
code.
Now.
This
is
where
things
get
a
little
bit
sticky,
because
there's
no
obvious
entry
point
as
there
is
with
Main.
A
A
A
A
A
A
A
So
let's
see
what
we've
see
what
we
missed.
Okay,
what
we've
missed
is
that
c
strings
are
not
DOT
net
strings.
So,
if
I
look
in
my
console,
Dot
h,
the
type
that's
being
passed
across
the
boundary
is
one
of
these.
It's
a
it's
a
pointer
and
a
length
and
that's
not
a.net
string,
so
I
need
to
actually
map
something
that
corresponds
to
I
need
to
have
something
that
corresponds
to
that
on
the
C
sharp
side.
So
things
can
pass
across
correctly.
A
That
represents
that
canonical
ABI
format,
so
you
can
see
there.
It's
got
the
the
pointer
and
the
length
and
it's
marked
as
sequential
layout,
and
what
that
means
is
it's
telling
the
c-sharp
compiler
that
that
struct
should
adopt
the
the
C
ABI.
It
should
be
laid
out
in
memory.
According
to
the
C
API.
A
A
A
A
And
we'll
try
building
that
again
and
now
the
C
sharp
has
built
successfully
and
what
it's
doing
is
it's
building.
It's
built
those
dlls,
including
all
the
dependency
dlls,
and
it's
now
trying
to
link
those
with
the
the
C
code
and
when
it
fails,
it
does
tend
to
produce
these
very
long
error
messages
all
right.
This
is
a
little
bit
of
a
silly
issue,
that's
caused
by
whip
by
and
Jen
the
way
that
it
generates.
These
things.
A
A
A
Okay,
I
will
switch
back
to
my
pre-prepared
one.
Thank
you
for
your
patience,
but
I
was
getting
a
bit
over
optimistic
there.
So,
let's
switch
back
to
dotnet,
guest
and
Dot
net,
build
that
one,
and
this
is
what
you've
seen,
except
without
the
the
mistakes.
It's
the
same
same
code
that
you've
you've
just
been
looking
at.
A
A
A
A
A
All
right
does
that
make
sense.
I'm.
Sorry,
that's
been
a
little
bit.
I've
shown
that
in
a
slightly
confusing
way
does
it
does
it
make
sense
to
people
how
that's
hanging
together
that
we've
got
the
the
C
generated
code,
forming
the
interface
to
the
to
the
host
to
the
world
exporting
and
importing
things
this
binding
layer
of
C
interrupts
stuff
like
the
interop
string
and
the
internal
call
melding
that
into
the
c-sharp.net
world,
and
then
the
application
being
able
to
handle
those
callbacks
and
call
out
through
the
interop.
Yes,.
A
A
A
The
the.net
design
is
is
aimed
at
amortizing
startup
time
you,
you
expect
to
be
a
long
running
process.
It
takes
a
while
to
spin
up
the
runtime,
maybe
sort
of
30
40
milliseconds-
something
like
that.
But
then
each
call
should
be
quite
quick,
but
in
a
in
a
western
environment
in
a
world
like
event
where
your
export
is
being
called
quite
frequently,
you
don't
have
the
res,
it's
wasteful
to
spin.net
up
every
time.
A
So
what
we
can
do
is
we
can
in
our
wiser
function
we
can
start
the
run
time
load.
The
assemblies
inject
a
fake
request
to
warm
up
the
actual
Handler
and
then
capture
the
state
of
the
module
at
that
point,
and
that
means
that
every
request
that
goes
to
that
captured
version
of
the
module
is
going
into
something
that's
already
pre-warmed
and
ready
to
go.
So
it's
not
a
great
workaround
and
there
are
some
weird
side
effects
which
are
documented
in
the
spin
SDK,
but
it
it
certainly
helps
a
lot
in
a
lot
of
cases.
A
Stability
is
a
problem
that
I've
hit
to
the
point
of
banging
my
head
against
the
desk
a
few
times
we're
doing
some
kind
of
Fairly
hairy
sea
magic
here
in
a
experimental
environment
and
I've
sudden
hit
a
few
kind
of
mismatched
signature
which
I
just
don't
have
a
lot
of.
Those
do
seem
to
be
down
to
wiser,
but
again,
not
fully
understood.
Yet
size
is
a
bit
of
a
problem
at
the
moment.
A
A
whole
lot
of
Western
linear
memory,
which
we've
had
to
work
around
future
versions
of
the
Westy
SDK,
should
improve
that
and
the
one
that
you
so
rightly
identified
convenience
you
do
not.
You
do
not
want
to
go
through
what
I
just
went
through
on
a
regular
basis,
even
if
you
know
what
you're
doing
the
the
the
process
of
generating
the
C
files
setting
up
all
the
linkage
linkages,
writing
those
interop
bridges
and
writing
the
the
gunky
stuff
on
the
C.
A
C
sharp
side
is
a
mess
where
we
would
like
to
be
is
to
be
able
to
generate
those
C
sharp
bindings
directly,
which
would
be
a
whip,
buying
gen
back
end
and
then
somehow
from
there
generate
the
sea
bridging
or
the
the
equivalent
ABI
level,
bridging
stuff
which
might
be
doable
within.net
or
we
might
be
able
to.
We
might
need
to
use
something
like
Rosalind
Source
generators
to
spit
out
that
c
code
and
make
sure
it
gets
Linked
In,
so
some
definite,
tooling
improvements
that
absolutely
need
to
be
done
before
this
can
be
production
ready.
A
And
with
that
I'll
say,
go
play
with
it.
We've
got
an
SDK
for
work,
working
with.net
with
c-sharp
in
spin.
You
can
just
add
it
as
a
nuget
package
and
use
it
in
spin
today,
but
I
hope
what
I've
shown
you
is
also
relevant,
even
if
you're
not
interested
in
in
working
with
net
I
hope
that
this
is
Illustrated
a
technique
that
you
could
be
able
to
use
for
other
languages
for
supporting
those
worlds
and
interfaces
in
other
languages
that
don't
compile
down
directly
to
Azam
that
that
live
inside
these
run
times.
A
And
with
that
I'll
leave
you
some
links.
The
the
working
code
is
in
that
top
repo
the
Western
day,
22
one,
the
spin.net
one,
which
illustrates
a
more
real
world
use
case
and
illustrates
the
wisering
technique,
is
instrumental
in
SDK
and
I
need
to
acknowledge
the
foundational
work
that
Steve
Sanderson
has
done
with
the
Wazi
SDK.
Thank
you
very
much,
foreign.
B
All
right,
our
next
two
speakers
are
no
strangers
to
open
source
by
any
means.
Daniel
is
a
Serial
entrepreneur
in
his
own
right
and
was
the
past
founder
of
vietnami
and
Rafael
among
his
many
other
things,
they're
both
now
in
the
VMware
Office
of
the
CTO
I
worked
on
KDE
for
like
forever
right,
like
16
years
long
time,
so
blame
him
for
all
the
Linux
presentation
that
she's
not
working
today,
I
think.