►
From YouTube: 2020-09-09 .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).
B
B
Hey,
are
you
all
assembly
loading
experts
now.
A
Hey
yeah:
let's,
let's
start,
let's
get
started
yeah
I'm
actually
working
on
on
activities,
but
monday
was
also
not
much
time
has
passed.
I
have
no
real
status
update.
A
But
related
to
activities
other
than
the
realistic
expectation.
Now
I
wanted
to
actually
have
like
an
entry
and
working
thing
by
the
end
of
the
sprint,
but
given
where
we
are
now
and
all
the
versioning
challenges
that
I
think
we
should
address
first
before
we
even
you
know,
go
to
the
other
things.
A
B
I
I
was
the
christmas
last
week.
A
I
do
apologize
guys,
I
keep
being
haunted
with
by
being
really
bad
with
names,
and
I
just
remembered
you
guys
as
new
relic
fox
and
I
confused
you.
I
do
apologize
so
yeah,
then
you
have
the
context
and
chris,
hopefully
ellen,
was
able
to
tell
you
so
anyway.
My
my
goal
now
is
to
have
a
standalone
library
as
a
prototype
by
the
end
of
this
week.
A
Is
the
plan
for
for
by
the
end
of
this
week
it
is
a
it's
less
than
I
hope
to
achieve
when
the
sprint
started,
but
it
will
be
some
progress
other
than
that.
The
the
person
who
works
on
bytecode,
target
method
and
vacation
is
back
in
office,
but
we
haven't
synced
up
yet
after
the
vacation,
so
no
news
there.
A
So
maybe
I
put
this
in
here
other
than
that.
I
have
no
real
real
updates
today.
B
I
like
crisco,
since
he
was
out
last
week,
yeah
yeah.
I
don't
really
have
anything
for
the
agenda.
One
of
the
things
I
still
plan
on
doing
is
getting
a
clone
of
the
repo
and
just
building
and
getting
more
familiar
with.
What's
what's
in
there.
A
Yep,
that
makes
sense,
hopefully
just
I
did
the
rest
later.
I
wonder
so.
How
did
you
guys
send
your
relic?
How
did
you
go
about
dealing
with
activities?
Do
you
essentially
have
your
own
representation
of
spence
and
you
just
use
that
or
how
exactly
do
you
do
this.
B
B
Have
our
own
representation,
and
so
our
agent
itself
doesn't
deal
directly
with
diagnostic
source.
B
B
Yeah,
so
for
that
specific
thing,
it's
based
off
of
open
tracing,
and
so
it's
just
using
the
open
tracing
sdk
to
to
create
those
spans.
A
Open
trace
think
is
like
because
I
I
never
actually
worked
with
it
actively.
What
do
they
do
to
to?
They
have
just
their
own
type
of
code
span
and
that's
it
right.
B
A
And
how
do
you
glue
together,
if
you
have
a
stack
of
your
auto
instrumentation
spans
that
are
created
by
your
tracer
and
the
custom
spans
created
by
the
customer?
How
do
you
glue
this
together.
B
It's
just
a
open
tracing
extension,
and
so
we
have
a
piece
that
listens
to
diagnostic
source.
That
will
then
in
turn
generate
some
open
tracing
spans
on
behalf
of
the
the
user
of
the
api,
so
that
they
don't
have
to
to
call
an
api
themselves.
B
Yeah
yeah,
so
because
it's
based
on
open
tracing
and
open
tracing
has
its
own
concept
of
a
span.
That's.
A
B
A
You
don't
reference
the
open
tracing
sdk
from
the
from
your
instrumentation
libraries.
B
From
our
main
agent,
yes,
we
we
don't
directly
reference.
A
It
so
we
were
actually
exp
like
debating
an
approach
similar
to
this
because
like
in
right
now,
this
is
how
our
stuff
also
works.
A
But
the
challenge
is
this:
I
wonder
whether
you
solve
this
and
if
then,
how-
or
maybe
you
just
decided
not
to
deal
with
it
so
say
I
have
activities
right,
because
I
am
writing
custom
code
that
uses
activity
as
a
customer
and
in
terms
of
building
like
using
a
diagnostic
source.
You
can
convert
activity
to
whatever
you
use
internally.
A
So
after
you
send
the
data
and
people
look
at
it
in
your
ui.
Everything
is
fine
and
everything
stacks
correctly.
So,
basically,
if
you
used
first
a
your
own
internal
span,
then
you
used
activity
and
then
you
used
another
internal
spin
right.
That
would
be
logical.
You
have
a
route
which
is
your
route
spanning,
which
is
your
internal,
your
auto
instrumentation,
then
some
customer
created
some
logical
business
logic
level
span
using
activity
and
then
they
call
the
dependency.
So
that's
stacked
like
this.
A
B
Yeah
that
that
that's
what
I
would
expect,
if
it's
not
registered
with
the
activity
yeah,
so
the
the
product
that
chris
is
describing
is
specific
for
aws
lambda
and
it
uses
open
tracing
to
create
a
thing.
And
if
I
recall,
I
haven't
actually
looked
it
open
tracing
code
in
a
long
time,
open
tracing
yeah
totally
has
its
own
like
model
of
the
span
and
it
the
context
of
it
flows
via
async
local,
similar
to
activity,
depth
currents.
B
A
B
On
the
floor,
the
whole
notion
of
the
activity
we
only
just
scrape
it.
My
am
I
getting
that
right
chris,
I
may
be
forgetting
some
details:
yeah
no,
that's
accurate,
and
so
also
with
that
based
off
of
open
tracing.
B
A
A
A
Yeah
we
debated
a
similar
approach
and
then
it
felt
like
for
a
open,
telemetry
standard
trace.
It
may
be
too
restrictive.
Actually,
I'm
curious
now
that
cj
and
noah
and
william
are
here
how
they
feel
about
this.
Essentially,
here's
the
thing
imagine
we
would
say:
let's
not
deal
with
this
nasty
problem
of
versioning.
A
Let's
say
that
the
tracer
emits
so
we
create
a
class
called
span,
and
this
will
be
a
class
that
is
private
to
the
tracer.
Let's
call
it
spam
and
it
will.
We
won't
even
have
it
as
a
public
api
so
well,
it
must
be
a
public
api,
because
people
who
create
instrumentations
will
use
this
this
class,
but
customers
should
not
like
custom
code,
should
never
deal
with
this
so
and
then,
when
a
tracer
emits
bytecode,
then
that
bytecode
creates
that
private
span
class,
or
instance
of
this
private
spam
class.
A
That
means
no
problem
with
with
versioning.
Now
the
collector
also
collects
those
private
spans,
also
no
problem
there.
Now
we
create
a
separate
module
that
is
a
diagnostic
source,
listener
or
activity
listener,
or
using
reflection
that
loads
the
right
the
right
api
at
the
right
place.
This
is
sort
of
separate
from
all
that
system,
which
means
it
puts
all
the
complexity
just
in
a
well
a
kind
of
constraint
area
and
that
diagnostic
source,
listener
or
activity
listener
listens
to
activities
and
just
converts
activities
to
those
private
spends.
A
So
whenever
we
start
an
activity,
we
start
a
private
span
whenever
we
finish
activity,
we
finish
the
private
span
that
solves
most
of
our
problems,
because
the
hierarchy
of
private
spends
works
just
fine
in
that
space.
The
only
problem
that
is
broken
is
now.
If
a
now
the
expectation
of
the
user
is,
if
you
actually
are
want
to
create
custom
custom
spans,
you
just
do
activities,
so
you
never
reference
our
private
library
directly
and
you.
A
You
never
create
a
versioning
problem
that
library
ships
only
with
the
tracer,
so
this
converter
or
that
listens
to
activities
and
creates
spans.
So
the
activity
to
spam
thing
works
just
fine,
but
now
a
customer
who
created
a
new
activity,
it
was
using
whichever
method.
A
During
the
execution
of
a
request,
logically,
this
activity
is
a
child
of
a
root
activity,
but
there
is
no
root
activity.
Logically,
it's
a
child
of
a
root
span,
but
there,
if
you
do
activity.
parent
it
points
to
nothing
because
it
was
like
the
whole
root
stuff
was
not
set
up
right.
A
D
I
mean,
I
guess,
there's
a
few
more
elements
that
we
just
have
to
define
how
they're
working
I
mean,
it's
not
to
say,
there's
no
solution
there.
It's
just
it's
missing
pieces.
It
sounds
like
so
far
I
mean
one
would
be
figuring
out
when,
when
a
new
request
comes
in
from
the
wire
or
when
a
request
is
outgoing,
on
the
wire
sort
of,
how
do
we
do
the
you
know?
D
How
is
the
sampling
logic
going
to
work
for
the
activity?
Assuming
I
mean
so
one
option
is
to
say:
you're
not
going
to
do
any
sampling
you're
just
always
going
to
create.
You
know,
anytime.
Anyone
has
any
activity,
instrumentation
instrumentation
in
their
code,
you're
just
always
going
to
create
it
you're
not
going
to
worry
about
whatever
context
it's
in.
D
A
So
so
to
answer
this
so
because
this
whole
thing
could
only
kick
in
when
the
tracer
is
actually
attached.
A
That
means
that
we
do
need
the
the
activity,
at
least
for
context
propagation,
so
the
option
of
not
creating
it
at
all
is
already
off
the
table.
A
Of
performance,
so
that
means
we
do
have
to
create
an
activity,
and
the
question
is
only:
are
we
going
to
serialize
it
when
it's
finished,
but
by
then
we
know
that
we
never
serialize
activity.
We
serialize
the
private
spans
right.
We
converted
it
to
spence.
We
know
that
we
would
always
convert
it
to
spence
and
then
whether
or
not
we
choose
to
serialize
them,
that
will
that's
where
sampling
starts,
to
play
their
own
role.
A
I'm
not
sure
whether
I'm
missing
some
performance
improvement
opportunity
here
other
than
we
essentially
four
activities
per
creature,
object
activity
and
the
span.
D
So
it's
just
sort
of
it's
a
your
choice
of
intermediate
representation
of
you
could
serialize
that
activity
out
directly
or
you
could
convert
it
into
a
span
and
then
you
could
serialize
the
span
out
and
chances
are
not
doing.
The
conversion
might
save
you
a
little
bit
of
performance,
but
it
might
also
make
your
serializer
more
complicated
and.
A
Yeah
but
but
like
the
way,
I
imagine
this
so
the
the
the
collector-
wouldn't
I
don't
want
them
with
the
whole
point
of
that
particular
approach-
would
be
for
the
collector
not
even
take
any
reference
to
diagnostic
source
at
all,
so
the
converter
would
be
essentially
like
a
separate
module,
a
separate
dll
that
you
only
ever
need
to
load
if
you
interact
with
activities,
so
the
collector,
essentially,
the
tracer
could
work
completely
without
ever
realizing
the
diagnostic
source
exists.
A
If
it
can,
if
it
ignores
activities,
and
then
there
is
a
separate
dll,
that
only
does
the
conversion
and
the
whole
the
whole
risk
of
doing
reflection
is
contained.
Only
there.
B
A
So
that
would
be
the
the
the
sort
of
the
benefit
of
doing
this.
A
So
the
idea
problem
is
also
fine,
because
in
in
the
world
of
in
the
sdk
world,
activity
does
its
own
thing,
but
in
in
a
tracer
world,
because
different
vendors
doing
are
doing
different
approaches
for
serializing
con
context
into
headers.
A
It
needs
to
be
anyway,
a
plug-in
where
every
time
a
dependency
is
called
says
here
is
the
current
span
or
activity
here
is
the
request.
Object,
put
the
headers
in
it
because
somebody
might
choose
to
do
w3c
headers
somebody
might
choose
to
do
some
proprietary
headers
and
it
needs
to
be
plugged
in
so
whatever
local
representation
of
spam
vs
activity
we
use.
We
still
need
that
plugin.
A
I
think
I
think
I
think
long
term.
It
would
be
good,
but
if
you
take
realistic
steps
towards
the
success
of
the
project,
we
shouldn't
make
success
here,
dependent
on
all
the
companies,
because
it
means
that
all
the
vendors
would
need
to
convert
all
the
supported
languages
to
w3c
and
in
the
long
term
it
would
be
good.
But
it's
not
realistic
to
happen
simultaneously
because
say
you
have
a
data
customer
who
uses.
A
A
B
But
I
guess
taking
a
step
back,
I
don't
know
if
this
is
going
to
be
tangential
or
not,
but
is
there
any?
A
B
A
So
I
think,
like
we
discussed
it
in
one
of
the
meetings,
I
am
very
very
keen
on
not
taking
a
dependency
on
on
an
open,
telemetry
sdk
because
of
the
whole
versioning
nightmare.
What
we
can,
however,
do
is
we
can
import
code.
We
can
share
code
between
open
limit,
sdk
and
the
tracer
so
that
we
reuse
the
code
and
we
have
the
same
kind
of
standard
and
and
api
shape.
B
B
Because
one
of
the
initial
thoughts
that
I
had
with
this
is
that
the
auto
instrumentation
that
we
have
would
be
ultimately
generating
activities
and
the
shared
sdk
code
that
we
have
will
be
able
to
listen
for
those
activities.
And
then
any
vendors
can
just
plug
in
via
those
extensibility
points
provided
by
that
shared
sdk
code.
A
Yes,
that's
that's.
That's.
The
whole
discussion
last
week
was
about
achieving
exactly
that.
I
was
just
thinking
whether
you
know
as
I
was
starting
to
implement
this.
I
was
kind
of
thinking
about
other
alternatives
that
might
simplify
the
whole
reflection
business
and
that's
one
thing
that
came
to
mind:
that's
I'm
just
kind
of
brainstorming
and
getting
shoes.
D
So
when
you're
talking
about
a
converter
from
activity
to
spam,
I
mean
that
it.
I
guess
it's
not.
I
mean
I
have
no
opposition
to
it.
So
don't
take
it
that
way,
I'm
just
not
clear
what
the
what
the
win
is
versus
over
like
basically
isn't
that
still
just
a
reflection
wrapper,
it
just
happens
to
be
a
reflection,
wrapper
that
you
just
use
once
in
the
process
of
conversion.
A
Correct
and
and
it's
it's
that
plus
you
can
start
playing
tricks
to
load
it
late,
and
so
there
is
two
problems
that
we
discussed
right.
One
is
reflection
wrapper,
but
that's
just
mechanics
of
building
it
right.
B
A
There
is
a
problem
of
what,
if
the
application
depends
on
some
other
version,
blah
blah
blah
by
loading
this
guy
late.
We
can
be
sure
that
that
some
version
of
the
diagnostic
source
is
already
loaded,
and
if
it's
not
loaded,
then
we
never
need
to
actually
load
that
right.
So
basically,
I.
B
A
So
so
the
big
problem
that
I
see
with
this
is
so
the
api
around
creating
activities
and
setting
things
on
activities.
A
A
What
I
cannot
imagine
in
a
with
a
reasonable
effort.
Anything
is
just
bits
right,
but
with
a
reasonable
effort
is
reading
things.
So
if
we
created,
if
we
did
it
that
way,
and
somebody
queries
activity,
the
current
pro
dot
parent
property,
then
they
will
not
get
a
good
answer,
because
the
parent
may
be
something
that
was
a
span
that
I
described
and
in
this
system
that
I
suggested
we
create
a
span
for
every
activity,
but
we
don't
create
an
activity
for
every
span.
A
Sure
right,
so
that
means
parent
property
gets
broken
and
activity.current
also
gets
broken.
Because
if
I,
if,
if
suddenly,
I
created
a
custom
activity
because
custom
code,
but
then
I
called
a
dependency.
So
now,
I'm
inside
of
some
code,
where
the
tracer
actually
emitted
a
spam.
A
A
Create
okay.
Okay,
so
imagine
imagine
this
this
this
scenario
so
first
you
enter
the
request
and
the
tracer
creates
the
root
span.
A
A
D
Mean
okay,
so
here
I
was
gonna.
Do
let's
see?
Oh,
I
was
just
gonna
see
if
I
could,
if
I
could
make
a
little
ms
paint
illustration
I
mean
I'm
pretty
sure
I
follow
what
greg
is
proposing.
A
And
I
feel
that
what
I
described
is
a
deal
breaker,
so
I,
but
I
just
want
to
like
I.
I
would
like
to
know
how
you
guys
feel
so.
A
D
And,
and
and
I'm
assuming
I'm
assuming
you
know,
spam
has
still
some
notion
of
actually
what
I
what
I
should
do,
no.
D
It's
just
the
fact
that
it
is
now
possible
for
the
tracer
to
sort
of
create
new
spans
for
things
that
it
instruments
that
there's
no
corresponding
instrumentation
in
the
user's
code.
For
because
I
don't
know
this
is
redis
or
whatever
is
your
canonical
thing
that
a
new
span
appears
and,
and
then
I
and
then
greg.
I
think
the
issue
you're
pointing
out
is
that
it's
sort
of
to
say
now,
there's
there's
two
different
notions
of
current
there's.
D
You
know
from
from
the
user's
code
perspective,
you
evaluate
activity.current,
and
it
says
this
guy
number,
two,
that's
the
current
activity,
but
if
you
go
ask
the
tracer
on
its
little
chain
of
spans
what's
current
and
it
says
no,
no
number
three,
this
span,
that's!
What's
current
right
now,
and
presumably
these
have
different.
You
know,
even
if
they
agree
on
a
trace
id,
they
don't
agree
on
a
spam
id
because
they
need
to
be
distinguished
from
each
other.
Yes
and
then
I
think
you
were
sort
of
further
saying,
maybe
what
is
that,
like?
D
You
would
see
like
incongruent
incongruency
or
something
like
if
the
app
maybe
logged
a
message
on
its
own?
Like
a
you
know,
a
text,
log
message
into
its
log
and
it
logged
like
I'm
doing
this
unit
of
work
and
the
current
span
or
the
current
activity
id
is
blah
blah
blah
and
then
your
tracer
is
also
sitting
here
emitting
these
things
and
you
emit
something
for
that
same
area
of
work.
D
But
you
give
it
now
a
different
id,
because
you
created
this
new
span
here
at
the
bottom
and
then,
if
those
both,
if
both
those
streams
of
telemetry
feedback
to
the
user,
they
might
be
confused
to
say,
oh
well,
that's
weird,
like
redis,
can't
seem
to
agree
on
what
the
current
span
id
is.
A
data
dog
tells
me
the
spam
id
is
x,
but
this
text
block
that
I
have
tells
me
it's.
Why,
and
I
don't,
and
I
don't
understand
why
these
are
different.
D
A
I
think
so
far
you
exactly
described
the
problem
only
much
better
than
I
did.
Thank
you
for
that.
The
the
the
last
part,
I
think
kind
of
has
a
bit
of
an
answer.
If
we
really
wanted
to
project
back,
like
you
described,
then
the
comp,
the
versioning
complexities
that
comes
with
it,
would
indicate,
in
my
opinion,
that
this
whole
approach
is
pointless
and
we
should
just
stick
to
what
we
discussed
last
week,
where
we
just
solved
the
versioning
problem
of
diagnostic
source
and
use
it
directly.
A
D
And
so
I
assume
that
really
just
comes
down
to
figuring
out.
How
likely
is
it?
The
user
is
going
to
log
activity
ids
via
some
other
telemetry
stream,
that's
outside
the
tracer's
scope
of
influence,
and
then
how
likely
is
the
user
going
to
take
that
telemetry
there
and
compare
it
back
up
to
what
the
tracer
gave
them
at
some
later
point
such
that
they
can
actually
notice
the
discrepancy
between
the
two.
A
So
I
I
have
encountered
a
bunch
of
scenarios
where
this
would
have
been
a
problem,
but
those
scenarios
where
I'm
not
sure
how
representative
they
are
because
they
were
related
to
actually
doing
deeper
monitoring.
So,
for
example,
microsoft's
synthetic
testing
product
right
tries
to
glue
together
activities
that
happened
during
this
synthetic
test.
So
synthetic
test
is
a
bunch
of
code
that
the
user
can
take,
write
some
code.
B
A
This
is
my
coded
test
and
I'd
like
to
execute
it
on
a
regular
basis
and
the
outcomes
of
these
tests
are
fed
into
the
right
system
so
that
I
can
from
different
locations
so
that
I
can
essentially
see
a
synthetic
test
that
calls
my
application
from
from
outside.
That's
a
microsoft
product
that
right
so-
and
I
bet
that
all
the
other
vendors
have
something
similar.
A
A
Inside
of
the
test
are
also
available
as
logs,
so
that
people
can
debug
the
tests,
and
so
there
were
special
spans
that
represented
the
test
itself.
So
we
needed
essentially
to
write
code
inside
of
the
azure
azure,
like
inside
inside
of
the
thing
that
hosted
these.
These
synthetic
tests
to
explicitly
interact
with
activities
and.
A
Because
application
inside
since
decay,
which
was
used
at
the
time
for
it,
creates
activities
explicitly,
it
was
just
fine.
We
could
do
this,
we
could
just
like
create
a
new
activity
and
it
would
fit
into
the
chain
nicely.
A
But
if
that
approach
would
have
existed,
then
it
wouldn't
have
worked.
However,
this
may
be
a
such
big
age
case
that
we
don't
care.
So
the
question
is:
do
we.
B
B
A
A
Anyway,
so
in
summary,
I'll
continue
working
on
the
reflection
wrapper
anyway,
because
we
need
this
either
way.
But
how
do
you
feel
about
this
one-way
thing?
Is
this
a
deal
breaker
or
not?
What
what's
your
opinions
or
do?
We
need
to
make
it
both
ways
in
some
way
and
then
reflection
of
this.
B
Like
good,
no
strong
opinion
just
because
I'm
not
I'm
I'm
trying
to
grasp
for
use
cases
where
you
know
it
becomes
a
deal.
Breaker
and
that's
I
mean
you've
kind
of
articulated
one
great.
But
I
guess
it's
a
matter
of
how
you
think
there's
going
to
be
multiple
telemetry
products.
D
I
mean
what
one
thing
I
mean
one
thing
I'll
throw
out
there
I'd
say:
we've
been
seeing
increased
requests
on
the.net
team
for
better
support
in
the
logging
api,
like
ilogger,
specifically
for
those
logs
to
contain
ids
from
the
activities.
Yes,
yes,.
D
So
it's
certainly
I'd
say
it's
certainly
going
to
be
increasingly
likely
over
time
that
if
people
are
creating
any
form
of
textual
log
output
from
their
app
and
they
are
including
the
ids
into
those
textual
logs-
that
the
ids
that
get
recorded
there
are
only
going
to
be
the
ids
that
are
visible
via
the
activity
chain.
And
not
you
know
if
you
have
any
sort
of
behind
the
scenes
business
that
will
not
be,
that
will
not
be
visible
in
those
logs.
A
A
So
maybe
then
you
actually
know
the
answer
to
this.
Are
there
any
plans,
any
concrete
plans
to
do
what
you
say
so
that
the
output
of
I
logger
contains
information
about
the
current
activity?
Are
there
concrete
plans
to
do
this,
or
is
this
more
like?
We
should
do
it
someday
it.
A
A
Data
point
that
I
think
decides
this
conversation.
Thank
you.
I
think
also
what
it
means
for
all
of
the
vendors
on
this
call.
So
today
I
don't
know
how
you
guys
do
it
in
your
elect.
A
Today
you
have
to
do
something
when
you
do
a
tracer,
you
have
to
do
something
so
that
the
logs
are
correlated
with
traces
right
and
I'm
I'm
guessing
that
you
do
some
kind
of
bytecode
instrumentation
to
include
information
about
the
current
current
trace
id
and
current
spend
id
into
the
things
that
customers
application
logs
into
custom
logs
right.
A
So
that
means,
if
we
use
an
internal
representation
for
spends
sorry
for
activities.
A
We
have
to
do
this
for
ilogger
and
if
we
don't,
then
we
don't
and
then
any
logging
library
that
chooses
to
support
this
will
be
supported
for
free,
essentially,
nora
is.
Could
you
please
share
some
sort
of
link
about
documentation,
information
about
this
feature.
A
Cool,
I
think
that
that
that
addresses,
like
you
think
so,
thank
you,
the
them
it.
It
also
is
a
a
good
data
point
for
the
priority
of
having
this
whole
activity
support,
because
then
we
get
this
for
free
right.
D
Yeah
I
mean
well:
whatever
activity
is
currently
the
current
is
the
current
one.
It
will
that
id
should
get
locked.
The
the
thing
that
we're
building
and
done
at
5
is
opt-in.
D
It
adds
a
new
property,
as
I
recall,
on
the
it's
either
on
like
the
logger
factory
or
maybe
on
the
or
like
the
logging
builder.
You
know
the
logging
options
that
ultimately
goes
to
the
logging
factory,
but
basically,
at
the
end
of
all
the
configuration
you
get
a
true
false
property
on
the
factory
that
says,
do
you
want
to
include
this
activity
information
in
your
logs
and
if
the
customer
sets
that
to
be
true,
then
then
we
automatically
create.
D
A
Yeah,
but
so
that
means
we
can
tell
our
customers
once
once
activity
supports
for
the
tracer
is
shipped
like
once
once
that
is
done.
We
can
tell
our
customers
if
you
use
a
version
of
the
tracer
that
supports
it.
You
automatically
get
get
support
for.
I
logger
based
logging,
essentially.