►
From YouTube: .NET Design Review: RESX
Description
00:-12:-42 - Approved: System.Resources API additions for non-primitive objects https://github.com/dotnet/corefx/issues/37041#issuecomment-485934735
E
Right,
so
all
of
this
issue
is
to
the
enable
compilation
of
windows
forms
applications,
use
non,
primitive
that
resources
and
doesn't
avoid.
We
want
source
compatible
compilation
because
in
the
sources
we're
talking
about
here
are
res
x-files
and
designer
generated
source
files
which
access
those
res
x
bottles.
E
Hard
hard
thing
to
solve,
because
you're
often
building
in
a
different
framework
than
what
you're
targeting
and
you
either
need
to
have
strong
contracts
for
cross
framework,
binary
serialization
or
have
some
way
to
sandbox
and
run
the
target
framework
that
the
app
is
targeting,
which
in
some
cases,
isn't
even
possible
if
you're
targeting
your
cross
targeting-
and
you
don't
have
that
runtime
yeah
in
general,
we
try
and
get
rid
of
any
sort
of
type
like
live
type
activation
on
our
builds.
It's
none
other
than
compilers
or
tools,
modern
ones.
E
Do
it
so
trying
to
fix
that
as
part
of
this
effort
and
I'm
also
trying
to
set
a
path
forward
so
that
we
don't
have
to
use
binary
format
or
for
non
primitive
resources?
So
at
some
point
in
the
future,
when
we
want
to
say,
add
an
API,
that's
a
kill,
switch
on
binary
format
or
than
an
app
could
opt
into
that
won't
cut
them
out
of
using
resources,
so
the
general
so
the
way
it
works
today
is
the
top
of
this.
E
Keep
scroll
down
will
have
it
you're
just
mixing
like
this
here,
because
we
need
more
screaming
this.
Didn't
I
think
all
right,
so
we'll
just
look
at
the
top
part
for
now.
So
there's
a
res
X
file
as
a
lot
of
elements
in
it,
their
key
value
pairs.
They
define
the
key
and
the
data
and
if
it's
a
non
primitive
resource,
so
key
data,
the
type
of
the
data
and
sometimes
mime
type
and
mime
type
is
the
format
in
which
the
value
should
be
interpreted.
E
There's
also
a
special
special
type,
which
is
a
res
X
file
ref,
which
means
the
value
isn't
in
the
res
X
file.
It's
often
some
other
referenced
file
relative
to
the
res
X.
So
that's
how
all
the
non
primitive
types
are
represented
today
in
desktop
they
get
these
these
files
or
as
X,
gets
reddened
by
ms
builds,
generate
resource
tasks,
and
then
it
uses
one
of
many
mechanisms
to
create
live
objects
inside
the
generate
resource
tapped
on
the
framework
it's
running
on.
E
So
it
goes
from
res
X
and
data
files
to
string
keys
and
object
box
values
in
the
case
of
the
primitive
ones,
but
but
actual
user
types
or
framework
types
that
are
in
objects
and
it
passes
those
two
by
two
resource
writer
and
then
resource
writer
for
four
types
that
it
understands
and
directly
write
those
to
the
resources
file
with
the
type
code.
Four
types
that
it
doesn't
understand.
It
writes
the
type
name
and
then
it
runs
the
the
live
object
through
binary
format
to
serialize
the
data
as
a
blonde.
So.
F
E
Right
if
it
happened
to
use
the
binary
format
or
mime
type,
that's
right.
It
goes
it's
a
live
object,
then
back
down
the
way
that
the
design
is
so
the
designer
is
what
chooses
which
format
to
write
a
lot
of
these
in
and
it
will
choose
the
type
converter
in
most
cases,
because
and
in
most
cases
it
will
choose
type
converter
of
string
because
that's
more
human,
readable
and
human
maintainable,
and
so
what
the
the
most
common
representation
for
or
non
primitive
types
is
as
strings.
E
Then
there
are,
there
are
a
couple
other
very
commonly
used
types
that
it
will
store
using
byte
arrays,
so
images
and
icons,
single
images
and
icons
are
stored.
If
they're,
not
reference,
files
are
stored
using
byte
arrays
that
are
passed
through
type
converter
and
then
anything
else.
It
doesn't
know
about,
gets
stored,
using
binary
format,
so
binary
format
or
there's
a
couple.
There's
a
couple
types
that
are
in
WinForms
that
commonly
hit
this.
E
Know
so
icons
in
resources
get
binary
format.
So
all
these
there's
no
type
code
for
an
icon
in
the
dock
resources
follow
and
so
any
icon
that
you
provide
will
when
it's
when
you
reference
it
through
a
file
rep,
it
gets
activated
to
a
live
object
through
activator,
create
instance
when
you,
when
you
reference
it
directly
from
the
res
X,
it
gets
stored
as
a
byte
array,
which
gets
passed
to
type
converter
for
creating
a
live
object.
So
is
this
different
than
the
win32
absolutely.
H
G
E
Through
this,
not
through
that
not
the
other
thing
we're
talking
about
today,
that
that
would
be
through
a
totally
separate,
totally
separate
pipeline
if
it
was
supported,
brick
brainer.
Are
you
aware
of
anything
in
the
build
that
would
be
writing
native
resource
streams?
I
mean?
Maybe
the
compiler
would
I
know
the
companion
I
think
with
their
little
T
version,
stuff,
yeah.
C
E
We're
not
talking
about
that
problem
at
all.
There
could
be
something
related.
I
would
be
really
surprised
if
the
compiler
used
this
pipeline
even
to
promote
them
to
the
native
resources,
because
that
would
imply
that
it
knew
how
to
crack
the
dock
resources
and
use
binary
for
matter
itself,
which
is
back
to
the
live
object.
Problem
in
item
I
would
be
very
surprised
if
CSC
did
that
yeah.
E
So
once
once
we
get
live
objects
and
generate
resource
defeat,
slurs
through
binary
format
or
writes
them
through
a
well-defined
to
a
well-defined
format
and
the
resources
file.
The
resources
file
is
has
gone
through
a
few
iterations.
It
appears,
but
in
general
you
can
think
of
it
as
a
header,
a
name
table.
E
Mapping
of
name
to
type
code
type
codes
in
enum
and
then
raw
data
blobs
with
some
understanding.
So
it's
so.
It's
essentially
header
collection
of
names,
collection
of
type
codes,
collection
of
data
and
efficient
ways
of
accessing
all
that
at
runtime.
What
happens
in
that
header
of
the
resources
file?
It
says
this
is
the
the
the
resource
reader
type
you
need
to
create
in
order
to
open
this
resources
file,
and
this
is
the
resource
set
type
you
need
in
order
to
represent
the
key
value
pairs
within
this
resources.
E
E
I
E
It
can
be
one
yeah.
It
still
supports
one
right
for
the
purposes
of
this
discussion.
We
don't
need
to
go
into
the
format
differences
again.
The
the
framework
types
still
support
reading
both
ok,
then
at
runtime
those
types
are
created.
They
wrap
the
resources
file
and
expose
the
resources.
All
right.
Are
you
doing
time,
I'm
gonna,
try
and
speed
this
up
a
little
bit
so
hi
the
proposed
change.
We
can
scroll
down
nope
and
it
waits.
You
know.
E
And
then
so,
the
most
change
just
cuts
out
in
all
those
I
D
serializers
from
them
as
build
tasks
so
before
when
it
was
deserializing.
All
these
things
to
live
objects,
just
as
serialize
them
back
using
binary
format,
or
we
say
we're
not
gonna.
Do
that
anymore.
We're
just
going
to
pass
the
three
suruli
data
directly
through
the
resource
writer
and
write
it
to
the
resources
file.
E
Now,
in
order
to
do
this,
we
have
to
write
one
more
piece
of
information
with
each
one
of
those
pre
serialized
blobs,
and
that's
which
mechanisms
should
you
use
for
deserializing?
Yes,
so
before
the
resource
reader
could
assume
that
it
was
always
using
binary
format
or
2d
serialized,
anything
that
wasn't
a
primitive
type.
Now
it
has
to
know
or
something
that
is
in
primitive
type.
How
can
I
deserialize
it
to
get
back
alive
object,
and
so
we
had
always
felt.
F
E
Yeah
or
essentially,
there's
an
res
X,
there's
a
you
could
think
of
it
like
mapping
the
mime
type
to
an
enum
and
then
storing
that
enum,
so
where
I
got
it
rather
than
creating
the
live
objects
in
the
res
X
reader,
we
just
read
the
raw
data
and
flow
it
through.
It's
not
quite
mime
type,
because
res
X
had
like
a
handful
of
different
ways
to
specify
how
to
get
like
objects.
It
appears
like
gets
an
open-ended
set,
but
the
actual
like
there's
just
if
else
statement
in
the
reader.
C
F
C
F
E
Yeah
I
think
so
yeah.
No,
we
have
to
in
order
to
make
this
work.
We
have
to
have
a
couple
new
types,
but
the
nice
part
about
it
is
we
don't
need
any
new
extension
points
so
that
the
activation
of
resources
already
has
a
hook
where
you
can
specify
what
what
type
of
reader
you
need,
and
so
we're
making
use
of
that
hook
in
order
to
provide
our
customer
a
nur
that
knows
how
to
handle
the
pre
serialized
formats,
so
there
there
may
be.
E
There
may
be
some
perf
work
to
do
in
order
to
ensure
that
run
time
purpose
on
par
with
what
we
got
from
binary
formatter,
but
in
general
the
approach.
There's
nothing
about
this
approach.
That
says
it
will
be
worse
at
the
limit.
So
if
you
fed
in
all
binary
formatted
data,
then
it
will
be
the
same
and
in
fact
the
writer
that
we're
gonna
propose
will
write
the
whole
format.
E
But
if
you
fed
in
type
of
converter
data
you're
now
going
through
the
type
converter
system,
which
has
different
characteristics
than
binary,
formatter
and
activator,
would
actually
be
faster,
general
cuz
it
it
doesn't
involve
all
the
had
a
really
a
in
reality.
It
probably
depends
it
depends
on
the
perk
of
individual
types,
instructor's
individual
types
converters,
but
hypothetically
you
could
achieve
something
that
is
even
more
efficient
than
then
binary
formatter
because
of
the
ability
to
like
we
could
extend
this
approach.
E
E
So
in
order
to
enable
this
scenario,
we
needed
a
new
resource
writer
which
could
communicate
the
pre
serialized
data
and
it's
types
and
then
the
new
resource
reader
also
needs
to
write
the
type
names
for
the
new
resource
reader,
and
it
turns
out
that
the
resource
reading
abstraction
in
the
framework
is
too
minimal
to
achieve
performance
on
par
with
what
we
do
today,
because
the
resource
reader
abstraction
is
just
a
numeration.
So
in
that
top
diagram,
you'll
see
there's
a
the
resource.
H
A
E
A
E
A
writer
and
a
reader
most
of
this
is
just
a
copy
of
what's
in
the
framework
types
already,
I've
commented
that
initially
I
tried
to
extend
the
framework
types,
but
because
this
needs
to
work
from
both
desktop
msbuild
inside
Visual,
Studio
and
core
msbuild
from
the
CLI
we
need
to.
We
can't
rely
on
framework
changes
to
to
the
inbox
types,
so
we
have
to
provide
a
solution
for
msbuild
that
works
on
desktop,
so
we
can't
just
we
can't
make
our
changes
depend
on
changes
to
resource
reader,
research,
writer,
sorry.
F
E
So
today,
today,
dotnet
core
can't
even
handle
I
can't
even
handle
compiling
these
resources,
because
a
big
it
does
not.
It
does
not
do
what
desktop
did
with
respect
to
creating
the
live
objects
in
the
building,
so
that
code
could
have
been
added
back,
but
then
it
would
be
loading
user
types
and
framework
types
in
the
build
framework
that
don't
match
the
target
framework.
E
So
when
building
from
Visual
Studio
you'd
end
up
trying
to
load
load,
potentially
or
user
types
in
the
desktop
process,
which
that
kind
of
happens
today
when
using
the
desktop
generate
resource
and
then
from
core,
you
would
end
up
trying
to
load
either
core
or
desktop
types
in
the
in
the
core
process,
so
that
we
could
have
added
that
stuff
back
today.
But
then
we
would
have
been
adding
back
this
bad,
build
pattern
and
we'd
also
be
adding
back
uses
a
binary
format
or
to
our
like
happy
path
of
the
this
new
app
model.
I
F
Nothing
there's
two
things.
It
sounds
like
there's
security
concerns
that
are
sort
of
existing
security
concerns,
but
also
reliability,
issues
where
you
may
end
up
to
serializing,
something
that
can't
actually
be
loaded,
because
it's
the
wrong
targeting
it's
using
API,
so
don't
exist
or
something
like
that.
Yeah.
C
F
F
E
Those
happen
to
have
those
don't
go
through
the
same
process,
so
all
the
primitive
types
of
special
handling,
but
at
that
type
of
that
same
concern
is
avail.
Is
there
for
any
serializable
type
for
a
lot
of
our
types?
We
ensure
we
try
and
ensure
around
tripping,
but
there
are
a
set
of
types
that
have
serializable
attribute
which
don't
round-trip
to
desktop
today
and
there's.
E
B
E
E
A
E
E
E
Technically,
we
could
build
all
the
functionality
we
need
on
top
of
that,
for
if
we
imagine
we
were
to
be
given
a
a
blob
of
data
and
we
just
inserted
our
type
code
at
the
beginning
and
then
put
it
in
a
new
byte
array
and
passed
it
to
this.
That
would
get
it
to
the
right
spot
in
the
resources
file,
but
a
it's
happy
to
to
do
that.
Much
I'll
patient
copying
just
to
insert
a
single
byte
in
the
beginning
and
B.
We
need
to
override
in
that
dot
resources
file.
E
We
need
to
overwrite
more
than
just
the
binary
data.
We
also
need
to
set
the
reader
type
name
and
resource
set
type
name,
which
is
why,
if
we're
gonna
do
that-
and
we
don't
expose
an
abstraction
to
do
that,
we
might
as
well
you
like
have
a
new
type
and
give
better
better
methods.
For
writing.
This
data
and.
E
On
this
concrete
type,
just
like
it
works
on
the
concrete
resource
writer
type
today,
okay,
there's
no
extensibility
point
in
them
as
build
as
far
as
I,
know
or
well.
The
desktop
code
had
a
bunch
of
different
readers
and
then
it
would
swap
out
different
writers,
depending
on
what
format
used
right.
Yeah.
C
C
J
D
E
G
E
E
Basically
you
would,
the
drive
type
could
define
whatever
members
it
needed.
It
would
call
add
resource
data
and
pass
in
whatever
context
it
needed
to
write
to
serialize
the
objects,
and
then
it
would
receive
the
call
back
through
write
data
when
generate
was
called.
So
that's
that's.
How
I
originally
tried
to
address
this
by
modifying
resource
writer
in
dotnet
Cory,
but
given
that
that
wouldn't
be
sufficient,
that
API
edition
I
I
have
that
as
as
something
I
want
to
get
out
of,
this
review
is
to
understand.
I
E
E
Adding
span
all
these
all
these
api's
need
all
these
api's
would
not
work
with
span
today,
because
they
need
a
copy.
You
could
add
memory
to
them.
But,
honestly,
this
scenario,
the
only
caller
for
this
API,
is
msbuild,
and
it's
going
to
be
allocating
all
these
single
use
objects
itself
and
it
will
be
like
there
won't
be
any
other
it
won't
be,
slicing
or
or
or
like
it
will
have.
It
will
have
actual
arrays
for
all
the
things
that
it's
reading
from
I
see.
J
You
know
a
skit
was
presumably
Emma's
build
whatever
best
tasks
you
try
to
use
span
over
the
support,
and
then
they
hit
a
point
with
the
API
that
they
are
talking
to
doesn't
contain,
span,
overloads
and
I
might
have
to
be.
The
substring
I
said
Ryan
material
as
the
string
again
yeah.
This
is
this
would
be
one
of
those
components.
Then,
at
the
bottom
of
this
stack,
I
see
yeah.
C
E
What
about
and
there's
actually
your
strings?
Your
strings
are
read
from
the
res
X
to
you
can't
control
the
encoding
of
the
res
X,
so
you
can't
really
return
a
spin
like
a
span
or
a
memory
to
the
region
of
of
the
encoded
data.
Yeah
yeah
you're
gonna
have
to
really
get
into
the
manage
string.
Anyways
well.
G
G
D
E
B
E
Just
to
deploy
as
a
modular,
furthermore,
all
this
is
sharing
code
yeah,
so
we
don't
want
to
fork
our
reader
and
writer
implementations
if
I
could
I
would
have
extended
them.
Yeah
I
cannot.
So
it's
all
shared
source
with,
what's
already
present
in
core
Lib
and
system
resources,
writer
and
doing
a
bunch
of
API
innovation
here
is
going
to
churn
that
code
and
cause
risk
to
those
existing
types.
I
would
prefer
instead,
given
the
very
constrained
usage
and
the
nature
that
like
this
is
an
unblocking
position,
it's
not
like.
J
E
No
one
would
use
it
in
the
initial
release.
We
could
always
add
it
later,
not
having
it
now
introduce
Berg
having
it
now.
What
introduce
the
dependency
so
I
buy
that
the
place
where
we
want
to
make
that
effort
is
not
here.
It's
in
the
resource,
reader
resource
writer,
abstractions
in
the
framework
yeah
and
only
four
core
three.
Those
could
definitely
use
some
spam
love
right,
but
this
is
not
the
place
to
start.
E
This
is
not
where
you're
going
to
get
the
bang
for
your
buck
buck
area
so
I,
even
even
this
section
of
so
even
the
protected
members
that
I
put
here
I'm,
not
necessarily
recommending
we
put
those
here.
Ideally
we
add
those
to
the
inbox
types,
and
then
we
could
build
this
on
top
of
those
inbox
types
in
the
future.
The
only
reason
why
I
put
it
here
is,
if
folks
want
this
to
be
an
experiment
for
how
we
might
add
extensibility
in
the
future.
B
E
That's
a
prototype
name
looks
but
yeah
they'll,
just
swap
so.
Msbuild
today
will
swap
their
use
of
resource
writer
to
pre
serialize
resource
writer
and
then,
and
they
will
call
these
today.
They
they
already
call
the
add
resource
members
for
the
primitive
types
and
now
they'll
be
able
to
call
these
new
add
star
resource
data
members
for
the
non
primitive
types.
So
it's
designed
to
be
a
basically
go
up
and
drop
in
replacement.
Presumably.
C
E
E
C
Current
situation
is
that
on
on
desktop,
we
use
res
X
resource
reader.
Get
live
objects
do
that
whole
dance
on
core.
The
current
understanding
is
a
very
basic
understanding
of
a
res
--ax,
the
res
X
file
that
basically
only
understands
strings.
It
just
passes
those
strings
that
we
got
from
reading
the
XML
into
the
resource
writer
to
be
serialized.
The
plan
for
this
would
be
to
add
a
new
flag
that
we'd
flip
when
we're
compiling
for
core,
regardless.
That
would
use
the
new
understanding
of
res
X
and
this
new
writer
and
to.
E
E
E
It
hasn't
been
settled
as
to
what
the
defaults
will
be
for
next
standard,
like
that
I,
don't
think
that's
something
we've
talked
about,
I
think
it's
relevant
to
consider
the
default
being
off
yeah,
that's
plausible,
and
then
that
way,
if
someone
opts
into
it,
they
they
will,
they
will
opt
in
and
in
knowing
that
they
have.
This,
in
fact,
like
the
way
that
we
had
been
discussing
this
before
was
not.
J
E
So
ad
resource
data
is
a
straight
pass
through
that's
already
present
on
resource
writer
right.
If
anything,
that's
the
one
that
I
would
remove
from
resource
writer
from
this
from
this
type,
because
it's
it's
not
encoding
the
the
D
serialization
method.
The
difference
between
the
three
sets
at
the
bottom
is
all
about
the
D
serialization
method
used
at
run
time.
So
it's.
E
How
do
I
interpret
these
these
bytes
of
data,
it's
for
add,
binary,
formatted
resource
data,
it's
a
it's
interpreted
as
a
binary,
formatted
object,
so
binary
format
or
deserialize
is
used
at
run
time
stream.
Resource
data
is,
we
will
be
interpreted
as
a
stream
at
runtime
and
FASTA
activator,
create
instance.
What
does
that
mean
like?
What
do
you
mean
by
a
just
interpret
in
the
stream?
Then
the
data
will
be
wrapped
in
a
stream
and
pass
to
activator,
create
instance.
I
E
E
That
being
and
bussing
of
the
stream,
we
need
to
differentiate
stream
as
a
primitive
type.
It's
considered
a
primitive
type
for
resources
right,
so
that
add
resource
that
takes
a
stream
up
above
that
will
cause
resource
reader
to
give
back
a
stream.
This
one
below
add
resource
stream
data
yeah.
It's
gonna,
give
back
tightening
right
cuz.
It
calls
activator
created
since
on
type
name
pass
in
the
screen.
Yeah
I've
added
both
overrides,
presumably
only
the
second
one
is
needed,
because
the
way
that
msbuild
will
use
this
is
it
will
open
a
handle
to
the
file.
E
Sorry
open
a
file
stream
to
the
file
and
then
pass
the
file
stream
in,
but
I
I
added
the
binary
value
as
well,
because
it
sometimes
it's
easier
for
test
naming
one
time,
but
that's
an
optional
and
I
I
just
tried
to
to
match
some
of
the
the
I
that
we
had
before
with
type
converter.
The
actual
overload
matters
because
it
determines
the
from
type
when
type
converters
invoked
at
runtime,
so
in
the
latter
two
they're
either
calling
that
they
get
the
type
converter
for
type
name
and
convert
from
either
by
the.
G
E
Will
be
a
question
for
the
designer,
so
this
will
support
anything
you
throw
at
it.
Okay,
so
that's
exactly
what
we
need
to
start
looking
at
in
the
designer,
so
that
if
we
want
to
get
rid
of
binary
formatted
resource
data,
then
what
what
we
could
do
is
the
designer
could
start
insisting
on
type
converters.
The
designer
has
to
deal
with
live
types.
It's
a
total
purpose,
it's
to
visualize
the
user,
the
users
type.
So
so
it
will
be
able
to
probe
for
type
converters
and
it
could
say,
hey
my
default
it.
E
My
fallback
is
now
gonna
be
a
type
of
converter
for
byte
array.
If
you
don't
give
me
like,
unless
you
set
some
flag,
I'm
gonna
assume
that
this
thing
needs
a
type
converter
for
byte
array.
If
you
don't
have
it,
I
can
display
an
error
message
and
then
once
we
start
doing
that,
then
people
can
hook
into
the
system
and
in
a
slightly
safer
way,
yeah.
G
E
If
we
wanted
to
even
allow
for
more
extensibility
here,
if
we
have
unsealed
types
and
we
have
those
virtuals,
people
could
write
their
own
writer,
but
we
don't
I
would
say,
msbuild
isn't
going
to
know
about
that.
We're
not
designing
any
sort
of
plug-in
system
for
msbuild.
So
probably
the
the
right
extension
point
for
for
user
types
right
now
is
type
is
type
converter
and
that
actually
is
in
line
with
what
WPF
does
so
they
fall
back
to
type
converters
or
or
user
types
in
bandwidth
are.
G
E
Okay
component
models,
so
we
we've
treated
it
in
core
FX
for
historical
reasons:
we've
treated
it
as
kind
of
like
a
a
island
like
we
don't
want
to
take
dependencies
on
type
converter,
mainly
because
of
the
number
of
static
references
it
pulls
in,
because
it
tries
to
catalog
all
the
all
the
types
and
knows
about
all
the
types.
So
you
bring
in
type
converter
to
an
app
that's
not
already
using
it,
and
it
brings
in
a
lot.
Yeah
wind
forms
is
built
around
type
converter,
all
right
type
descriptor.
E
Ideally,
the
thing
that
we
would
probably
recommend
to
people
is
don't
rely
on
the
the
resource
reader
for
creating
your
live
objects.
So
if
you
really
want
to
do
something
exotic
with
resources,
build
it
on
top
of
it
instead
of
underneath,
because
that
way
you
actually
have
better
access
into
the
to
the
functionality,
and
you
could
do
the
right
kind
of
caching
that
you
want.
You
don't
have
to
rely
on.
Whatever
assumptions
were
made
in
the
runtime,
you
can
rely
on
the
runtime
for
doing
the
primitive
stuff.
G
E
We
could
do
that.
The
challenge
with
doing
that
right
now
and
and
buying
that
to
this
feature
is
that
it
would
be
difficult
to
do
that
and
make
it
source
compatible
with
desktop
right.
So
you
one
thing
you
can
imagine
is
if
we
threw
all
the
type
converters
and
same
assembly
as
this
and
then
moved
it,
then
it
could
be
like
this
new
pack
that
we
shipped
a
desktop
and
then
that's
that's
a
reasonable
path
forward
for
getting
off
of
binary
format
or
even
stop
for
this
scenario.
So
it's
not
doesn't
preclude
that.
E
J
E
E
J
E
E
E
J
E
H
E
You
know
disparate
disciplines
in
the
street
dispose
so
generate,
will
actually
what's
the
street.
Well
close.
The
stream
dispose
without
calling
generate
will
close
to
strength
as
well
yeah.
This
thing
will
wrap.
It
will
wrap
the
stream
that
it's
writing
to
and
then
it
keeps
it
handle
to
all
the
screens
that
you
pass
in
I,
see.
E
Okay,
so
sealed
but
I'll
add
resource
data.
We
can
cut
out
the
type
name
convert
I
Raynor.
Do
you
rely
on
the
type
name?
Converter,
Oh,
no
I,
don't
think
so
yeah
we
can
cut
that
out.
That's
for
well,
let's,
let's
say
that
that's
TBD
based
on
the
desktop
implementation
of
this
of
of
msbuild
right,
because
you
yeah,
you
don't
rely
on
in
court,
but
it
might
be
relevant
for
that's
not
for
so.
J
E
G
E
E
J
E
I
could
rename
I
see
so
I
think
add
binary
format.
A
resource
data
is
pretty
clear
as
to
what
it
does
at
stream.
Resource
data
I
heard
comments
about
what,
if
I
change,
that
to
add
activator
resource
data
and
then
I
only
took
a
stream
that
way
it
behaves
sort
of
similar
to
add
type
converter
resource
data
right,
because
the
type
the
type
that
you're
passing
in
determines
the
type
which
eventually
gets
passed
to
activator
right
and
then
perhaps
in
the
future.
E
We
could
imagine-
and
I
was
thinking
about
this
this
morning,
because
a
lot
of
the
ways
that
res
X
writes
the
strings.
If
you
had
a
very
long
string,
it
would
be
a
lot
larger
in
string
format
than
in
the
binary
format
of
data.
But
if
we
could
switch
to
using
an
activator
based
convention,
then
we
could
still
have
a
nice
human
readable
string
and
then
we
could
like,
for
instance,
if
it's
for
like
point
today,
point
is
X
comma
Y
in
a
string
and
then
I
with
this
change.
It's
going
to
get
stored.