►
From YouTube: 2020-09-02 .NET Auto-Instrumentation SIG
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
A
A
Just
a
reminder
to
people
to
sign
up
on
the
attendees
for
the
meeting
if
they
have
a
chance
and
the
usual,
if
there
is
somebody
that
is
joining
us
for
the
first
time.
Please
take
this
chance
to
introduce
yourself
and
let
us
know.
D
I'll
do
that,
if
you
guys
don't
mind
hi
there,
my
first
time
here
my
name
is
michael.
I
joined
the
dotnet
group
last
night
also
yesterday,
for
the
first
time,
I'm
looking
to
start
using
open
telemetry
in
the
system.
We
have
a
work.
We
are
a
kind
of
standard,
three-tier,
winforms
app
and
we
have
data
remoting
and
ssrs
as
well.
So
I
thought
it'd
be
interesting
to
see
if
there's
anything
useful,
I
can
help
with
kind
of
with
instrumenting,
remoting
or
srs
itself.
D
D
E
Yeah
I
used
to
but
disappeared
sorry
the
document
with
the
notes
I
lost
access.
I
cannot,
I
cannot
put
myself
in.
E
By
the
way,
since
you
mentioned
remoting,
this
is.
G
F
G
E
This
moment
is
a
joke
to
microsoft,
people
but
seriously
another
emoting
guys.
I
mean
when
I
saw
this
and
and
we
have
some
customers
for
using
it
and
seriously
like
so,
there
was
not
enough
remoting
in
the
dot-net
framework,
so
we
moved
on
to
core,
and
now
we
have
azure
service
fabric
remoting.
Oh
my
come
on.
E
And
the
thing
is
it
does
what
remoting
does
sort
of
it's?
It's
a
it's
a
remote
procedure
invocation
protocol
and
it's
not
grpc,
it's
it's
kind
of
like
grpc,
but
it's
not.
E
To
make
it
serious,
I
would
actually
be
curious
to
learn.
E
I
realize
that
this
is
the
wrong
team
to
ask,
but
I
would
be
curious
just
for
my
personal
education
to
learn
why
the
azure
service
fabric
team
believed
that
building
a
protocol
there
was
necessary
just
for
education,
but
I
guess
we
might
never
learn
about
this.
G
Yeah
yeah,
no,
I
I
realized
that
we
were
just
looking
at
this
recently
and
were
you
were
you
on
the
team.
F
When
raja
was
the
death
manager,
was
that
yes,
time
frame?
Yes,
okay,
and
do
you
know
that
he's
now,
I
think
a
depth
manager
in
service
fabric?
Oh
really,
yeah,
interesting!
No,
so
you
actually
have
the
right
past
contact.
If
you
want
to
go
you're
doing
it.
E
I
should
I
should
check
with
him,
but
luckily
what
for
the
for?
The
relevance
for
this
group
is
that
that
protocol
seems
to
support
the
headers
necessary
to
do
trace
context
propagation,
because
it's
it's
a
l7
protocol
over
l5
right.
So
it's
application
over
tcp
and
it
seems
that
they
have
the
right
headers
for
context
propagation,
and
so,
from
our
perspective,
we
are
not
upset.
A
Okay,
so
just
giving
a
quick
update
here
about
what
I
I'd
say,
not
much,
not
a
lot
of
activity.
I
think
a
lot
of
people
are
kind
of
on
summer
vacations.
I'm
I'm
starting
my
one
this
week,
so
I'll
be
going
for
a
week
and
a
half
last
week
was
greg,
and
now
I
think
mihail
from
from
microsoft
is
also
on
vacation,
so
and
chris
is
also
on
vacation
from
from
new
relic.
A
We
have
the
this
stuff
to
start
the
ci,
but
actually
only
people
from
open
telemetry
committee
has
their
rights
to
enable
the
azure
pipeline
app.
So
I
pinged
some
people
to
get
that
enabled,
so
we
should
have
start
ci
very
soon
and
we
should
be
able
to
kind
of
start
to
do
the
changes
with
our
confidence
based
on
on
the
tests.
A
Besides
that,
we
had
a
bunch
of
follow-ups
from
last
meeting,
we
didn't
do
much
on
those
because,
as
I
say,
a
lot
of
people
on
vacation
are
out.
I
think
the
the
main
thing
that
we
discussed
and
kind
of
having
outline
from
the
last
time
is
about
a
road
map
and
the
issues
that
we
open.
So
I
think
basically,
if
we
go
back
to
what
we
discussed
on
that
last
meeting.
A
So
there
is
this
conversation
about
multiple
versions
of
about
the
same
assembly.
That
mihail
said
that
he
already
has
some
practice,
and
I
I
hope
that
the
guys
from
the
profiler
know-
and
they
can
help
us
with
kind
of
the
path
to
to
go,
how
to
properly
handle
that.
E
I
created
an
issue
as
discussed
last
time,
but
so
far
I
only
like
so
far.
It's
a
placeholder
like
we
discussed
to
collect
information
there.
So
the
issue
is
there,
but
not
much
content.
Is
there
yet.
A
E
Target
for
for
this
particular
one,
my
target
by
the
end
of
the
current
sprint,
is
to
like
right
now
we
have
a
working
prototype,
but
it's
very,
very
raw.
It's
just
proof
of
concept,
but
my
target
for
the
end
of
the
sprint,
which
is
a
week
and
a
half
from
today,
is
to
have
something
that
is
kind
of
has
maybe
not
completeness,
but
the
look
and
feel
of
what
I
envisioned
to
be
the
end
result,
and
then
that
would
be
a
good
point
in
time
to
start
reviews.
E
Should
you
get
some
early
feedback
and
whatnot
by
the
way
david
noah?
Should
I
ping
you,
or
should
I
ping
the
azure
monitor
guys?
Should
I
ping
all
of
you
to
get
a
little
to
have
a
maybe
a
brief
offline
discussion
about
how
to
correctly
deal
with
the
versioning
conflicts
of
system
diagnostic
dll,
because
maybe
if
it
requires
taking
dependency
on
a
version
that
is
not
the
latest,
then
it's
the
earlier.
I
know
the
better.
F
I
I
mean
yeah,
you
could
certainly
put
me
david
and
kyle
will
probably
have
some
opinions
as
well.
We've
been
talking
to
him
about
it
for
a
while.
That's
probably
a
good
group
of
us.
A
A
I'll
pick
up
the
link
to
the
issue
and
put
on
the
the
notes,
so
people
can
find
it
easily
on
the
the
notes
of
the
meeting,
so
actually
for
from
from
my
perspective,
is
more
important
about
us
doing
these
follow-ups
and
kind
of
really
because
we
discussed
at
the
high
level
the
road
map-
and
we
have
kind
of
these
things
to
pursue.
A
But
I
think
the
important
thing
is
kind
of
having
an
agreement
about
this
world
map
with
everyone.
You
know.
So,
if
any
anybody
here
kind
of
wants
to
propose
or
work
on
something
that
is
not
covered
on
the
roadmap
that
we
mentioned
and
look
at
prior
it,
it
would
be
nice
to
bring
this
stuff
up.
You
know.
E
Yeah
so
it
looks,
it
looks
like
by
the
way,
which
does
it
doesn't
really
matter,
but
it
looks
like
the
reality
of
of
things
seems
to
be
that
number
four
on
on
on
the
list
becomes
number
two
just
because
we
are
already
starting
to
work
on
number
four,
but
we're
not
yet
starting
to
work
on
number
two
and
three.
A
E
Mean
I
mean
I'm
already
actively
working
on
number
four,
but
I
am
not
aware
of
anybody
already
actively
working
on
number
two
or
number
three.
If,
if
you
guys
are
then
sorry
for
for
randomization,
but
I'm
just
not
aware
of
anybody
actually
working
on
it.
A
F
A
So,
let's
just
do
that.
A
So
I
don't
have
anything
more
to
go
over
if
you
guys
want
to
use
the
opportunity
to
discuss
some
of
the
technical
aspects
of
any
of
this
you'll
be
a
good
opportunity,
but
for
my
my
part,
we
can
follow
up
later
and,
as
I
said,
I
will
be
out
starting
this
friday
and
you'll
be
back
actually
in
the
next
meeting.
I
think
yeah
yeah
I'll
miss
the
meeting
next
week
and
the
I'll
be
back
on
the
meeting
after
that.
E
Okay,
yeah
so
we're
working
on
activity
source.
We
will
also
be
working
on
cold
targets
instrumentation
when
tony
is
back
from
his
vacation.
He
is
not
yet
back.
E
So
these
are
the
two
things
that
we
will
contribute
in
the
upcoming
future
and
we
are
we're.
Definitely
asking
for
help
is
from
microsoft,
about
this
versioning
thing
and
then
from
everybody
is
once
activity
sources
done
in
the
basics.
We
will
need
to
convert
all
the
existing
integrations
to
it,
so
that's
definitely
somewhere
where
you
guys
can
help
yeah.
E
If,
if
you
have
time,
maybe
we
can-
and
there
is
no
other
agenda-
maybe
we
can
chat
about
versioning
and
diagnostic
source
versioning
now,
so
that
we
don't
need
a
separate
meeting.
F
I'm
happy
to
chat
about
it
now.
I
I
do
actually
have
a
conflict
starting
at
1
30,
so
it
could
be
a
short
chat,
but
I'm
you
can
have
as
much
of
the
next
13
minutes
as
you
like.
Okay,.
E
Yeah
yeah,
absolutely
it's
it's
mainly
I'm
asking
for
like
anything
because
I
haven't
yet
looked
at
it.
I
mean
I
I
know
highly.
I
generally
understand
how
assembly
resolution
works,
but
in
all
the
caveats,
yeah.
F
Well,
okay!
Well,
let
me
let
me
just
sort
of
start
spewing
stuff
off
the
top
of
my
head
and
you
can
stop
me
and
ask
questions
so
I
will
say
this
is
historically.
This
has
been
a
thorny
problem,
there's
some
simpler
solutions
that
don't
quite
cover
all
the
cases
and
then
there's
solutions
that
everyone
sort
of
says.
Oh
man,
that's
complicated
that
probably
actually
handles
everything
and
you
kind
of
have
to
decide
where
you
want
to
be
on
that
spectrum.
Are
you
gonna,
you
know
gonna
do
it
all?
F
Are
you
gonna
accept
some
some
shortcuts
in
exchange
for
something
simpler
and
the?
I
guess
the
big
choice
to
be
made
is
there
are
solutions
that
force
that
force
the
act
to
use
sort
of
a
specific
version
of
diagnostic
source
or
like
have
a
specific
minimum
version
of
diagnostic
source
that
that
you
as
the
profiler
dictate
and
what
happens
below?
That
is
also
something
like
you
could.
F
Basically,
if
you,
if
you're,
going
to
let
the
app
choose,
what
version
of
diagnostic
source
it
wants
to
load,
then
realistically
the
only
solution.
I've
seen
from
the
profiler
perspective
is
you
have
to
be
prepared
to
use
reflection
to
do
late,
binding
against
any
api
that
you
might
want
to
use,
because
who
knows
if
it's
actually
there
or
not,
depending
on
how
old
of
a
version
diagnostic
source
that
is-
and
that
goes
all
I
mean
if
you
want
it
to.
F
It,
goes
all
the
way
down
to
the
premise
that
maybe
the
app
doesn't
load
diagnostic
source
at
all
and
then
and
then
now.
The
app
is
doing
nothing
with
diagnostic
source
and
you
have
to
decide
what
it
is
you're
going
to
do
in
the
profiler,
knowing
that,
if
you
were
to
load
any
version
of
diagnostic
source
into
the
default
assembly
load
context
or
if
we're
on,
if
we're
down
level
one.net
framework
into
a
you
know,
default
app
domain.
F
The
moment
that
you
do
that
load,
you've
now
sort
of
polluted
the
loaded
set
of
assemblies
and
if
the
app
tries
in
the
future
to
do
a
load,
they're
likely
they're
likely
to
just
get
whatever
you
already
loaded
for
them
and
not
what
they
would
have
gotten
if
you
hadn't
uploaded
anything
so
so
even
loading
loading,
the
assembly
is
sort
of
automatically
side
effecting
and
you've
kind
of
polluted
the
space.
F
F
The
challenge,
if
you
go
that
route
is
that
and
if
you
load
an
assembly
twice
like,
regardless
of
how
you
achieve
it,
each
one
of
those
assemblies
is
going
to
have
its
own
set
of
statics
and
thread
statics
and
basic
local
like
there.
They
will
be
distinct,
which
means
if
your
goal
is
to
have
a
single
chain
of
activities,
that's
being
tracked
across
the
thread
and
that
chain
the
root
of
the
chain
is
tracked
in
that
async
local.
F
It
won't
wind
up
being
a
single
chain.
It
will
wind
up
being
each
assembly
will
have
its
own
definition
of
what
the
chain
looks
like
and
they'll
have
multiple
parallel
chains
that
don't
connect
to
each
other
at
all,
so
that
usually
winds
up
scuttling.
Those
ideas
of
like
oh
we'll
have
multiple
versions
of
it
loaded.
F
That's
that's
probably
sort
of
what
makes
diagnostic
source
particularly
nasty,
is
that
if
it
was
just
the
profiler
coordinating
among
itself,
you'd
be
fine,
and
if
it
was
just
the
app
coordinating
among
itself,
you'd
be
fine.
But
the
fact
that
you're
trying
to
have
the
profiler
and
the
app
code
mutually
compose
this
data
structure
means
that
you,
you
have
to
agree
on
something.
F
So
so
when,
in
the
past,
when
we
talked
to
mikhail
at
microsoft,
he
has
usually
shied
away
from
like
these
reflection-based
scenarios,
because
they
sound
pretty
complicated,
and
I
mean
to
be
fair.
Like
there's.
Definitely
some
complexity
there.
I
don't
think
it's
like
uber
rocket
science,
but
it's
messy,
and
so
he's
done
a
variety
of
things
that
in
practice
have
worked
out
pretty
well.
E
Can
I
just
ask:
ask
you
a
question
so
in
a
generic
discussion
where
any?
If
it
was
any
library,
this
makes
complete
sense
as
a
set
of
trade-offs.
But
since
we
know
since
we're
talking
about
a
particular
library.
G
E
Additional
piece
of
information
that
is
probably
important
here
is
how
it
how
backward
compatible
it
has
been
over
time.
What
I
mean
is
if
it
was
always
additional
functionality,
but
never
functionality
break
then
loading
say,
say
we
say
we
had
to
pick
the
one
that
comes
with
five
and
right
always
enforced
for
that
to
be
loaded
over
something
that
is
older.
If
that
is
super
safe,
more
safe
than
for
a
genetically
picked
library,
then
you
know
it
would
be
good
to
understand
this.
F
F
F
E
I
actually
like
that
format.
I
let's
not
discuss
it
but
sure
I
I
was.
I
was
wondering
why
this
was
necessary.
It
was
a
cool
format,
but
whatever.
E
But,
but
I
think
I
think
for
as
far
as
distributed
aspect
of
this
is
concerned,
specifically
within
the
tracer.
E
I
think
we're
safe
as
a
group,
and
the
reason
for
it
is
that
the
mechanism
for
context
propagation
across
service
boundary
is
something
that
is
vendor-specific
anyway,
so
whatever
like
for
us.
For
example,
when
we
take
for
datadog
whatever
the
activity
does
in
proc,
when
we
attach
headers
to
things
being
placed
on
the
wire,
we
will
use
the
same
format
regardless
like
today.
We
don't
even
use
activities
at
all.
We
use
spence
right,
then
we
will
go
to
use
activities
and
that
change.
E
Then
there
are
other
languages
that
are
not
even
net
right,
so
we
must
make
an
assumption
that
we
don't
know
what
is
the
downstream
service.
So
this
must,
when
we
transition
to
using
activities
in.net,
we
must
not
break
any
downstream
or
upstream
applications.
E
So
the
logic
of
extracting
context
from
upstream
and
putting
context
into
downstream
must
be
pluggable
rather
than
default
activity
logic
so
that
every
vendor
can
plug
in
whatever
is
appropriate
for
their
distributed
system.
So
the
distributed
part.
I
am
not
so
worried
about.
I'm
more
kind
of
concerned
about
not
breaking
an
existing
application
right.
F
So,
as
far
as
I'm
aware
that
that
change
of
the
id
format
is
the
only
time
in
the
history
of
this
library
going
back
a
decade
or
something
that
we've
made
a
intentional
change
to
the
behavior
of
an
api,
anything
beyond
that
is
probably
just
like
a
bug
fix.
So
in
theory,
you
could
have
taken
a
dependency
on
some.
F
You
know
weird
corner
case
bug,
behavior
and
then
now
it's
fixed
in
the
next
version
of
the
library
and
and
then
maybe
you
know,
if
you
designed
your
scenario
right
now,
your
app
would
have
broken.
I
don't.
I
don't
think
I
have
any
evidence
of
that
ever
like
a
customer
coming
and
telling
us
that
that
had
happened
at
any
point
in
the
past,
but
it
is
conceivably
possible.
F
I
guess
also
in
a
sort
of
a
well
somewhat
of
a
future
looking
thing,
but
somewhat
even
of
an
issue
now
is
it's
not
always
trivial
to
force
the
version
of
the
assembly
that
you
want
to
load
to
get
loaded
like
in
in.net
core?
You
know,
there's
a
bunch
of
that.
You
know
there's
the
json
file
that
has
all
the
dependencies
of
the
app,
for
example,
and
then,
of
course,
that
thing
might
call
out
you
know
hey.
F
That's
intended
to
sort
of
force
the
right
version
of
an
assembly
to
load,
usually
what
it
wound
up
being
was
you'd
find
some
place
to
like
sort
of
gain,
control
of
the
manage
code,
execution
flow
and
then
you'd
go
off
and
you
do
some
like
assembly,
dot,
load
and
you'd,
give
it
a
literal
path
or
something
like
that
or
you
might
actually
have
to
go
on
disk
and
like
put
an
assembly
in
place
of
some
other
assembly
or
or
in
or
adjacent
to
an
assembly,
to
sort
of
force
that
the
assembly
version
that
you
want
to
get
loaded
actually
does
get
loaded
and
there's
yeah,
there's
sort
of
a
handful
of
hijinks
down
that
path
of
like
how
do
you
force
it
to
load
exactly
the
version
of
the
assembly
that
you
wanted,
even
when
that's
not
the
version
that
the
app
developer
specified
and
it's
not
what
was
present
at
build
time,
I'm
going
to
have
to
run
to
the
to
the
other
meeting.
F
So
sorry
to
cut
this
short,
but
I'm
happy
to
to
keep
chatting
about
this
either
offline
or
in
a
future.
You
know
open
sponsorship.
E
Yeah,
thank
you
very
much.
This
is
actually
super
useful.
I
have
some
follow-up
questions
to
ask
you
next
time.
Maybe
I'll
shoot
your
an
advice
to
have
a
brief
conversation
or
something
like
that
sure
yeah.
F
Just
yeah
like
I'll
pull
in
pull
in
david
and
myself,
and
if
the
aisles
around
it's
late
enough,
okay,
sorry,
everyone
gotta
run
thanks
guys
thanks
guys,
bye
thanks.
E
Yeah
this
is
this
is
very
interesting,
so
I
think
there
is
two
parts
is
which
version
should
we
be
loading
and
then
how
do
we
force
that
version
to
load
and
while.
E
That
there
is
no
changes,
so
we
can
use
the
latest,
but
then
again
the
problem
is
exactly
was
being
late.
What
if,
in
an
ideal
case,
we
should
be
able
to
it?
It
would
be
unfortunate
to
design
ourselves
into
a
situation
where
we
never
can
in
the
future,
build
a
feature
where
we
are
attached
to
running
an
application
running
application
right
now
it's
not
a
priority,
but
it
would
be.
E
But
if
we
are
too
late
because
something
is
already
loaded,
then
we
bail
out
like
if,
if,
if
you
have
loaded
something
that
is
at
least
this
version
would
have
at
least
this
this
this
one,
then
we
can
work
with
it.
But
if
you
have
something
that
is
super
old,
then
we
just
bail
out
right
and
then
the
question
is:
how
old
is
super
old
like
what
is
the.
A
Like
probably,
then,
we
need
to
to
carry
some
range
of
supported
versions
somewhere
to
make
this
kind
of
decision.
You
know.
E
Yes,
I
mean
we,
don't
we
don't
need
activity
listener
right.
What
was
the
the
diagnostic
source
listener,
whatever
it
was
called
before
is
essentially
the
same
thing.
The
only
the
only
new
thing
that
that
that
supports
is
like
the
sampling,
stuff
right.
E
Because
the
thing
is,
if,
if
the
tracer
is
already
attached,
we
need
all
activities
created
this.
This
mechanism,
where,
where
the
activity
listener
was
able
to
touch
the
activity
source,
don't
even
create
the
activity
right.
E
That
is
something
that
is
useful
for
the
sdk
scenario,
where
nothing
is
attached,
but
for
us,
if
the
tracer
is
attached,
then
we
want.
We
want
all
activities,
so
we
could.
We
could
do
something
like
when
we
attach,
if
it's,
if
something
is
loaded,
that
is
an
old
version
that
does
not
yet
have
the
new
activity
listener.
E
We
just
use
the
old
mechanism
and
we
always
use
old
mechanism
at
the
core.
But
if
the
new
mechanism
is
available
we
say
yes,
creative
activities,
something
like
that.
That
would
need
to
be
dynamic.
I
Yeah,
I
think,
there's
another
thing
that
needs
to
be
considered
in
this
as
well,
which
is
I
mean
for
the
most
part,
our
apm
vendors
try
to
not
have
external
dependencies
which
allows
them
to
do
the
by
code
instrumentation
inside
either
either
inside
say,
like
ms
square
level
or
framework
assemblies
or
just
to
safely
be
able
to
instrument
them
in
general,
but
now
we
actually
have
to
take
dependency
somehow
on
diagnostic
source.
I
This
is
something
we've
run
into
it:
the
data
dog
tracer,
and
so
we
need
to
figure
out
if
we
are
actually
going
to
statically
reference
and
compile
against
this
assembly,
such
that
it's
an
actual
assembly
reference
on
the
final
manage
assemblies
or
if
we
have
to
resort
to
just
loading
it
dynamically,
because
I
think
exactly
referencing
the
assembly
such
that
it's
no
longer
I
mean
we
can't
really
guarantee
that
it's
going
to
be
loaded
like
domain
neutral.
I
think
that
might
pose
some
problems.
I
If
we
reference
it
from
the
actual
assembly
and
compile
against
it,
then
I
think
that
could
cause
some
issues
which
type
of
issues
the
the
main
one
that
comes
to
mind
is
basically
instrumenting.
A
framework
assembly
like
system.data,
which
we
do
in
our
data.tracer.
That
needs
to
be
that's
loaded,
domain
neutral,
which
is
sort
of
standard
but
like
when
you're
running
an
is
and
what
not,
with
the
optimization,
all
those
that
are
in
the
gac
strong
strongly
named
are
loaded
domain
neutral.
I
But
if
we
refer
to
something
that's
going
to
be
pulled
in
via
nuget,
then
we
risk
the
possibility
of
the
profiler
like
managed
assembly.
That's
trying
to
start
these
activities
violate
that
contract
of
being
able
to
be
loaded
to
be
neutral.
H
The
diagnostic
source
assembly-
it
would
be
the
diagnostics
first.
I
Assembly,
if
it's
pulled
in,
say
the
application,
has
it
and
they're
in
the
application
folder.
And
we
load
that
one.
Yes,
because.
I
And
the
problem
is,
then:
if
we
take
a
stack
dependency
on
that,
then
we
end
up
well
depending
on
that,
and
we
need
that
to
actually
say
start
new
activities.
I
If
we're
trying
to
do
this
instrumentation
to
libraries
that
don't
already
have
activities
generating
activities.
So
that's
where
the
problem
lies.
E
So
essentially,
if
we
yeah,
because
so
let
me
let
me
repeat
this-
and
I
think,
let
me
repeat
this
as
a
change
so
in
on
on
full
framework
diagnostic
source
is
not
part
of
bcl.
E
E
So
that
means
we
cannot
call
it
from
a
domain
neutral
assembly,
but
we
have
to
because
we're
instrumenting
them
like
system.data,
so
we
can't
is
essentially
in
the
tracer
system.
There
is
two
places
we
have
a
reference
diagnostic
source.
One
is
when
we
collect
activities,
but
also
when
we
start
stop
activities
right
and
that
part
is
instrumentation
assembly
and
that
we
and
there
we
cannot
have
a
static
reference,
because
otherwise
we
break
the
domain
neutral
stuff.
E
So
that
forces
us
towards
the
the
dynamic
solution.
I
E
J
K
It's
I
mean,
that's
generally,
a
concern,
there's
other
there's
other
issues
with
instrumentation
and
I'm
trying
to
remember
if
you,
if
you
statically
reference
it
from
your
profile,
you
might
also
just
get
so
if
you,
if
you
have
a
different
version,
I
think
there's
scenarios
where
you
run
into
when
you
try
and
load
your
profiler,
that
it
will
just
fail
to
load
because
the
assembly
can't
be
resolved.
K
So
if
you
like,
if
you
have
a
if
your
pro
your
managed
profiler
dll,
has
a
a
reference
to
some
newer
version
of
diagnostic
source,
but
there's
already
a
previous
version
loaded
in
the
process,
I
think
there's
scenarios
where
it'll
just
give
up
and
say:
oh
the
you
know,
there's
an
assembly
load
failure.
You
can't
load
this.
E
Is
it
not
something
we?
It
sounds
similar
to
what
we
had
recently
with
the
the
other
dealer
that
you
investigated.
I
Right
zach,
we
had
something
similar
where,
basically,
if
our
so
the
the
one
assembly
that
came
to
mind
was
system.htp,
which
can
be
provided
in
the
framework
or
vnuga
package.
But
if
the
user
had
like
a
web
config
that
had
some
binding
redirects,
where
some
of
them
referenced
4.0
and
some
of
the
assemblies
and
the
application
reference
like
4.2.1
or
I
don't
sorry,
I'm
not
sure,
that's
the
version
or
4.1.1
that's
zero.
I
I
That
would
actually
fail
because
there
would
be
some
eager
loading
when
the
we're
trying
to
get
the
closure
for
the
profiler
manage
assembly,
and
so
there
was
some
awareness
there.
I
could
it's
hard
to
kind
of
describe
a
high
level,
but
I
have
some
investigation
notes.
If
that
would
help
to.
You
know,
explore
that
idea,
but
we
did
find
some
issues
with
that.
Just
referencing
the
same
assembly
that
could
be
brought
in
via
you
get.
K
To
me,
it
feels
like
it
wouldn't
be
that
much
work.
I
know
it's
complicated
a
little
bit
but
like
when
I
think
about
it.
Basically,
what
it
would
boil
down
to
is
writing
a
man
if
you
can
do
it
in
manish
code
is
writing
a
class
that
has
the
same
api
services
diagnostic
source
and
then
a
little
reflection
helper
to
just
to
query
it
and
then
probably
invoke
a
delegate.
So
you
don't,
you
know,
make
a
delegate,
so
you
don't
invoke
the
cost
of
reflection.
K
And
then
and
then
just
call
it,
and
I
I
mean
I'm
not
the
one
who
would
be
writing
it.
So
maybe
I'm
not
thinking
about
it.
You
know,
maybe
maybe
there
are
other
things
that
I'm
thinking
about,
but
generally
speaking,
I
don't
think
it'd
be
that
much
work
to
just
do
the
reflection
way.
It
doesn't
feel
that
complicated
to
me,
the
the
complication,
would
come
from
if
you
really
wanted
one
of
the
new
apis.
What
do
you
do
when
it's
not
there?
K
E
Goes
like
this,
I
have
the
shim
that,
like
along
the
lines
that
you
just
described
and
when
I
am
invoking
the
instrumentation
for
the
first
time,
I'm
loading
diagnostic
source,
I'm
doing
this
reflection,
and
then
I
know
that
so
I
wanna
I
wanna
load,
whichever
diagnostic
source
is
referenced
by
the
application.
E
So
if
application
already
loaded
this,
then
I
just
take
it.
If
it
hasn't,
I
wanna
load
whatever
it
will
load
in
the
future.
How
do
I
do
this.
K
That's
a
good
question.
So
typically
you
probably
so.
If
you
wanted
to
wait
until
they
uploaded
to
figure
out
what
load
they
would
do,
then
you
would.
You
would
wait
until
a
module
load
started
event,
and
then
you
could
use
the
reflection
apis
to
you
know
I
module
data
or
imetadata
whatever
it
is
import
and
you
you
can
walk
through
their
set
of
assembly
references
and
you
can
do
a
you
know.
A
closure
walk
on
that
and.
E
K
Yeah
right
and
so
do
you
guys
know
what
the
app
do,
what
the
app
exe
or
dll
is
on
disk
when
you're,
you
know,
when
you're
doing
your
instrumentation
before
it's
actually
loaded.
K
So
like,
if
you
get
so
when
you
do
your
instrumentation,
I'm
assuming
you
do
it
in
the
ms
corlab
module
load
started
callback.
Is
that
correct.
E
I
can't
remember:
do
you
remember
zack.
I
K
E
We
can
be
late,
I
mean
we
can.
We
can
avoid
doing
anything
there
and
we
can
do
it
later
when
the
actual,
when
the
actual
instrumentation
assembly
has
been
called
sorry,
instrumented
assembly
has
been
called,
and
at
that
time
we
have
certainly
loaded
the
main
entry
point.
K
Right
or
you
can
just
argue,
I
suppose
I
guess
the
other
option
would
be
to
to
do
module
and
started
callbacks,
but
then
you
would
have
to
there'd
be
some
you
know.
Would
the
module
would
happen
before
you
got
called
and
there
would
be
some
ambiguity
there,
but
but
yeah
either.
Your
your
options
are
either
to
walk
the
static
references
or
to
listen
for
a
module
that
started
callbacks
and
those
are
the
two
ways
that
you
know
what
they're
loading.
K
E
G
E
K
E
If
it,
and
because
I
will
specify
a
class
name
and
the
library
name
without
specifying
the
library
version,
it
should
just
work
right
if
it's
already
what
if
the
library
has
not
been
loaded-
and
I
don't
specify
the
library
version,
what
will
happen.
K
Then
you'll
get
whatever
the
api
is
called
to
where
you
say
you
know
like
new
assembly,
whatever
it
will
just
return
null
or
return.
You
know
no
types
found
basically
you'll
just
get
so
it.
K
Yeah
it
won't,
the
reflection
will
fail
because
there's
no
assembly
that
it
can
bind
to-
and
you
can
but
basically
will
happen,
is
you
just
won't
get
you'll
say,
give
me
the
type
of
diagnostic
source
and
it
will
say,
and
at
some
point
in
that
chain
it
will
say
that
assembly
isn't
there
so
return
null
for
whatever
that
call.
Is
I
don't
I
don't
remember,
I
could
look
it
up
and
tell
you
exactly
which
one.
E
So
I
guess,
but
we
can
check
whether
the
well
I
maybe
this
is
a
separate
conversation.
Maybe
in
the
very
first
prototype
we
can
say
so.
If
the
assembly
is
already
loaded,
then
I
don't
need
to
specify
the
version
it
will
just
right.
E
K
To
be
the
case,
so
if
I
mean
I
don't
have
any
data
to
back
this
up,
but
just
kind
of
my
gut
feeling
about
it
is
that
it
would
be
weird
for
a
regular,
asp.net
asp.net
app
to
do
anything
weird
where
they're,
like
loading
over
the
reflection
like.
Why?
Wouldn't
they
just
statically
reference
it
and
use
it.
E
A
A
C
E
A
So
so
this
is
something
that
we
have
to
be
kind
of
exploring
first
and
kind
of
doing
the
prototypes
and
the
stuff.
So
we
can
flush
out
any
issue,
because
the
risk
is
obvious.
We
we
go
in
that
direction
without
testing
a
lot
of
stuff
and
then
down
the
road
oops,
and
that
is
going
to
be
pretty
bad.
E
Yeah
all
right.
Well,
I
think
we
can
schedule
a
meeting
pool
also
knowing
that,
since
he
had
to
leave,
and
if
someone
from
the
azure
monitor
team
is
around,
then
them
as
well.
Who
from
the
people
who
are
online,
now,
would
like
to
be
in
that
extra
technical.
A
Discussion,
I
I
would
like
to
be
everything
that's
happening
this
week,
please,
let
me
know
yeah.
E
J
E
Diagnostic
source,
now
right,
you
use
some
own
implementation
of
spence.
Is
this
correct.
J
E
What
what
when
you
talked
about
it?
Why
did
you
decide
not
to
do
it?
Just
wasn't
the
thing
or
like
what?
What
were
your
kind
of
considerations
pro
and
con.
J
Well,
the
talking
that
we
were
doing
was
actually
more
recent
and
it's
just
not
something
we've
taken
on
and
also,
of
course,
with
open
telemetry,
we're
kind
of
weighing
whether
we'll
ever
do
it
in
our
agent.
So
why
was
that.
J
E
A
Yeah
all
right,
that's
it
for
today,
then
all.