►
From YouTube: 2021-04-20 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Okay,
if
you're
on
the
call
already
please
write
your
name
in
that
the
list
can
start
in
another
minute.
A
A
So
this
is
a
bug.
Report
opened
a
few
days
back,
it
looks
like
we
are
using
the
baggage
header
name,
not
following
the
spec.
It
was
supposed
to
be.
Like
small
caps,
I
mean
lowercase,
we
are
using
a
p
cap.
A
I
don't
know
whether
there
are
any
like
serious
issues
with
this,
because
it
looks
like
for
like
queuing
systems.
This
is
case
sensitivity,
not
necessarily
for
http,
so
I
think
it
should
be
like
to
let
us
say
bug
and
fixed.
I
mean
if
there
are
any
other
opinions,
I'm
happy
to
hear
that
also
the
question
is
like:
should
we
even
consider
it
as
a
like
worthy
of
like
a
hotfix
or
what
ending
a
1.0.1
release
as
opposed
to
the
1.1
which
is
coming
next?
A
I
mean
if
there
are
no
opinion,
I
mean
objections.
I'll
just
do
a
bug
fix
and
make
it
part
of
1.1,
since,
like
only
one
person
has
reported
it
as
a
issue,
I
would
say
it's
not
really
worthy
of
doing
a
1.0.1.
A
A
Let
me
ask
ya:
so
there
is
a
bunch
of
packages
in
contrib
repo
which
haven't
been
released
in
a
while,
it's
mostly
on
like
me
or
sean
or
like
has
access
to
do
it.
So
it's
not
automated.
So
it's
like
little
bit
of
like
manual
talk,
so
this
is
just
an
faa
like
we
will
be
doing
a
release
sometime
this
week.
I
think
two
or
three
releases
should
be
done,
must
transit,
elastic,
search
and
add
framework.
A
I
will
be
doing
that
for
the
contrib
and
the
recipr
which
prashant
sent
out
to
like
this
down
the
process
to
be
followed
for
contrary
repo,
for
doing
the
release.
I
think
I
briefly
looked
at
it.
I
will
continue
to
look
at
it
and
refine
it.
While
I
am
doing
the
release
today
of
this
week,.
C
A
Be
like
actually
trying
it
out,
so
I
mean
I'll
try
to
follow
this
asses
and
see
if
I
can
offer
some
suggestions
cool
and
then
there
is
a
special
package
which
is
in
the
main,
repo
open,
telemetry
extension
start
hosting
package.
A
So
when
we
release
all
the
core
packages,
we
left
this
out
primarily
because
it
was
not
ready
for
like
one
double
quality.
We
have
like
at
least
five
to
seven
issues
listed
against
this
package,
so
it
was
not
released
like
we
recently
have
a
improvement
like
michael
submitted,
a
pr
which
added
da
support,
but
we
still
have
like
open
issues,
so
we
haven't
released
it.
A
So
I'm
trying
to
like
address
certain
issues
like
known
issues
in
this
package,
with
the
intention
that
once
we
are
done,
we
can
just
release
a
one
dot
version
of
that
package.
It's
not
blocked
by
anything
in
the
spec,
because
this
is
a
pure
tornado
triple
that
dotnet
repo
should
not
have
spec
issues,
so
we
should
be
able
to
like
proceed
quicker
on
this
one.
Unlike
any
other
instrumentation
packages,
we
still
don't
have
any
eta.
For
when
can
we
release
instrumentation
packages
as
1.0?
A
Could
vary
will
be
like
midsummer
or
something
so
no
eta,
it's
just
blocked
on
respect
yeah.
Another
like
small
update
from
me
is
we
did
discuss
about
like
assigning
maintainers
and
approvers
to
each
pr's.
I
did
not
do
anything
on
that
aspect.
I
will
be
getting
to
it
like
later
today
or
tomorrow,
but
one
thing
which
we
another
thing
which
we
discussed
was
to
to
get
help
more
help
with
triaging
issues
to
add
victor
as
the
trader.
So
I
did
the
pr
here.
A
I
think
I
got
enough
approvals
to
proceed
so
I
will
just
merge
it
and
add
victor
to
all
the
like.
There
is
a
group
which
will
give
you
access
to
change
permissions
or
change
tags,
so
welcome
victor
a
stranger.
Oh
victory
is
already
in
the
call
yeah
hello.
D
Thank
you,
everyone,
I
think
I'm
gonna
need
help
at
least
the
first
few
stages,
showing
me
how
to
to
go
through
the
triage
process
for
people,
so
yeah
you'd
be
the.
A
Very
first
person
who,
who
will
be
actually
officially
a
treasurer
because
we
never
had
it
like
official
treasurer
before
I
think,
like
sergey
added
riley
as
one
of
the
triages,
but
at
that
time
the
road
was
not
defended
in
the
community,
so
we
eventually
got
rid
of
really
essentializer
and
I
think
yeah
and
he
moved
to
approval
group
so
yeah
we
can
like
work
together
and
see
where
you
can
help,
and
one
like
additional
thing
is
a
lot
of
issues
got
cleared
up
in
the
last
one
weekly,
I
think
like
10
or
15
issues
were
closed.
A
Like
alan
closed
few
of
them
I
closed
few,
but
we
still
have
a
lot
of
them,
and
I,
like
one
of
the
thing
which
I
mentioned,
I
will
be
doing
this
week-
was
the
matrix
cleanup,
which
I
haven't
done
yet.
A
So
I
think
it
would
be
fairly
right
to
say
that
any
issues
which
are
marked
as
metric
would
be
a
good
candidate
for
just
like
blindly
closing,
and
that
would
be
something
which
I'll
be
doing
today,
and
I
also
owe
an
update
on
the
matrix
actual
implementation
like
how
do
we
do
the
logistics?
I
don't
have
an
update
today.
Hopefully
I
will
work
it
together
with
victor
later
this
week
and
share
it
here.
A
We
might
be
like
we,
we
might
be
just
doing
like
a
nooking
of
the
whole
metrics
folder
and
starting
over,
given
that
there
is
no
like
there
is
nothing
which
we
think
can
be
reused.
I
see
so
most
likely
it
will
be
just
smoking
and
starting
over.
That
might
be
like
the
fastest
way,
rather
than
trying
to
keep
the
existing
code.
A
So
it's
still
on
me
I'll
come
back
by
next
week,
and
I
share
the
ideas
with
victor
initially
because
he
already
has
some
code
in
a
private
branch
which
might
be
a
right
candidate
to
be
put
into
the
metrics
folder.
So
we'll
come
back
next
week
with
an
actual
action
plan,
so
that
ends
updates
from
me.
Oh
sorry,
I
actually
have
one
thing
victor,
add
a
comment
so,
okay,
so
victor
like.
Let
me
share
what
I
meant
by
the
net
standard
versus
net
framework
targeting
issue.
A
It's
basically
what
triggered
this
pr,
even
though
this
pr
is
doing
like
something
else.
Indeed,
right
now,
the
original
reason
why
it
was
targeted
was.
Oh
sorry,
let
me
find
the
description.
A
A
So
in
this
format
like
if
a
user
is
having
a
console
which
uses
a
class
library
which
is
like
a
wrapper
which
wraps
the
open
elementary
sdk,
and
if
the
app
is
targeting
at
48
and
class
libraries
targeting
extended,
it
brings
the
net
core
version
to
the
main
app.
I
think,
even
though
the
main
app
is
targeting
net
4
right,
it
brings
the
net
core
version,
and
if,
if
we
have
like
a
different
public
api
or
different
behavior,
then
it
will
so
in
this
case
it
was
extreme.
A
The
public
ebay
was
different
for
different
targets,
so
it
just
breaks
like
at
runtime.
It
throws
what
like
method,
not
found
exception.
I
think
so.
This
vr
does
fix
it
by
having
the
same
api
available,
so
it
won't
really
throw
anything
at
the
runtime.
But
it's
still,
the
problem
is
still
there,
because
it's
now
pulling
the
wrong
like
it's
triggering
the
wrong
code
path.
A
So
this
is
still
an
issue
so
utkarsh
and
I
did
a
lot
of
investigation
on
this.
I
don't
have
a
actual
solution
other
than
asking
like.
If
you
are
writing
your
own
wrapper
around
the
sdk,
then
you
make
sure
you
have
to
target.
You
have
to
have
multi-target
as
well.
So
if
this
plus
library
is
also
multi-targeted
like
dot
one
for
net
standard
and
then
one
for
dogmatic
framework,
then
this
shouldn't
occur.
A
Because
then,
like
I
mean
it's,
I
don't
know
whether
that's
a
right
recommendation,
but
that's
what
we
found
based
on
utkarsh's
experiment
with
this
approach.
So
that
was
the
issue
which
I
wanted
to
discuss
now.
I
just
want
to
hear
from
victor
whether
this
is
same
thing
which
you
wanted
to
discuss,
or
is
it
something
else.
A
Uh-Huh,
could
you
like
describe
what
what
is
the
thing
which
you
mean
by
like
review
the
target
framework
circuit.
D
Yeah,
so,
okay,
so
if
we're
ready
to
discuss
this
item,
I
could
I
could
give
you
guys.
E
D
Up
on
it,
okay,
so
yeah
so
so.
The
issue
here
is
that
the
request
here
is
that
we
like
the
sig
or
I'm
requesting
that
the
sig
maybe
review
what
target
frameworks
we
need
to
support.
You
know
ongoing.
D
Specifically,
for
the
reason
is
that
I
know
currently
that
the
dot
net
metrics
api
today
was
developed
currently
primarily
using
net
five
and
so
specifically
reviewing
that
there's
two
or
three
features
that
are
currently
being
currently
being
used
by
the.net
metrics
api.
Well,
that's
going
to
be
a
problem
if
we're
going
to
introduce,
depending
on
how
we
package
the
metrics
api.
D
If
we
just
introduce
that
directly
into
the
sdk
directly
today,
for
example,
it
won't,
it
won't
merge,
because
we
have,
you
know,
target
framework
differences,
okay,
so
the
features
that
are
currently
being
used
by
the
net
metrics
api
as
the
design
experiment,
is
that
we're
using
tuple
values
and
read-only
spans,
and
so
those
two
items
I
think,
generally
require
net
standard
2.1.
D
So
currently
in
the
open
sdk,
we
have
support
all
the
way
back
to
net
four
five
one,
four,
five,
two
sorry,
and
so
the
question
is:
if
we
do
need
to
support
all
of
those,
then
then
we
need
to
discuss
with
with
the
net
team
what
to
do
about
it.
D
I
think
I've
spoken
to
noah
who's,
leading
that
effort
and
I
think
we
have
an
approach,
but
I
just
wanted
to
call
that
out
to
see
if
the
sig
has
want
to
review
or
have
recommendation
in
terms
of
what
target
frameworks
we
do
want
to
support.
A
So,
like
the
promise
which
we
made-
oh
sorry
like
so
michael,
what
was
it
you
please
go
on
first,
so.
D
E
A
Five
two
yeah,
I
think,
system
dot.
If,
if
that
literally
tuple
is
coming
from
system.memory,
I
mean,
if
that's
the
only
thing
which
you
mean
by
the
five
features:
yeah.
A
We
already
use,
I
mean
techno
assistant
or
diagnostic
source,
that's
for
tracing,
and
it
already
has
a
dependency
on
existing
dot
memory
and
which,
like
obviously
supports
all
the
way
back
to
net
four
five.
So.
D
A
D
Well
so
they're
they're,
like
the
span,
the
just
the
general
span.
A
That's
surprising
yeah
I
mean
I
I
okay,
so
it
says
literally
scanning
it
back
of
this
package,
but
this
package
is
supporting
like
all
the
way
to
the
new,
but
the
I
mean
it's
tricky
like
if
this
package
is
available
in
dot
net
4
5,
but
this
particular
type
within
this
package
is
not
available.
That's
a
little
bit
weird.
D
Yeah,
so
I
asked
noah
to
give
us
a
recommendation
in
terms
of
what
we
could
do
here.
Yeah.
A
So
like
just
to
give
background
like
when
the
this
sig
was
originally
formed,
like
in
2018
and
or
maybe
2019
beginning,
there
were
some
discussions
on
what
is
what
are
the
document
versions
which
it
wants
to
support
and
the
decision
at
that
time,
which
is
like
way
before,
like
any
of
us
in
this
group
joined
this
thing
was
to
support
every
every,
like
supporter.net
version
and
dotnet
framework
for
phi
2
was
the
lowest
supported
version
from
microsoft
at
that
time,
so
it
was
decided
that
we'll
do
support
dot
net
framework
452
and
in
dot
net
core
world.
A
The
least
supported
at
that
time
was
2.1
onward.
So
we
decided
okay,
we'll
support
everything,
microsoft
supports
and
that's
what
we
promised
even
in
metrics,
I
mean
it.
It's
I
slightly
tweaked
that
here
just
to
say
that
it's
going
to
be
supported
all
the
way
to
462,
not
for
phyto,
because
I
vaguely
recollect
that,
when
dotnet
team
decided
to
include
the
metric
support,
they
mentioned
that
it
may
not
be
available
in
like.net
four
or
five
to
eight.
A
E
A
E
E
A
Okay,
so
the
first
step
is
like:
is
it
actually
true
that
it
is
only
supported
in
what
this
talk
says?
If,
yes,
then
we
need
to
ask
for
a
plan
from
dotnet,
if
not
like,
we
are
good.
We
I
mean.
If
it
is
part
of
like
system
dot
memory,
then
we
are
already
covered,
because
this
is
already
being
used
in
diagnostic
source.
We
use
the
span
like
the
regular
span
here,
so
if
red
only
span
is
also.
C
A
D
I
I
well
so
so
nothing
here
is
locked
in
stone
yet
so
currently
the
the
the
prototype
that
noah
is
putting
together
in
that
link
that
I
think
I
shared
the
link.
So
everybody
please
welcome
to
look
at
it.
I
think
it's
called
systemdiagnostic.metric
and
I
think
noah
is
working
with
tariq
to
you
know,
today
or
or
soon
to
figure
out
how
to
start
to
produce
a
nougat
package
for
it,
but
the
namespace,
as
I
best
understand
it
right
now-
is
system
diagnostic
metric.
A
I
see
so
like
maybe
like
we
will
just
come
back
like
confirm
whether
the
problem
actually
exists
or
not,
and
then
we'll
come
back
and
ask
for
like
some
solution
from
the
dotnet
team,
because
we
expect
to
support
dotnet
framework
for
sure.
The
only
thing
which
can
be
negotiated
is
like
do
we
need
dotnet
452
or
we
can
just
drop.net
452
and
use
461,
that's
probably
negotiable,
but
we
definitely
need
to
support.net
framework
because.
D
Yes,
yeah,
so
the
question
isn't
whether
we
support
that
net
frame.
The
question
is
really
how
far
what's
the
oldest
net
framework
or
netstandard
or
net
core,
we
need
to
support.
So,
for
example,
do
we
need
to
support
four
or
five?
You
know
series
four,
five,
two
or
so
forth.
A
Yeah,
so
the
original
decision
was
to
support
whatever
microsoft
support.
So
since
452
is,
with
the
exception
of
3.5,
we
support
whatever
is
supported
by
microsoft.
So,
like
four
five
one
is
after
support:
four
five:
four,
oh,
so
we
don't
support
it.
So
everything
from
four
five
two
and
above
is
officially
supported
by
microsoft,
and
this
is
for
net
framework
and
for
core.
It's
slightly
different.
A
I
think
2.1
is
the
most
yeah,
but
it
this
will
be
going
out
of
support
like
very
soon
so
by
the
time
we
have
matrix
out,
which
is
only
on
like
after
august,
we
can
easily
say
we
won't
support
net
core
2.1.
We
can
only.
We
only
need
to
support.net
cover
3.1
and
above
in
the
dot
net
core
series,
but
for
total
framework.
The
original
plan
is
to
support
anything
which
is
supported
by
microsoft,
which
includes
dot
net
452.
D
Okay,
fair
enough,
I
think
yeah
noah
could
work
with
that.
A
D
Yeah,
so
I
think
I
think
the
ask
would
be
then
back
to
the
net
team
to
see
if
their,
if
they
could
produce
the
package
and
the
nougat.
That
would
work
for
all
the
supported
frameworks.
A
Okay,
so
which
means
I,
I
still
have
my
open
question.
So
it's
even,
though
related
not
directly
addressing
the
question
which
I
posted
earlier,
so
this
is
coming
from
the
like.
This
is
the
same
thing
which
I
described
earlier
like
we
don't
know
whether
it's
okay
to
just
expect
people
to
multi-target.
A
This
is
something
which
I
haven't
done.
A
lot
of
research
did
the
research
and
I'm
just
updating
on
his
behalf
that
it
is
an
issue.
It
is
going
to
break
people,
but
I
I'm
just
struggling
to
find
out
like.
Should
we
just
leave
with
that
and
just
expect
that
people,
if
they're,
writing
wrappers
for
our
sdk,
they
also
do
multitargeting
or
something
of
that
sort,
or
we
just
document
that
this
is
an
issue
so
make
sure
if
you're
writing
a
wrapper
due
to
the
proper
multi-targeting,
any
other
opinions.
A
I
I
might
actually
get
some
help
from
my
team
to
see
whether,
like
this,
this
won't
be
an
issue
just
for
open
telemetry.
This
will
be
like
a
general
issue
for
anyone
writing
libraries
multi-targeting.
So
I
can
reach
out
to
some
folks
from
dot
19
to
see
if
they
have
any
recommendation,
but
I
just
want
to
get
like
initial
feedback
from
this
community.
If
anyone
has
opinions
on
this
aspect,
any
opinions,
michael.
E
A
This
yeah,
so
before
this
pr
or
the
current
code
in
dotnet
core,
we
have
these
two
options
in
dotnet
framework.
We
have
this
so
the
class
library
which
is
using
the
net
standard
201
will
get
like
both
I
mean
because
it
isn't
at
standard
too
it
gets
the
net
core
version,
but
the
final
app.
A
If
it
tries
to
access
like
these
two
or
it
it
does
because
it
does
it
through
the
class
clip
it
blows
up
at
runtime,
because
this
controller
is
targeting.net
48
and
it
brings
the
net
framework
version
of
the
instrumentation.
E
A
Okay,
so
the
console
app
does
not
refer
to
this
directly.
It's
only
the
class
lib
which
refers
to
like
these
settings,
the
console
simply
take
a
dependency
on
the
class
slip
and
call
some
method
on
the
class
library
internally
inside
the
class
library.
It
calls
the
actual
set
db
statement
or
yeah.
I
think
like
do
you
know
like
where
is
that,
like
actual
repro.
D
This
sounds
like
to
me,
like
a
assembly
binding
issue
right,
so
so
I
I
think
if
we
ran
like
a
fusion
or
turn
on
fusion
to
see
which
assembly
rebinding
occurs,
that
would
probably
help
us
answer
the
question
and
I
think,
if
that's
the
case,
I
think
you
could
specify
in
your
config
files
to
just
point
it
to
the
right
assembly.
D
A
D
Right
understood:
it's
not
the
build,
it's
just
the
the
users
combination
of
these
different.
You
know
these
different
assemblies
or
these
different.
You
know,
let's
see,
the
user
is
combining
different
components
that
potentially
uses
different
net
components,
and
so
the
net
runtime
has
to
somehow
figure
it
out
right
and
it's.
A
I
I'm
just
opening
it
here,
so
everyone
can
see.
So
this
is
a
class
library
which
is
net
standard
only
and
it's
referring
to
the
sequel,
instrumentation
and
inside
the
class
library.
It
makes
this
call,
which
is
accessing
the
dot
net
core,
but
this
is
only
available
in
dot
net
core.
These
two
statements.
E
A
E
There
is
the
anti
pattern,
so
I
had
this
issue
with
apache
thrift,
when
I
was
first
working
on
jaeger,
where
yeah
one
nougat
package
that
has
targets
for
net
framework
core
standard
core
app,
there's
a
ton
of
them
in
there,
but
the
different
targets
have
different
apis,
so
our
jaeger
library
was
compiling
for
one
api
and
then
at
runtime
it
would
switch
like
the
net
framework
one
in
and
everything
would
break.
I
think
the
anti-pattern
is
really
if
you're
multi-targeting
you
shouldn't,
expose
different
apis.
E
A
But
like
even
if
we
expose
the
same
api
for
both
targets,
if
the
behavior
is
expected
to
be
different,
it's
still
an
issue
right,
because
in
this
case
the
issue
was
like
really
blowing
up
the
app.
So
it's
like
obvious
that
you
did
some
mistake,
but
if
you
did
have
like
like
common
api
for
both
dotnet
framework
and
dot
net
core,
but
it's
internally
not
doing
what
it
is
supposed
to
do.
For
example
like
this
has
no
impact
on
dotnet
framework.
A
So,
even
if
we
still
make
the
same
public
api
available
for
both
targets,
I
still
think
that
this
is
still
an
issue
because
you're
not
getting
the
behavior
which
you
are
expecting
or
we
can
clarify.
I
mean
I
think,
that's
what
this
pr
is
trying
to
do
like.
If
we
put
this
feature,
it
has
no
effect
on
dot
net
core
so
and
then
people
have
to
read
the
comment
all
the
time
to
understand.
F
The
only
thing
I
saw
in
some
documentation
is
that
you
have
to
specify
a
target
on
the
cs,
prod
to
say,
set
target
framework
to
whatever
version
of
the
framework
you
want,
so
that
it
will.
It
will.
Basically,
the
library
will
pick
that
target
that
you
want
not
the
target
that
the
library
is
because
it's
less
descriptive
or
was
it
the
nearest
target
framework
moniker,
it's
it's
2.0,
but
its
dependency
is
a
different
version
like
4a
like
I
don't
know
that
sorry
I'll
shut.
E
A
E
A
But
in
this
particular
case,
like
the
reason
why
this
console
app
is
bringing
the
wrong
version,
because
the
console
app
is
supposed
to
be
like
framework,
so
it
should
be
like,
even
if
it
uses
a
like
wrapper
library,
which
brings
the
secret
line.
It
is
like
if,
if
the
class
libraries
do
multi-target
like
this,
like
netflix
or
something,
then
this
issue
should
not
be
there
like.
A
It
should
not
occur,
because
now
that
there
is
multiple
targets
like
when
you
build
the
console
app,
since
there
is
a
dotnet
framework
target,
the
sql
clients
dotnet
framework,
one
will
be
brought
because
the
final
app
is
like
net
48
and
net
46
more
closely
matches
net
408
than
net
standard.
So
it
kind
of
solves
the
problem.
But
then
my
question
is
like
what
do
we
do
about
it
as
library
others
like
in
this
case?
Like?
A
Should
we
just
state
that,
okay,
if
you're,
ever
wrapping
our
library
inside
your
own
wrappers
like
because
it's
not
the
end
like
if
they
are
using
it
in
an
end
application?
Like
final
application,
then
there
is
no
issue,
because
if
it
is
net
framework,
it
brings
the
net
framework
version
of
our
instrumentation.
If
it
is
net
core,
it
brings
the
only
issues
if
they
wrap
it
in
another
library.
A
So
this
could
solve
the
issue
like
if
they
multi
target
based
on
like
if
they
see
that
okay
sql
client
is
multi-targeted.
So
let
me
also
keep
it.
I
don't
know
whether
that's
a
like
right
recommendation
or
like
what
michael
was
saying
is.
We
should
not
have
like
different
apis
for
different
framework.
It.
A
Yeah
I
mean
that's,
I'm
not
like
perfectly
happy,
but
it's
same
problem
which
we
have
even
in
other
places
like
we
don't
have.
So
let
me
see,
I
think,
even
for
http
client
instrumentation.
We
have
like
different
options,
so
there
is
one
http
instrumentation
option,
http
client
instrumentation
options
and
what
is
the
other
one
yeah?
A
So
this
is
only
applicable
for
net
framework.
So
it's
like,
depending
on
your
target,
you
have
a
different
public
api,
so
this
problem
is
there
like
in
many
other
places.
So
I
was
wondering
like
is
there
if
there
is
any
common
approach
which
we
could
take?
One
approach
which
this
pr
is
proposing
is
have
the
api
same
in
all
platforms,
but
the
behavior
be
different,
so
if
it
doesn't
make
sense
in
one
case,
we
just
document
it
and
it
becomes
no
hope.
A
B
We
could
have
like
target
framework
specific,
like
packages
like
have
two
packages
for
sql,
one
for
dotnet
framework,
yeah.
A
So
that's
like
yeah,
I
mean
then
that
defeats
the
whole
point
of
like
like
multi-target
in
cs
project,
because
if
you
are
having
different
packages,
then
you
you'll
always
have
like
one
package
for
target
framework.
A
A
Okay,
we
just
have
a
single
package
and
the
behavior
is
transparent
to
the
user,
whether
they
use
http,
internet,
core
or
not
framework,
but
it
does
sound
like
other
issues
so
yeah
I
mean
I
could
do
like
reach
out
to
the
dotnet
team
to
see
whether
they
have
any
recommendation
on
this
aspect
and
then
come
back
and
like
report
that
back
here
and
then
make
a
final
decision.
A
So
basically
I
wanted
to
like
here
like.
Is
it
something
which
people
have
faced
before,
like
michael
already
shared,
like
instance,
but
it's
a
problem
which
I
know
exist,
but
I
don't
have
a
proper
solution
at
this
stage,
so
we
most
likely
like
be
sitting
on
this
for
a
while,
and
we
get
a
good
answer
from
that
of
my
team.
D
You
see
joe
from
from
the
user's
perspective.
Is
there
any
way
they
could
work
around
this
issue
at
the
moment
or
they
can?
They
just
cannot?
Oh.
A
D
A
Don't
know
I
mean
assembly
binding,
like
you
cannot
specify
like
which,
which
target
you
have
to
get
like.
You
can
only
specify
like
from
one
version
to
another
like
instead
of
this
version,
go
and
take
the
other
version,
at
least
that's
my
understanding.
I
don't
think
like
you,
can
tell
that
hey
if
someone
asks
for
sql
client
in
extended
instead
redirect
them
to
the
net46
version.
I
don't
know
whether
assembly
reader
has
that
capability.
E
E
I
was
basically
overwriting
or
not
using.net
resolution.
I
was
saying
pull
in
the
library,
so
it
downloads
it
to
the
nougat
folder
location
and
like
unpackages
it,
and
I
basically
added
a
file
reference
to
the
specific
target
dll
inside
the
nuget,
so
that
I
was
basically
telling
it
specifically
which
one
to
compile
against,
but
even
at
even
that
there
were
some
other
problems.
I
forget
what
it
was,
but
there
were
like
some
bugs
open
where
it
didn't
work.
100
of
the
time.
E
A
A
Out
yeah,
I
mean
this.
E
A
So,
what's
the
current
state,
like
I
like
we
just
like
literally
clone
the
repo
into
our
reproductive
classes,
which
we
need.
E
A
Yeah,
okay,
so
it's
like
we
are.
We
have
seen
this
problem,
but
yeah,
it
doesn't
look
like
there
exist
a
neat
solution,
so
how
about
like?
I
just
reach
out
to
someone
from
dot
19
to
see
if
there
is
anything
which
they
can
recommend
for
like
the
program
which
we
have
in
open
telemetry
and
it
might
affect
the
matrix
area
as
well.
So
we
I
mean
in
matrix
it's
just
like
internal
internal
thing.
A
There
should
be
any
there
shouldn't
be
any
public
api
difference
based
on
like
read-only
three-dollar
span
available
or
not
so
it
may
not
be
directly
affecting
the
metrics,
but
yeah
I'll
bundle.
This
and
ask
someone
in
dortmund
then
come
back
next
week
to
see
if
we
can
solve
it,
because,
right
now,
it's
just
sql
and
http
client,
and
I
think
even
the
logging
as
logging
is
also
using
multiple
target,
because
the
login
is
only
for,
but
the
api
is
same.
A
So
we
wouldn't
know
if
there
is
anything
like
really
broken
or
not
behaving,
because
we
only
target
it
for
like
net
for
six
and
above
yeah,
okay.
So
there
is
no
the
only
two
known
places
where
there
are
different
public
apis
for
different
targets
is
the
http
client
and
the
sql
client,
at
least
in
the
main
repo
need
to
see
if
there
is
anything
in
the
contract.
Repo,
okay,
yeah
I'll,
take
an
action
item
on
me
to
like
work
with
someone
from
dotnet
team
and
get
some
official
answer
for
this.
A
Okay,
yeah
any
anything
else
to
discuss.
I
do
have
a
bunch
of
peers
open
just
trying
to
do
the
extension
start
hosting,
as
I
mentioned
earlier.
This
is
purely
waiting
on
us
not
on
spec,
so
try
to
like
push
it
to
the
next
like
rc4
and
then
eventually
stable,
but
much
before
the
instrumentation.
So
I
do
have
like
some
peers
open
in
that.
I
think
oh
someone,
commanded!
Maybe
I
used
a
few
minutes
just
to
ask.
A
Oh
okay,
michael
recommended,
let
me
just
open
the
pr
just
to
share
with
everyone.
What
is
the
thing
which
I
am
like
trying
to
like
trying
to
address
so
with
me?
A
F
Yeah,
I'm
kinda
curious
how
you
will
end
up
solving
this,
because
I
in
my
own
independent
learning
of
all
this,
it
seems
like
dot
net
standard
as
great
as
it
is.
It
actually
complicates
a
couple
matters
when
you're
trying
to
do
framework
compat
like
it
doesn't
speak
to
core.
It
doesn't
speak
the
full
framework,
exactly
full
framework.
F
Obviously
is
that
effect
like
you
can
pick
it
out
of
the
bunch,
but
then,
when
you
want
to
discriminate
based
on
what
libraries
are
available
to
you
in
core
or
you
know.net,
5
or
forward,
then
it's
harder
because
standard
doesn't
is
not
specific
to
that.
Even
though
there
is
specific
apis
surface
area,
that's
different
in
the
newer
versions,
so
it's
like
either
don't
use
it
if
it's
not
the
same
surface
area
like
if
it's
the
same
api
for
everything,
then
dot
net
standard
makes
a
lot
of
sense.
F
A
There
is
a
pier
which
was
like
little
bits.
Let
me
open
that
pier
just
to
it's.
In
the
same
context,
I'm
trying
to
find.
E
A
E
F
That
was
where
my
mind
ended
off.
Thinking
about
it,
because
I
was
in
my
world.
We,
we
write
libraries
that
wrap
other
libraries
inc
in
the
biggest
difference
between
the
this
kind
of
stuff.
We
do
is
like
well,
we
got
net
framework
configuration
way
of
doing
things.
Then
we
have
dot.
You
know
net
core
apps
way
of
configuring,
configuring
things
and
the
two
worlds
are
kind
of
different
when
you
think
of
it.
F
Natively
and
I
like
well
standard,
sounds
great,
but
then
I'm
really
targeting
each
frameworks
or
the
the
runtime
way
of
configuring,
the
app
there
wasn't
like
an
easier
way,
unless
you
just
explicitly
say
it
like.
I
want
to
do
this
type
of
app
or
that
type
of
app
in
the
library
name.
So
essentially
what
you're
saying,
but
if
that
sounds
confusing,
I'm
sorry.
A
G
A
E
At
like
system.diagnostic
source
for
as
an
example,
that's
a
library
of
targets
like
everything
that's
supported,
it
gives
you
the
same
api,
no
matter
what
target
you're
using
so
that,
in
that
case
it
works.
Our
case
is
a
little
different,
because
we
can't
do
that
right.
There's
framework
differences.
We
don't
really
have
a
choice,
so
multi-targeting
for
us
is
kind
of
a
different
animal
than
just
you
know,
building
a
library
and
saying
here's
the
api.
I
don't
know
how
to
solve
it,
be
very
curious.
You
do
if
you
ask
the
runtime
team.
A
E
F
E
C
E
A
Yeah,
but
for
sql
there
is
like,
like
some
limitations
like,
for
example,
you
don't
have
access
to
the
sql
command
to
extract
the
statement
from,
and
this
limitation
only
exists
in
dotnet
framework.
So
we
cannot
write
a
hello.
How
would
we
polyfill
that
yeah?
We
cannot
feel
it
like.
We
just
say
that
instead
of
the
actual
statement,
we
can
say
sorry
not
found
you
know
platform,
not
supportive
type
of
thing,
yeah.
A
Something
like
that,
but
I
mean
I
don't
know
like
whether
that's
more
appealing
than
the
current
way,
because
in
the
current
way
it
breaks
your
app
at
runtime.
So
it's
it's
worse
in
in
terms
of
life
impact,
but
at
least
you
know.
Okay,
this
problem
occurs.
I
mean
this
is
not
supported,
so
you
can
do
like
something
about
it,
but
yeah
I
mean
it's
not
ideal.
Either
you
don't
want,
like
a
telemetry
library,
to
crash
your
app
on
runtime,
so
that's
definitely
not
ideal
either.
F
Yeah,
the
runtime
really
drove
a
lot
of
our
decisions
on
how
things
get
done,
because
it's
just
the
I
think,
you're
on
to
something
with
focusing
concentrating
on
the
runtime
aspect.
More
than
the
standard
which
is
you
know,
is
supposed
to
be
what
it
should
should
have
been
just
standard
across
all
libraries,
but
if
you're
not
actually
standard
across
all
libraries,
then
you
have
a
code
to
the
least
common
denominator,
which
would
be
the
you
know.
The
applications
run
time.
A
All
right
yeah,
so
let
me
just
share
like
a
different
problem,
now
excited
really
a
problem.
I
am
just
trying
to
get
some
feedback,
because
this
is
the
extensions
package
we
have
for
sp
net
core
or
really
it's
not
tied
to
sp
net
core,
but
it
is
the
extension
store
hosting
package.
A
So
this
pr,
like
I
did
like
seemingly
hacky
things
just
to
get
my
job
done.
So
let
me
show
the
end
result.
This
is
what
we
were
being
asked
like
as
a
feedback
from
the
very
beginning.
People
usually
don't
construct
because,
like
this
is
a
current
way
like
you
have
a
common
place,
which
is
your
startup
class.
Typically,
you
construct
your
open
telemetry
by
like
having
a
builder,
which
you
add,
all
the
instrumentations,
all
the
exporters,
all
other
things
which
are
configurable.
You
do
it
like
one
place.
A
A
There
is
no
way
for
the
second
component
to
do
it
without
duplicating
this,
because
if
they
add
like
services,
dot,
add
open
telemetry
with
a
add
aeger,
then
it's
not
just
they're,
not
adding
that
exporter
to
the
same
provider,
they're
going
to
create
a
brand
new
provider
which
is
another
like
issue
which
we
have
like
it's.
Basically,
we
don't
clean
up
the
previous
one,
so
we
will
end
up
having
two
two
tracer
providers,
one
in
undisposed
state.
A
So
one
way
I'm
trying
to
solve
it
here
solve
it
here
is
we
can
do
like
and
open
elementary
tracing
without
configuring
anything.
We
can
still
do
it
here
just
like
before,
but
then
you
can
like
build
onto
it
like
you
can
call
like
tracer
provider
builder,
and
you
can
incrementally
build
all
the
things
which
you
want
like,
so
it
can
be
like
happening
in
different
places
of
your
code.
A
A
Rather
than
forcing
to
configure
everything
in
like
single
place
and
any
attempt
to
do
it,
otherwise
would
result
in
incorrect
behavior.
So
this
is
my
end
result
I
mean
my
end
goal
to
have
the
ability
to
configure
things
like
this
and,
like
I
put
like
some
comments
here,
to
explain
like,
for
example,
sometimes
like
if
you're
using
asp.net
core,
like
some
instrumentation
or
some
exporter,
you
want
to
bind
that
to
a
section
of
your
configuration
so,
but
this
will
have
no
impact
unless
the
actual
component
is
important.
A
There
is
no
error
or
anything.
So
it's
possible
that,
like
you,
have
a
like
you,
you
have
a
telemetry
team
which
is
like
picking
things
for
you
like
they'll,
have
like
helpers
or
rappers.
So
they
decide
that
okay,
if
you're
using
sp
net
core,
you
always
want
the
like
some
setting
on
so
they'll
put
this
statement,
but
the
question
of
whether
you
want
to
use
this
feature
or
not
like
it.
It
already
lies
on
who
is
constructing
this
instrumentation.
A
So
this
is
like
a
real
scenario
like
we
have
some
comments
in
the
original
issue.
So
this
is
the
end
result.
E
A
Yeah,
so
in
the
di
world,
no,
like
it's
just
one
like
it's,
we
are
not
preventing
anyone
from
creating
more
tracer
providers.
It's
just
that
in
the
da
world.
We
are
only
adding
it
as
a
singleton,
so
there
is
only
one
tracer
provider,
but
if
you
want,
you
can
still
construct
like
your
own
tracer
providers
manually
and
add
it
to
like
ba
yourself.
So
we
are
not
restricting
anyone
from
constructing
multiple
providers.
E
E
The
next
thing
I
was
going
to
bring
up
if
you
go
down
the
way
you're
asking
for
the
high
enumerable
of
all
the
configurations
that
are
registered
yeah.
E
That's
what
I
was
trying
to
figure
out,
yeah
yeah,
I
don't
know,
I
don't
think
here.
I
thought
that
was
sorry.
We
needed
to
do
like
you
wanted
to
send.
E
A
Yeah
so
you're,
basically
like
the
recur
one
of
the
requirement
is
you
have
like
multiple
tracer
providers
so
that,
like
one
of
them,
will
have
a
like
sampling
enabled
and
you
send
it
to
like
expensive
back
end
and
the
other
one.
It's
like
no
sampling
or
always
on
sampler,
and
you
send
the
telemetry
to
like
not
so
expensive,
like
back-end,
that's
a
scenario
yeah,
so
why
I
mean
this
does
not
prevent
anyone
from
doing
that.
A
A
That's
not
really
broken
by
this
pr.
It's
already
exist,
it's
not
being
broken
by
this
pr.
A
It's.
What
was
that
you
were
like,
like
first
question,
to
be
discussed.
E
A
I
mean
I'm
happy
to
hear
our
ideas
like.
I
know
that
this
is
something
which
I
tried,
which
we
put
some
comments,
but
design.
E
A
F
A
Callbacks
exactly
yeah
we're
just
trying
to
like,
cumulatively,
I
mean
collect
all
the
requirements
and
when
you
do
the
final
build
like
take
all
the
things
from
like
it's
like
I
mean
I
could
not
find
an
easy
way
to
achieve
a
similar
code
like
here.
A
E
A
Yeah
also
like
I
did
put
another
comment
here
about
this
part,
so
you.
E
E
A
Yeah,
so
do
you
see
the
like,
like
the
end
goal,
which
I
am
trying
to
achieve
like
having
the
ability
to
use
the
extension
methods
but
still
have
the
ability
to
like
configure
it
from
multiple
places,
not
strictly
tied
to
the
single
callback?
Here.
E
E
I
think
we
could
make
that
work.
So,
basically
all
we
need
to
do
is
in
that
extension
method
for
add,
open,
telemetry
tracing.
Instead
of
registering
a
singleton,
we
register
one
per
then
we
have
that
hosted
service.
What
it
does
is
actually
pull
it
out,
so
it's
actually
executed
and
then
it
manages
it.
We
could
have
that
hosted
service.
Do
exactly
what
what
you're
doing
below,
where
you're
just
asking
for
an
enumerable
hosted
service
could
basically
say
give
me
all
the
tracer
provider
builders.
F
A
A
A
E
A
A
Typically,
you
have
like
a
like
you.
You
are
like
an
like
big
company
like
where
you
have
like
multiple
teams.
They
all
have
like
their
own
helper
methods
on,
like
I
service
collection,
they
all
like
add,
like
things
independently
and
in
the
final
application
you
get
like.
You,
don't
really
know
like
what
your
sister
teams
are,
adding
to
the
ba
so
same
way
like
so,
if
we
let
everyone
call
add
open,
telemetry
tracing
then,
like
everyone
is
like
adding
a
new
instance
of
the
tracer
provider.
A
That's
that
was
one
of
the
bugs
which
we
opened,
because
then
we
have
multiple
providers
and
every
time
we
are
talking
about
configuration,
then
we
need
to
first
test.
Okay,
I
have
five
providers
to
which
one
I
should
apply.
This
conflict
really.
F
A
F
Kind
of
hearing
is
that
you
make
an
abstraction,
then
you
push
it
one
layer
higher
so,
like
I
think
mike
michael.
What
is
your
name
right?
Is
that
you,
you,
then
have
an
array
of
all
your,
I
guess
not
necessarily
providers,
but
I
liken
this
to
like
authentication
how
that
works
and
as
well
as
logging
you,
you
kind
of
have
all
these
pieces
that
just
get
registered,
but
under
the
covers
really
it's
just
one
thing:
that's
executing
everything
and
they're
they
kind
of
have
their
own
life
cycles.
F
If
you
will,
but
still
it's
still
one
thing,
that's
actually
pulling
all
these
providers
that
we've
just
registered
here
and
executes
them
and
then,
like,
I
think
you
mentioned
like
we
it's
sunset
together,
but
that's
nothing
that
the
user
sees
like
the
consumers
when
they
build
onto
this
they're,
not
going
to
actually
touch
the
the
abstraction
layer
at
that
part.
Just
like
authentication
provider,
we
don't
touch
the
internals
of
it.
We
just
we
nearly
configure
something
that
then
gets
added
to
it.
Kind
of
like
authentication
schemes
how
that
works.
F
E
A
Yeah,
so
we
do
know
that
there
exists
use
cases
for
having
like
multiple
tracer
providers
like
the
example
which
we
shared
earlier.
The
question
is
like
we
are
not
blocking
anyone
from
doing
that.
It's
just
that
we
are
not
making
it
easy
to
use
or
construct
multiple
providers
by
using
the
da
mechanics,
because
we
from
the
very
beginning
was
we
are
using
like
a
single
instance
of
tracer
provider,
it's
very
similar
to
like
in
experiment
code.
A
You
only
have
a
singleton
logo
factory,
like
you
just
add,
like
console,
x,
logger
or
debug
logger
or
whatever
logger,
it's
all
tied
to
the
same
logo
factory,
but
that
doesn't
mean
you
cannot
create
your
own
logo
factory.
You
can
it's
just
like
the
the
default
model
doesn't
make
it
easy
to
create
multiple
logger
factory
instances
in
an
sp
document
core
app.
So
we
could
just
stick
with
the
same
approach
like
we
don't
prevent
you
from
creating
multiple
providers.
A
If
you
want,
but
the
like
the
default
thing
which
we
are
going
to
do,
is
we
recommend
you
create
a
provider
once
and
reuse
it
throughout,
and
we
make
the
configuration
life
much
easier
for
that
approach.
If
you,
if
you
still
want
different
provider,
yeah
go
for
it,
but
there
is
no
like
helper
method,
like
services
stored,
add
open,
telemetry
tracing
which
helps
you.
A
I
see
so
when
you're
saying
like
when
you
do
like
adding
and
when
you're
configuring
you
always
specify
the
name,
so
the
config
would
only
apply
to
that
named
instance:
yeah.
That's
some
another
thing
which
we
can
explore.
Yeah.
E
A
But
that
would
also
require
us
to
make
some
changes
to
the
tracer
provider
api
to
support,
like
name
because
right
now
it
doesn't
have
the
concept
of
name
it.
You
just
create
it
as
many
as
you
want.
There
is
no
name
so
yeah
I
mean
that's
still
doable.
Let
me
try
to
see
if
I
can
explore
that
little
bit
further.
A
You
also
want
to
get
like
a
little
bit.
I
think
it's
over
time,
so
maybe
like
we'll
try
to
resolve
it
in
the
comment,
because
this
is
some
command
which
alan
made
earlier,
because
there
is
a
need
to
get
a
hold
of
service
provider
to
get
like
local
from
that
and
use
that.
A
But
let
me
come
back
to
this
sometime
later
because
we
are
like
slightly
over
time
but
like
people,
if
you
are
any
like
comments
or
other
ideas
other
than
what
we
discussed
feel
free
to
comment,
donates
yeah,
that's
pretty
much.
I
heard
I
think
we
can
end
now
and
come
back
to
this
problem
like
next
week,
maybe
like
by
then
we'll
have
sold
it
or
not.
A
Okay,
yeah
thanks
everyone
for
joining.
Let's
see
again
next
week,
hopefully.