►
From YouTube: 2021-09-22 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
How's
life
life
is
is
good,
but
not
back
to
normal.
I
don't
know
today
was
my
the
first
day
that
I,
for
instance,
took
my
daughter
to
ice
skate
since
the
pandemic
started.
B
A
C
I'm
gonna
put
for
the
the
first
thing,
because
raj
mentioned
that
we
are
gonna,
have
some
extra
folks
join?
I
think.
A
A
D
C
A
So,
as
I
was
saying,
kind
of
do,
a
review
of
that
for
the
benefit
of
tarak,
and
I
think
dave
perhaps
caught
that
part
that
we
are
doing
the
switch
to
the
sdk.
A
The
limitations
of
that
approach
and
kind
of
what
we
can
perhaps
due
to
kind
of
in
the
future,
hopefully
in
the
short
future,
have
better
solutions
for
that.
A
Have
coroner
here
and
then
both
zach
and
greg
especially
can
correct
me
what,
whatever
I
get
wrong
about
the
the
designs.
C
And
the
stuff-
I
I
just
want
to
kind
of
go
over
relatively
quick
over
that.
A
Okay,
so
when
the
the
project
started,
we
were
using
based
on
upstream
data.
Dog
has
a
tracer,
and
this
was
the
initial
design,
but
on
the
open,
telemetry
project,
we
used
the
diagnostic
source
that
has
the
activity
as
they
spend
and
that
is
actually
part
of
their
runtime
in
a
module
that
was
shipped
in
different
versions
before
even
open
telemetry
came
into
existence,
so
the
applications
have
different
versions
of
diagnostic
source,
potentially
with
the
the
data
dock
design
having
its
own
tracer.
A
That
is
not
a
problem
for
the
tracer
itself,
but
then,
when
you
want
to
start
to
operate
with
open
telemetry
or
anything
that
uses
activity,
then
we
have
the
problem
about
which
version
is
going
to
be
end
up
loaded
in
the
process.
A
Build
on
top
of
the
tracer
and
then
later
deal
with
the
the
question
about
the
the
compatibility
greg
had
a
prototype
that
had
a
type
isolating
that
the
diagnostic
source
access
and
then
we
could
do
things
like
that.
We
explored
a
little
bit
on
that
path,
but
then
we
we
note
that
we
lack
synergy
with
the
sdk
and
we
end
up
duplicating
a
lot
of
code
that
exists
on
the
open,
telemetry
sdk.
A
When
I
say
sdk
here,
I'm
in
the
open,
telemetry
sdk,
and
with
that
we
start
to
explore
using
the
the
open,
telemetry
sdk
and
the
problem
is
that
then
we
have
how
we
are
going
to
deal
with
the
diagnostic
source
version
that
the
sdk
requires
and
I'm
going
to
focus
on
the
diagnostic
source
problem.
But
the
same
problem
actually
applies
to
what
I'm
calling
calling
in
this
diagram.
A
The
source
instrumentations
source
instrumentations
in
these
cases
are
instrumentations
that
are
created
on
top
of
the
open
telemetry
api,
but
that
use
hooks
that
already
exists
on
asp.net
or
client
libraries,
whatever
the
application
already
have,
and
those
source
instrumentations
create
the
activity
spans,
but
they
don't
depend
on
auto
instrumentation
or
change
il
of
the
application.
A
What
we
are
trying
to
do
in
the
instrumentation
is
kind
of,
I
would
say,
aspect-oriented
programming,
not
a
generic
generic
one,
but
we
are
trying
to
add
initially
traces,
eventually
metrics
automatically
through
the
applications.
A
The
the
design
is
basically
using
a
clr
profiler
and
we
do
the
traditional
communication
via
the
profile
apis,
the
profiler
that
we
use
embeds
as
a
resource
at
builder
time.
A
small
assembly
that
doesn't
have
dependence
just
have
depends
with
the
things
that
are
provided
by
the
standard
runtime.
The
m
score
lib,
the
private
lib.
So
you
don't
need
anything
else
for
that
loader
that
is
in
better
resource.
A
So,
as
early
as
we
started
to
use,
I
would
say
the
first
user
module.
There
is
some
more
complicated
to
that
to
do
with
iis
and
modules
being
imported.
But
let's
say
after
the
first
core
lib
is
loaded
when
we
are
loading,
the
first
user
module.
We
inject
this
loader
and
this
loader
calls
our
what
we
call
managed
profiler
the
managed
profiler
is
the
one
that's
gonna
load:
either
the
data
dog
or
in
the
case
that
we
are
working
with
the
sdk,
is
going
to
load
the
sdk
and
initialize
it.
A
A
Versions
that
we
need
so-
and
we
can
simplify
this
by
having
a
new
get
package
that
people
can
reference
directly
that,
but
basically
the
idea
is
because
the
if
your
application
has
a
reference
to
the
correct
nuget
package
that
we
need.
This
is
going
to
be
resolved
at
build
time
and
the
application
is
going
to
use
the
same
version.
That's
needed
by
us.
A
So
the
sdk
and
the
source
instrumentations
can
work
with
that.
The
big
limitation
of
this
solution
is
that
we
are
requiring
people
to
build
the
the
the
applications
again,
and
this
is
not
possible
in
what
we
typically
call
devops
scenario.
A
But
basically,
if
you
just
have
the
the
files,
the
the
assemblies,
you
don't
have
a
chance
to
do,
that
we
did
some
high-level
exploration,
both
with
dotnet
framework
and
net
core
about
how
to
work
around
that
and
it's
possible
to
work
around
that
either
on
the
framework
with
binding
redirection
and
also
it's
possible
to
work
that
on.net
core
with
depth.json.
A
You
could
change
and
because
not
only
change,
but
we
also
bring
in
the
profiler
the
versions
that
we
need
and
the
loader
also
puts
a
handle
to
the
the
application,
the
assembly
loads.
So
then
we
can
kind
of
oh
okay.
We
say
that
we
wanted
this
version
and
when
the
the
application
itself
fails
to
load
that
this
code
that
was
already
initiated
on
the
manager
profiler,
the
hoop
that
was
created
there
will
take
care
of,
say,
hey,
but
we
do
have
disassembly
here.
A
So
basically,
this
is
the
the
workaround
these
workarounds
for
the
develop
scenario
we've
seen
that
they
work
on
basically,
but
it's
not
kind
of
easy
to
to
put
then
without
building
the
application.
You
know
kind
of
I
I
validated
then,
but
for
me
to
validate
it,
then
it
was
easy
because
I
could
simply
come
and
build
the
application
with
the
settings,
and
then
I
just
copied
the
file
and
put
the
files
at
the
depth
json
or
the
redirect
bindings
on
top
of
the
binary,
and
then
it
works.
A
You
know,
but
that
is
something
that
is
not
a
realistic
scenario.
I
think
for
people
to
do
that.
Once
more,
I'm
going
to
repeat
myself
here,
but
the
same
problem
that
happened
with
diagnostic
source
can
happen
with
source
instrumentations.
A
So
for
the
time
being,
on
the
branch
that
we
are
using,
the
sdk
we
are
requiring
people
to
beforehand
tell
which
instrumentations
they
want
the
case
for
that
is
because,
if
the
source
instrumentation
depends
on
a
library
in
the
application
and
we
try
to
load
that
is
going
to
fail.
A
A
So
I
I
hope
this
is
kind
of
the
information
that
kind
of
describes
the
situation
that
we
are
setting
up
using
the
sdk
and
the
diversion
problems
that
we're
gonna
have
down
the
line
and
the
limited
solution
that
we
have
for
the
time
being.
A
So
I
think
that
covers
kind
of
the
overview
of
the
issue
and
the
scenario
and
where
we
are
any
comments,
questions.
B
A
I
I
think,
since
it's
basically,
we
are
looking
for
a
way
to
do
a
a
rewrite.
That's
why
I
I
said
aspect-oriented
programming.
I
really
didn't
explore
a
lot
doing
things
like
il
rewrites,
but
that's
also
a
venue,
that's
possible
for
that.
You
know
like
the
same
way
that
tools
like
that
do
coverage
code
coverage,
for
instance,
do
we
could
have
done
seen
something
in
this
path?
You
know.
E
A
E
B
A
So
so
you
are
thinking
more
along
the
lines
of
let's
say,
tracing
the
diagnostic
tools.
A
A
They
actually
have
access
to
rich
information
from
the
things
that
they
are
instrumenting,
you
know,
so
did
I
lose
internet
here
everything
seemed
frozen.
I
can.
A
Oh
okay,
so
but
the
bytecode
instrumentation
they
have
access
to
the
rich
information.
So
think,
like
it's
a
object
instance,
we
can
access
the
properties.
We
can
access
the
parameters
through
the
method
and
that
allows
the
instrumentation
to
generate
reach
trace
information.
A
G
G
So
specifically,
it's
is
it
looking
at
the
activity
source
and
some
of
the
data
that
gets
thrown
onto
the
activity
or
diagnostic
source,
even
where
you've
got
a
diagnostic
event,
and
you
just
have
your
http
request,
object
available
in
memory
on
that
and
then
the
source
instrumentation
actually
then
reads
that
request,
object
and
extracts
all
of
the
tags
that
gets
added
to
the
activity.
Ultimately,.
E
Correct
yeah,
I
I
I
think
I
think
so.
For
instance,
I
mean
give
an
example.
I
think
that
chris
says
that
he
doesn't
imagine
how
it
would
work
if
something
will
be
instrumented
that
outputs
way
it
will
create
like
a
span
and
then
using
source
instrumentation.
Someone
would
like
to
create
a
child
span
to
that.
One
correct
chris,
for
example,.
G
Yeah,
so
I
I
don't
know
how
it
would
work,
because
it's
relying
on
that
diagnostic
source
and
diagnostic
listener.
F
E
G
D
D
Stepping
back
sort
of
the
the
out
of
process
etw
model
has
a
lot
of
advantages
for
specific
use
cases
and
it
sort
of
exists
and
applications
can
emit
telemetry
using
etw,
but
the
the
current
kind
of
space
of
distributed
tracing
is
really
about
collecting
and
bringing
together
some
information
that
is
not
available
in
that
way,
and
that
is
one
is
my
new
instrumentation
one
way
or
another
short
or
long
term.
D
We
have
to
have
that
and
then
things
that
are
emitted
from
the
libraries
using
you
know,
because
they
have
telemetry
and
also
using
some
sort
of
bytecode
instrumentation
for
libraries
who
are
not
yet
or
did
not
choose
to,
and
these
things
need
to
be
somehow
brought
together
in
a
consistent
model
where
it
all
fits
and
and
hierarchically
and
and
and
semantically
and
all
of
this
stuff,
and
that
just
is
very,
very
hard,
if
not
impossible,
to
do
in
a
kind
of
out
of
proc
model
where
you
just
shoot
events,
so
I
think
that's
kind
of
the
overall
historical
conclusion
of
the
of
the
industry.
D
A
I
I
think
the
80
double
knowledge
events
event.
Pipe
analogy
is
very
good.
The
the
thing
is
that
we
still
be
depending
on
the
library,
should
do
that
kind
of
instrumentation
for
us
should
take
advantage.
A
I
think,
while
we
still
have
bytecode
instrumentations
and
that's
the
thing
that
we
mentioned
from
time
to
time,
that
I
don't
know
in
my
mind,
I
put
that
horizon
kind
of
at
least
for
the
next
five
years.
We
are
going
to
be
needing
that.
That's
just
me
guessing
a
number.
I
I
think
they
need
to
reduce
in
the
future,
because
the.
A
Diagnosis
was
a
part
of
their
own
time
and
being
being
part
of
their
own
time.
They
will
become
kind
of
the
standard
and
net
typically
kind
of
converge
on
those
things.
So
I
think
perhaps
now
in
the
future
we
could
look
at
something
hey.
We
just
consumed
the
activities
via
ivent
pipe
and
generate
the
data,
but
while
you
still
need
bytecode
instrumentation,
I
think
there
is
no
way
you
have
to
make
it
up
mock
it
up
with
the
il
and
to
generate
kind
of
valuable
data.
A
We
also
need
access
to
the
properties,
the
parameters
and
all
that
things
that
that's
my
take.
So
I
would
say
that
at
least
for
the
next
five
years-
and
perhaps
I
will
be
saying
for
the
next
five
years
or
more
five
years-
I
I
think
we
still
need
byte
code
instrumentation,
you
know
and
we
need
to
change
the
il
and
that
gets
back
to
kind
of
we
have
the
profiler.
That
is
the
kind
of
standard
way
of
doing
that
in
the
past.
A
There
are
other
tools
that
use,
for
instance,
il
rewrites
at
the
time
of
the
the
the
building
like
coverage
code
coverage
tools.
Typically,
do
that
instead
of
styling
profiler,
but
I
I
think
the
most
flexible
and
generic
option
is
really
the
profiler.
A
But
on
that
I
would
say
that
if
we
have
a
proposal,
kind
of
to
do,
io
rewrites
like
at
build
time
not
at
build
time,
but
on
top
of
existing
assembly.
That's
something
that
we
could
investigate,
but
that
is
kind
of
a
completely
break
from
the
model
that
we
have
from
upstream
and
the
model
that
we
have
exploring.
So
if
we
decide
to
go
that
route,
probably
is
kind
of
investigation
required
for
us
to
dig
deep
into
that
model.
You
know
and
just
and
and
to
be
fair.
A
I'm
not
sure
if
that
that
you
have
to
handle
the
dependence
kind
of
in
a
similar
way.
D
Just
as
a
I,
I
think,
you're
absolutely
right
as
a
addition
to
this
in
terms
of
long-term
strategy.
I
think
specifically,
a
normal
telemetry
may
or
may
not
be
converging
and
using
activities
in
in
the
mid
to
long
term,
and
I
hope
it
will,
but
when
we
talk
generally
about
il
rewriting
as
the
industry,
so
once
once
telemetry
like
well
once
the
normal
distributed
tracing
telemetry
gets
commoditized
because
everybody
emits
it
in
a
standard
way.
D
The
whole
ex
user
expectation
on
what
it
means
to
do.
Observability
will
evolve,
and
so
people
will
start
expecting
deeper
insights
into
the
application
and
potentially
even
interactive
insights
with
with
what
application
is
doing
and
so
modify
like
safely
and
carefully
modifying
an
application
in
production
will
probably
not
go
away
as
a
key
capability
for
observability
ever
telemetry.
Normally,
you
know
I.
I
started
a
span
because
this
call
happened
that
may
go
away
because
everybody
starts
using
activities,
but
people
will
say:
oh
can
I
do
you
know.
D
Can
I
find
something
else
about
my
running
application?
Can
I
collect
additional
information
in
a
specific
place
because
I'm
handling
a
live
site?
Can
I
do
something?
Can
I
tweak
something,
so
I
think
I
think
iot
writing
is
interesting.
A
Yeah-
and
I
I
think
via
the
profiler
is
the
natural
way
to
do
that.
You
know
I
I
would
say
in
in
top
of
that,
even
if
we
take
out
these
bytecode
instrumentations
here
and
I
think
there
will
be
space
for
things
like
hotel,
sdk
or
metrics,
even
on
top
of
simple
methods
like
people
want
to
collect
metrics
for
latents
on
methods,
you
know
that's
very
common,
so
this
is
something
that
definitely
with
the
metrics
are
coming
for
to
hotel.
A
Okay,
so
I
I
wanted
to
present
this
overview
and
kind
of
the
the
things
that
we
are
trying
to
do
to
work
around
and
be
aware
of
the
the
limitations
that
we
have
to
see
where
we
can
take
this
down
in
the
future
to
kind
of
solve
that's
problems,
especially
what
it's
called
the
devops
scenario.
You
know,
as
I
said,
I
think,
for
build
time.
A
We
can
right
now
it's
not
that
simple,
because
we
have
packages
we
don't
have,
but
we
could
organize
and
create
a
new
get
package
that
does
exactly
what's
needed
and
then
we
tell
people
add
the
reference
and
you
are
good,
you
know,
but
this
is
just
for
people
that
are
building
the
application
for
people
that
are
just
delivering
the
the
beats
that
will
not
work
for
sure.
You
know.
H
He's
sorry
to
jump
in
because
I
I
joined
a
little
late.
I
don't
know
if
raj
had
the
opportunity
to
present
his
demo
so
to
solve
that.
You
know,
like
you,
said,
devops
scenario,
which
is:
let's
assume,
let's
assume
you
know,
you're,
not
interested
in
byte
code
instrumentation
right.
We
just
need
to
add
in
the
hotel,
sdk
and
the
right
version
of
diagnostic
source.
Is
there
a
safe
way
to
do
it
from
a
without
relying
on
like
a
profiler?
H
A
I
I
I
think
that
he
he
showed
to
us
the
the
startup
hook.
I
think
it's
a
very
viable
option,
if
you
don't
to
add
bytecode
instrumentations
and
I
think
the
code.
This
was
something
that
I
think
we
mentioned
the
same
code
that
does
the
initialization
of
the
sdk,
with
the
same
configurations
that
we
actually
are
adding
a
lot
of
them
to
the
sdk
via
environment
variables.
You'll
be
you'll,
be
kind
of
a
common
code
for
what
the
profiler
use
you
know.
A
So,
basically,
you
have
two
ways
to
bootstrap
the
sdk
into
application.
You
can
bootstrap
via
the
profiler
or
you
can
bootstrap
via
the
startup
hooks,
but
we
we
also
mentioned.
I
think
it's
in
the
recording
some
limitations
of
the
startup
rook
so,
for
instance,
us
as
vendors.
We
have
a
lot
of
people
in
dotnet
framework
and
that
is
not
covered
by
the
startup
hook
at
this
time.
B
A
Yeah,
so
I
think
perhaps
if
this
is
something
that
a
scenario
that
microsoft
has
interest,
perhaps
we
can
start
working
on
having
this
kind
of,
because
I
really
think
that
the
code
that
does
the
hotel,
sdk
and
perhaps
even
the
source,
instrumentation
injection,
it
should
be
common
to
both
scenarios.
You
know
both
for
the
instrumentation
via
the
profiler
and
using
the
startup
hooks,
and
then
we
have
these
two
options
for
people
that
want
to
leverage.
A
A
So
saurabh
and
raj,
if
this
is
something
that
you
want
to
pursue,
we
kind
of
should
try
to
kind
of
put
in
in
a
small
high
level
very
high
level
plan.
So
we
have
these
two
kind
of
deliverable
ways.
You
know
for
the
the
the
project
itself.
H
So
the
the
one
hesitancy
that
I
have
when
I
hear
you
say
you
want
to
use
the
profiler
approach,
because
I
I
know
part
of
the
motivation
is
sharing
some
of
that
instrumentation
code.
Between.Netcode.Net
framework
right
is
that
it's
by
like
catering
to
the
least
common
denominator
oftentimes,
you
see
the
the
profiler
actually
disables
a
lot
of
optimizations
of
work
that
we've
done
in
the
runtime.
H
Like
you
know,
we
don't
you
turn
off
multi-tier
jit,
like
you
turn
off
reach
it
on
attach,
and
it's
I
think
the
the
fear
is
that
the
observability
overhead
becomes
much
larger
than
it
needs
to
be.
If
so,
if,
if
we're
saying
that's
not
the
case
and
we're
going
to
use
the
latest
and
greatest
like
profiler
tech
to
make
sure
we
don't
regress
performance,
that
means
you've
already
signed
up
to
sort
of
like
have
a
fork
in
the
road
between
what
the
dot
net
core
approaches
and
the
dot
net
framework
approaches
right.
E
I
will
just
send
you
a
hyperlink
in
on
slack
in
a
second,
and
I
can
just
say
a
few
words.
H
G
So
so
there
is
a
gotcha
still
even
with
net
core
in
that
there
are
libraries
that
people
are
caring
about.
That
does
not
have
source-based
instrumentation
for
today,
and
so
they
still
rely
on
bytecode
instrumentation
to
happen,
and
so
we
would
still
need
to
leverage
the
profiling
apis
for
for
that
case.
H
H
Can
I
ask
what
are
the
library
like
the
the
popular
libraries
that
need
bytecode,
instrumentation
and
don't
have
source
instrumentation
today?
Is
that
something
that
is
like?
I
don't
know
proprietary
business
knowledge
for
each
of
you
apm
vendors,
or
is
that
something
that's
common
knowledge
and
you
can
share.
A
This
is
typically
open
source.
All
the
vendors
typically
have
their
their
their
instrumentations
open
sources.
Basically,
there
is
stuff
like
libraries
for
kafka,
confluent
kafka,
mongodb.
A
Yeah
yeah,
there
are
other
databases
that
they
they
don't
have
diagnostic
source.
They
don't
use
that
diagnosis
for
us
and
some
of
them
even
don't
have
good
hooks
that
you
could
plug
it
to
generate
tracing
data,
and
I
I
would
say
that
probably
we
have
in
this
repo
based
on
the
work
from
upstream
from
the
the
team
of
zack
and
greg.
We
have
like,
I,
my
guess,
will
be
20
that
are
only
available
with
the
instrumentation
they
they
they
have.
A
This,
I
guess,
is
a
number
I'm
kind
of
ballparking
here
and
there
is
like
10.
Perhaps
that
are
things
that
could
use
kind
of
instrumentation
from
the
the
web
socks
or
these
kind
of
things
to
to
kind
of
be
source.
Instrumentation
asp.net
core
stuff,
like
that.
That
already
has
a
diagnostic
observer.
But
sorry
I
I
digress.
The
point
is,
I
think
we
have
from
a
set
like
of
around
30
to
40.
I
think
about
a
third
of
those.
Are
things
that
we
can't
do
with
source
instrumentation?
D
D
Actually,
yes,
absolutely
and
in
addition,
also
in
some
cases
where
diagnostic
source
administration
instrumentation
does
exist.
In
the
library
vendors
collect
additional
information,
vendors
still
use
bytecode
because
they
feel
that
what
diagnostic
source
provides
is
not
enough
and
they
want
additional
details.
A
A
So
to
to
chris
point,
I
think
we
we
still
see
the
need
for
the
bytecode
instrumentation.
That's
why
we
think
the
profiler,
I
think
greg
also
iterated
the
same,
but,
as
I
said,
I
I
do
think
that
the
startup
hook
is
a
very
useful
path.
You
know,
as
I
said,
for
lambda
and
functions.
I
think
this.
This
kind
of
approach
is
really
good.
It's
small
code.
A
You
can
put
your
dependencies
once
there
and
kind
of
doesn't
have
to
change
much
and
you
are
not
going
to
pay
as
much
a
startup
cost
as
like
having
the
clr
profiler.
That
is
very
important
for
lumbed
and
functions.
You
know.
H
A
C
A
A
So
so
yeah
I
I
think
that
is,
is
the
idea
kind
of
we
can
share
this
work
for
this
bootstrapper
and
if
it's
going
to
be
injected
via
the
profiler
or
via
the
the
startup
hook,
it
should
be
independent
of
that
and
in
line
with
that,
robert
and
david-
that's
not
here
today
they
haven't
been
doing
a
lot
of
changes
on
the
sdk
themselves,
so
that
supports
the
stuff
that
we
need,
like
environment
variables,
any
initialization
with
proper
information.
For
for
that
to
happen.
A
And
I
think
from
our
perspective,
then
down
the
road.
What
would
look
like
what
at
least
if
we
don't
have
a
better
solution
for
that
is
kind
of
we'd
like
to
kind
of
have
some
way
of
facilitating
that
devops
scenarios?
In
the
case
that
people
just
have
the
assemblies
you
know,
because
we
still
want
to
be
able
to
inject
byte
code
instrumentation
there,
so
we
we
still
need
to
fix
the
dependencies.
A
On
that
case,
you
know
and,
as
I
said,
we
know
some
workarounds,
but
they
are
not
really
user
friend,
you
know
and
that's
the
path
that
we
you
want
to
look.
I
think
I
can
provide
these
small
descriptions
that
we
have.
I
can
find
a
link
and
then
I
post
post
on
the
slack,
but
then
you
you
can
see
the
high
level
gist
of
what
are
these
workarounds.
A
So
we
need
to
ensure,
for
instance,
the
sdk
requires
a
minimal
version
of
the
diagnostic
source
assembly.
So
we
need
to
ensure
that
that's
the
one
that's
loaded
at
build
time.
We
can
just
ask
the
user
to
kind
of
have
a
if
he
doesn't
reference
it's
fine,
but
if
he
has
a
conflict
we
can
ask
them
to
have
a
reference
to
the
correct
nougat
version
and
the
algorithm
to
solve
the
nougat
conflict
version
you
get
to
the
one
that
we
need,
because
it's
a
direct
reference
by
the
application.
A
But
if
we
just
have
the
assemblies
we
don't
have
the
build,
that's
not
possible.
So.
H
F
H
Think
that's
valuable
to
show,
but,
like
the
I'll
just
give
the
high
level
overview
is
we
the
app
can
load
whatever
version
of
diagnostic
source.
It
comes
with
and
in
a
separate
load
context
in
a
separate
assembly
load
context,
we
load
the
version
of
diagnostic
source
required
for
the
hotel,
sdk
and
then
load
the
entire
hotel
sdk
as
well,
and
then
we're
basically
creating
these
proxy
activity
objects.
So
we
can
subscribe
to.
H
We
can
subscribe
to
either
diagnostic
source
or
activity
source
in
the
default
load
context,
and
then
we
create
these
proxy
activities
so
that
instrumentation
packages
loaded
in
the
the
additional
assembly
load
context
will
now
fire
and
the
sdk
works
as
intended.
H
So
just.
A
Just
thinking
about
one
thing
here,
how
how
it
will
work,
profiler,
plus
startup,
hooks.
A
H
G
F
This
approach
should
work
for
the
self
contact
and
also
the
startup
book.
F
The
I
think,
in
the
last
time,
I've
shown
a
demo
with
the
simple
startup
hook,
how
we
can
do
a
console
exporter
so
in
this
one
and
in
what
I
was
showing
that
when
I
was
showing
that
that
we
have
a
reference
to
diagnostic
source
and
everything.
So
in
this
one,
I
just
made
a
like
sort
of
explain
that
clearly
like.
F
If
you
look
at
here,
this
startup
hook
is
of
3.1
and
loaded
in
an
application
which
is
also
3.1,
and
this
is
the
asp
net
core
application,
and
I
have
a
very
simple
controller
here,
which
does
like
three
system.net
calls
over
here,
and
I
don't
have
any
system.net
reference
here
or
in
the
startup
hook.
So
I
use
whatever
that
comes
up
with
the
framework,
I'm
just
executing
to
show
how
the
modules
list
will
look
like
more
than
the
code,
because
code
is
there
part
of
github
anyways.
F
Let's
give
it
a
minute:
it's
building.
G
F
So
you
can
see
the
two
versions
are:
diagnostic
sources
are
loaded
here,
one
is
from
the
app
which
is
of
the
4.7
version,
and
another
one
is
from
the
6.0,
which
is
from
the
open
telemetry.
F
So
what
we
do
here
is
like
whatever
the
application
application
creates
a
activity,
and
there
is
a
diagnostic
listener
in
the
startup
service,
startup
hook
that
listens
to
the
activity
that
gets
created
by
the
application
and
after
listening
to
it,
what
we
do
is
we
create
a
proxy
activity
for
the
diagnostic
source,
six
using
the
reflection-
and
we
put
it
in
the
like-
we
create
a
new
activity
over
there.
F
That's
a
good
dependency
also.
Now
let
me
quickly
show
what
is
happening
in
the
at
the
code
level,
so
I
have
a
like
a
diagnostic
subscriber
and
a
listener
which
is
going
to
call
at
the
end
of
the
day
these
ones.
So
if
you
look
at
here,
this
is
the
proxy
activity
that
I
we
create.
We
create
activity,
source,
dot,
stat
activity
using
reflection,
and
we
take
the
activity
that
is
created
from
this
application
and
details
from
that
and
we
create
a
new
activity
in
the
diagnostic
source.
F
Six
and
if
we
have
open
telemetry
already
listening
on
this
net
core
instrumentation
the
moment
we
do
that
it
just
understands
that
activity
and
then
picks
it
up
and
all
we
need
to
do
is
again
in
the
stop
activity,
get
the
current
activity
using
the
reflection
part
and
like
call
the
http
in
listener
in
the
open,
telemetry
the
stop
like
on
stop
activity
and
then
call
the
activity
stop.
This
does
the
magic
for
us.
So
maybe
this
is
a
prototype.
We
may
need
to
work
a
little
more
than
what
is
needed
here.
F
D
Yeah,
I
think
I
think
this
is
actually
this
is
very.
This
is
very
similar
to
to
to
what
the
dynamic
bindings
approach
was
doing.
You
remember
the
the
stuff
that
we
looked
at
a
few
months
ago.
D
So,
if
I
understand
correctly-
and
I
I
I
I'm
not
sure-
because
I
always
see
this
for
the
first
time-
it's
very
very
similar-
the
idea
is
that
we
dynamically
look
at
what
the
application
is
using
and
if
it's
using
the
right
thing,
then
we
are
just
using
that
diagnostic
source
version
and
if
it's
not
using,
then
if
it
doesn't
use
the
right
thing,
then
we
load
diagnostic
source
proactively
from
somewhere
and
use
that
and
then
I
think,
with
the
difference
between
you,
what
you
guys
showed
and
what
we
looked
at
and
then,
if
you
remember
there
was
a
demo
that
I
showed
a
few
months
ago.
D
Is
there
will
be
probably
some
caveats
around
performance,
how
you
use
reflection
and
there
will
be
some
caveats
around
the
whole
safety
of
the
whole
thing
with
the
with
the
different
load
context.
So
I
think
the
this
is
using.
This
is
loaded
twice
into
a
different
lot
context
and
what
I've
went
for
in
the
other
prototype
is.
I
use
a
vendor
inversion
where
we
just
compile
a
copy
of
diagnostic
source
into
the
library.
D
That
does
all
this
logic,
and
if
it
finds
that
the
version
loaded
by
the
application
is
not
the
right
one,
then
it
starts
forwarding.
D
To
true
that
vendored
inversion,
but
I
think
that
there's
a
very
similar
idea
which
essentially
solves
the
problem
in
a
very
similar
way.
So
you
think
there
will
be
some
caveats,
but
both
should.
I
I
have
question
on
this:
is
it
correct
that
it's
always
going
to
create
we're
basically
going
to
have
two
stacks
of
activities,
one
from
the
application
and
one
from
the
instrumentation.
D
D
That
might
that
might
be
another
difference
between
these
two
approaches.
I
I
just
pasted
in
into
the
chat
for
you
guys,
if
you,
some
of
you,
know
this
for
the
for
those
who
don't
know
this.
I
posted
the
links
to
that
prototype
into
the
chat.
The
one
difference
there
was
that,
essentially
it
said
the
applications
use
application
users
activities
in
whatever
way
it
wants.
The
demo
actually
focused
on
diagnostics,
but
activities
would
work
in
the
same
way
and
then
our
staff,
it
doesn't
use
activities
directly.
D
It
uses
a
very
thin
proxy
api
layer
that
essentially
just
is
a
repetition
of
the
activity
api
layer
and
that
proxy
api
layer
what
it
does
if
it
if,
if
diagnostic
source
is
loaded,
then
it
forwards
all
the
calls
to
the
activity
to
the
two
diagnostic
source
that
is
loaded,
and
if
it's
not
loaded
or
it's
loaded
in
a
bad
version,
then
it
forwards
all
the
calls
into
into
the
vendor
and
the
compiled
inversion
of
diagnostic
source.
D
The
the
advantage
of
that
is
that
you
never
get
your
activities
you
have
in
terms
of
performance,
it's
very
very
fast.
The
disadvantage,
of
course,
is
that.
D
You
have
to
compile
in
diagnostic
sources
in
here,
so
if
diagnostic
source
gets
like
some
sort
of
upgrade,
there
is
like
an
additional
step
of
like
shipping
that
technology
and
rebuilding
it
or
the
whole
thing.
But
overall
it's
a
very
similar
idea
to
combine
diagnostic
search
version
and
memory
and
processing.
F
I
did
have
that
discussion.
I
did
look
into
that
vendor
diagnostic
source
approach
earlier,
so
I
had
a
discussion
with
tariq
and
the.net
team,
so
they
kind
of
like
not
like
inclined
with
the
option
of
like
entirely
cloning,
the
diagnostic
sorcery,
like
code
into
our
repo
and
because,
whatever
the
like
challenges,
you
called
out.
We
may
end
up
in
like
hitting
that.
So
that
is
the
reason
that
we
came
up
with
this
one.
F
D
Sure
there
are
pros
and
cons.
I
just
wanted
to
make
sure
that
you're
you're
eyewear
of
the
thing
and
then
you
can
consider
because
there
will
be
pros
and
cons
to
each
way.
H
I
E
Doesn't
it
require
like
this
proxy
if
there's
any
different
version,
not
only
lower.
H
It's
whatever
yeah,
I
guess
right
now.
There
is
nothing
lower
than
what
the
sdk
hotel
sdk
has
a
dependency
on,
but
you're
right
that
there
would
be
a
that.
That
could
be
a
problem
in
the
future
like
higher
and
lower.
A
So
I'm
I'm
just
stepping
back
a
little
bit
of
with
the
work
around
so
kind
of
thinking
for
these
applications
that
this
devops
scenario,
let's
say
that
we
need
to
deploy
a
fix,
a
a
fix,
a
security
fix,
would
be
the
best
example
actually
and
it's
for
a
nuget
package.
The
only
way
to
do
that
as
of
right
now
is
a
rebuild
of
the
application.
A
A
You
know
I
I
I'm
kind
of
sidestepping
going
back
to
the
other
route,
but
I
I
I
think
it's
basically
the
same
problem
that
we're
trying
to
solve
you
know
and
if
we
are
able
to
solve
that,
I
think
the
the
path
of
avoiding
the
need
to
have
the
rapper
and
kind
of
resolving
the
version.
It's
the
kind
of
best
end
game
possible.
You
know
we
avoid
the
considerations
of
performance
and
the
careful
of
the
versions
we
we
kind
of
build
against
the
versions
that
we
target.
A
You
know
and
we
have
a
way
to
fix,
fix,
update
the
applications
to
satisfy
those.
H
Constraints,
so
so,
yes,
we
have.
We
have
something
in
in
the.net
host
that
we
call
hammer
servicing,
which
we
can
force
upgrade
in
any
assembly,
but
we
like
really
really
don't
want
people
using
that
that's
for,
like
critical
security
updates,
the
simplest
way
to
describe
it
is
think
of
it
as
something
like
ld
preload,
where
you
can
just
lord
of
your
version
of
the
assembly.
H
Instead
of
what
the
host
wants
to
load
right
and
yeah,
we
have
that,
as
like
a
for
critical
security
releases,
I
I
can
say
that
we've
never
had
to
use
this
in
the
what
six
seven
years
of
dot
net
core
that
we've
done-
and
you
know
hopefully
like
that's
good
things,
stay
that
way.
H
What
what
we
but
based
on
that.
What
we
are
keen
on
doing
is
adding
like
functionality
into
the
host
that
allows
you
to
upgrade
up
a
certain
version
of
an
assembly.
So
today,
one
of
the
like
the
limitation.
The
reason
why
we're
forced
to
create
this
whole
proxy
thing
is:
we
can't
force
the
host
to
upgrade
up
a
version
or
load
a
different
version
of
an
assembly.
That's
already
present
in
the
tpa
list
right
so
like
what
happens,
is
the
app
references
net
core
app
net
core
app?
H
Has
a
version
of
system
diagnostics,
diagnostic
source?
So
that's
present
in
the
tpa
list.
So
when
you
try
to
do
assembly.lord,
remember
not
assembly.lord
file
that
loads
into
separate
context.
When
you
do
assembly.lord
and
lords
enter
the
default
context,
the
host
will
explicitly
stop
you
from
upgrading
up
a
version
because
it's
hey.
I
know
this
is
a
trusted
version
right.
It
came
through
the
depth.json
or
something
so
what
I'm
keen
on
doing
is
in
the
dotnet
seven
time
frame
work
on
an
ability
to
tell
the
host
that
hey.
H
I
know
what
I'm
doing
is
potentially
dangerous,
but
let
me
upgrade
up
the
version
of
this
assembly
right,
but
because
it's
a
it's,
a
like
changing,
loader
behavior
is
a
huge
change
and
again
this
is
what
what
I
want
to
do.
Isn't
something
that
necessarily
the
the
team
that
owns
the
host
wants
to
right.
I
have
no
guarantees
that
will
happen
yet,
but
I
I
think
that
would
be
a
good
long-term
approach.
H
A
Yeah,
I
I
I
where
I
stand
right
now
and-
and
I
think
the
other
folks
can
chime
in
what
they
they
they
think.
But
I
think
that
I
think
the
the
solution
with
the
startup
hooks
has
a
definite
scenario
for
that.
The
demo
wrapping
around
the
multiple
versions
also
has
some
scenarios
for
that.
But
on
the
other
hand,
I
can't
let
it
go
because
of
the
things
that
we
talked
about
by
the
code.
Instrumentation
net
framework
support,
I
think,
at
least
from
from
the
perspective
of
my
company.
A
We
still
need
to
go
there
out
of
the
profiler.
You
know,
I
think
we
can
have
the
synergy,
as
I
said,
kind
of
sharing
the
bootstrap
code
and
we
can
work
on
this
together,
but
we
also
have
to
do
on
our
side
investment.
Should
the
cll
profiler
path.
You
know,
I
think
we
we
can't
negate
that
by
a
cla
profile
and
by
code
instrumentation,
for
the
reasons
that
I
think
chris
greg
and
others
here
chimed
in.
A
We
need
that,
but
I,
as
I
said,
I
do
see
a
lot
of
potential
for
us
to
have
the
kind
of
that
collaboration.
They
start
up
and
if
you
wanna
kind
of
having
this
startup
via
self-host
in
open
telemetry,
we
are
kind
of
able
to
collaborate
on
that
and
he
also
put
some
resource
into
that.
A
A
G
I
do
have
a
quick
question
regarding
the
upstream
sync.
I
just
happened
to
come
across
some
code
owner
files
in
there
do
we
want
to
merge
those
as
is
or
do
we
need
to
address
them.
A
I
I
think
we
we
should
address
some
of
that
stuff
I
actually
had
put
in
the
end
of
the
meeting,
because
I
wanted
to
talk
specifically
with
zach
and
greg
about
that,
because
for
now
I'm
doing
the
pool
as
it
is,
but
we
have
that
thing
about
the
headers
and
all
that
stuff.
So
I
don't
wanna
rush
that
I
wanna
that
we
have
a
conversation
there
and
kind
of
really
do
that.
A
The
the
right
way
you
know,
like,
I
think,
last
time
we
we
removed
the
headers
and
we
had
zach
merging
because
it's
the
open,
telemetry
way
of
saying
kind
of.
Oh,
it's
agreed
between
the
parts.
So
I
want
to
be
sure.
Are
you
going
to
do
the
same?
Are
you
not
going
to
do
the
same
and
also
I
I
think
we
talked
there
on
the
thread
and
then
we
put
the
cold
owners
there.
It's
also
possible
that
I
missed
something
else,
because
the
code
moved
so
in
the
move
of
the
code.
G
G
A
All
right,
then,
thanks
for
your
time.
Everyone
thanks
for
the
demo
raj
thanks
for
the
conversation
and
see
you
guys
soon,.