►
Description
Learn how features of the new .NET project system not only dramatically reduce the size of your proj and nuspec files, but it makes them simpler and easier to maintain.
A
A
A
A
A
B
A
A
Hearing
us
right
now,
you
guys
need
to
check
out
Jeff's
show
he
broadcasts
us
through
the
visual
Souter
channel
as
well.
Dad
jokes,
oh,
we
can
do
some
dad
jokes
too.
That's
awesome!
You
know
the
best
part
about
UDP
jokes
is
I,
don't
care
if
you
get
them
or
not,
do
boom
come
on
at
least
there's
one
of
you
geeks
out
there
that
found
that
amusing.
A
C
C
C
C
You
can
see
it's
quite
an
active
project,
there's
stuff
happening
there
all
the
time
the
new
product
system
was
created
really
because
the
old
project
system,
which
was
written
first
sort
of
C,
sharp
and
Visual
Basic
projects,
was
really
tied
to
Visual
Studio.
So
what
only
going
to
work
on
Windows
so
for
cross-platform
support,
they
needed
to
come
up
with
something
new,
and
it's
also
given
an
opportunity
to
sort
of
rethink
how
it's
all
implemented,
make
some
performance
improvements.
So
do
you
have
a
look
at
the
github
site?
C
There's
some
good
documentation
on
here
and
what
really
makes
up
the
project
system
and
also
things
like
a
feature
comparison.
What
what
things
are
in
the
new
product
system
that
aren't
in
the
old
one
and
vice-versa,
what
hasn't
been
brought
into
the
new
one?
Yet,
and
and
also
here,
just
get
an
idea
of
what
releases
are
going
to
have
those
features
as
well.
It
is
open
source,
so
you
can
even
jump
in
and
add
some
requests
for
features
and
maybe
even
commit
a
pull
request
as
well.
C
So
the
new
product
system-
let's
have
a
look
and
see
how
we
can
actually
migrate
an
existing
project
to
use
that
I'm
going
to
jump
over
to
visual
studio.
So
I've
got
a
solution
opened
here.
It's
actually
the
source
code
for
chocolate,
EES,
choco,
XE
command
line
tool,
so
chocolaty
is
a
platform
for
installing
software
on
a
Windows
PC.
C
It's
a
bit
like
apt-get
for
Linux,
but
on
the
Windows
platform,
and
so
I've
downloaded
the
source
code
for
their
command
line
tool
and
I'm
going
to
demonstrate
upgrading
the
chocolaty
class
library
to
using
the
new
project
system
format.
The
first
thing
we
can
do
and
I'll
just
switch
over
to
vs
code.
Just
to
show
you
what
that
looks
like,
but
so
many
windows
here.
C
So
here's
the
project
file
for
chocolate
at
the
moment,
if
you've
ever
looked
at
a
CS
progr,
a
VB,
proj
it'll,
look
pretty
familiar,
we've
got
things
like
assembly.
References
we've
got,
every
source
file
is
listed
there
individually.
That's
part
of
this
particular
library.
We've
got
other
things
like
embedded
resources
and
project
references
and
a
few
other
bits
and
pieces
as
well,
so
that
whole
file
there
is
around
about
371
lines.
Long,
okay,
we've
only
out
the
way.
C
So
the
first
thing
we
can
do
is
just
a
small
thing:
we've
got
new,
get
packaged
references
here,
and
so
one
thing
we
can
do
is
actually
migrate.
Those
to
use
the
new
packaged
reference
format
and
one
way
we
can
do
that
is
to
use
a
little
wizard
that
should
normally
pop
up
here
in
this
menu
and
I
right-click
on
the
references
node.
If
it
doesn't
then
just
open
up
your
package
manager
console
window
and
by
allowing
that
to
happen,
then
that
menu
item
will
appear.
C
So
just
if
you
don't
see
it,
you
just
need
to
do
that.
Step
first
is
to
initialize
it.
We
then
see
all
the
current
list
of
packages
that
we're
using
in
this
project,
we'll
also
see
a
couple
here
that
have
been
put
under
the
transitive
dependencies
section,
and
what
that
means
is
that
these
two
packages
we're
currently
referencing
those,
but
we
don't
need
to
going
forwards
because
there
are
actually
dependencies
of
our
X
link,
and
so
we
don't
need
to
directly
depend
on
these.
C
And
we'll
see
down
the
bottom
of
the
file
here.
We
now
have
a
new
item
group
there
with
package
reference,
so
I
still
haven't
converted
the
rest
of
the
project,
but
we
can
already
start
using
package
reference
here
rather
than
packages
up
config
and
so
we're
already
making
use
of
the
transient
dependency.
So
we
only
need
to
reference
rx
link
in
this
case
and
we're
getting
those
other
few
packages
in
so
our
line
count
is
down
a
little
bit
I'm
just
going
to
copy
that.
C
You
know
my
clipboard
because
we're
going
to
use
that
in
a
second
and
back
to
the
project
now,
so
we've
done
that,
let's
keep
going
and
I'm
just
going
to
jump
over.
The
next
thing
we
do
is
actually
convert
the
project
itself
to
the
new
format
and
one
easy
way
of
doing
that
is
to
use
a
command
line
tool
so
and
we
can
use
dotnet
the
command
line
tool
to
create
a
new
project
file.
C
So
when
a
new
class
Lib
and
the
name
is
going
to
be
chocolaty
I
hit
enter
on
that
it's
actually
going
to
complain.
So
here
on
that
file
already
exists.
Are
you
sure
and
I'll
say
yes?
I
am
so
run
that
and
that's
created
a
new
project
file
I
switch
back
to
vs
code
and
we'll
see
that
now
our
project
file
is
really
small.
That's
fantastic,
possibly
even
a
little
bit
too
small
by
default.
C
It
sets
the
target
framework
as
a
net
standard
to
zero,
but
our
project
was
actually
targeting
dotnet
4.0,
so
I'll
change
the
target
back
because
we're
not
ready
to
migrate
our
code
base
to
don't
need
standard.
Yet
I
can
paste
back
in
my
package
references
because
they're
going
to
work
as
well.
Now
I
switch
back
to
visual
studio
and
you
don't
notice
yet
that
projects
change
I
need
to
reload
it,
and
here
we
go
and
it
looks
pretty
much
the
same.
C
So
we've
still
got
all
s
lost
code
files
there
and
now
I
can
right-click
on
my
project
and
I
can
edit
the
project
without
having
to
analyze
it.
So
that
is
a
great
feature
of
the
new
product
system.
We
don't
have
to
unload
edit
reload
and
wait
forever.
We
can
edit
the
project
file
live,
that's
fantastic!
We've
got
our
project
references
there.
So
if
I
expand
this
new
dependencies
note
here,
I
can
see
mine,
you
get
packages
they're
all
nicely
and
we
can
even
see
those
transitive
dependencies.
C
There's
those
other
two
packages
underneath
rx
link,
that's
looking
good!
So
what
else
do
we
need
to
do
so?
Normally
you'd
probably
use
your
version
control
and
do
a
diff
between
the
old
project,
the
new
project,
to
figure
out
what
things
you
do
need
to
bring
back
in
here.
So
I've
got
my
package.
References
done.
I
also
have
some
regular
assembly
references.
C
Some
of
these
are
to
framework
assemblies,
and
some
of
those
are
to
other
libraries
that
are
in
my
source
code
repository,
so
I'll
bring
those
in
and
just
hit
save
and
then
the
other
thing
I
need
is
at
the
moment,
you'll
notice.
We've
got
all
the
files
are
included
in
the
project.
We
don't
need
to
list
them
anymore,
because
by
default
the
new
project
system
includes
every
file,
that's
under
the
directory
of
that
project
file.
But
in
this
case
the
old
project
was
also
linking
to
a
file
outside
of
that
directory
hierarchy.
C
C
So
it
may
be
that
before
you
do
this
kind
of
migration,
you
clean
up
all
those
files
first,
just
to
avoid
any
problems
with
them
sort
of
reappearing
in
the
project.
Okay,
so
we've
got
our
solution
file
there,
the
and
so
one
more
thing
we
need
to
do
a
couple
more
things
is:
we
need
to
add
a
project
reference
back
that
was
in
the
old
project,
so
who's
going
here
and
use
the
GUI
for
that
one
and
we'll
see
that
just
added
a
project
reference
element
there.
The
other
thing
we
had.
C
It's
added
this
line
here,
which
is
we're
going
to
remove
that
file
from
the
none
group
and
then
down
the
bottom.
It's
going
to
add
that
file
into
the
embedded
resource
group,
like
that
I've
got
a
few
other
files.
I
need
to
do
the
same
for
that,
so
I'll
just
find
those
and
they're
under
here.
So
again,
I
could
just
use
a
diff
and
you
sort
of
copy
those
over
from
the
old
version
if
I
knew,
which
ones
needs
to
go
over
there
change
them
to
a
better
resource.
Okay,
that
should
be
pretty
much
it.
C
C
Has
it
that's
a
nice
feature
so
unless
just
find
where
those
attributes
are
declared
at
the
moment,
so
normally
you
would
often
declare
those
attributes
in
your
assembly
info
file
if
I
open
that
actually
there's
no
attributes
declared
there,
but
there
was
that
linked
file
that
I
added
in.
Let's
have
a
look
at
that
one
and
sure
enough.
Yes,
that's
where
they're
being
declared,
but
they're
only
declared
once
so
where's
this
duplicate
coming
from
well,
the
new
product
system
actually
generates
these
for
you.
You
don't
need
to
define
them
yourself
if
you
don't
want
to.
C
C
B
B
C
C
So
we're
now
down
to
about
75
lines
from
about
360
I
think
it
was
before
so.
Our
project
file
is
a
lot
more
compact
and
the
nice
thing
is
because
we're
not
including
every
source
file
in
this
project.
It
means
that
if
you're,
adding
new
files
or
removing
them
you're
not
going
to
be
modifying
this
file,
such
as
one
less
thing
to
worry
about,
merge
conflicts,
okay!
Well,
we
here
we
we
added
package
references
in
there,
there's
some
other
nice
things
we
can
do
with
package
references.
C
One
of
the
things
is,
we
can
use
for
loading
version
numbers,
so
you
might
think
well
actually
I'm
happy
to
take
whatever
is
the
latest
version
of
rx
link
2.1
dot,
the
highest
number
that's
out
now
or
you
might
be
really
brave
and
go
yep.
Whatever
version
two
is
I
want
I
want
that
one
and
I
want
the
latest
one
of
that,
and
actually,
if
we
hit
save
on
that,
will
notice
that
the
build
system
goes
away,
thinks
would
be
a
man
realized.
Actually
the
latest
one
is
2.2
dot
five.
C
So
it's
able
to
to
load
that
in
pretty
quickly,
but
that's
even
quicker,
because
I've
already
done
this
before
so
things.
Occasionally
my
computer
we're
looking
at
this
and
we're
thinking,
that's
good
and
it's
nice.
How
we've
got
our
version
numbers
here,
but
if
I've
got
a
solution
with
a
lot
of
projects
and
I
want
to
upgrade
a
package,
that's
still
going
to
impact
a
whole
lot
of
projects
with
changing
all
the
version
numbers.
So
wouldn't
it
be
nice
if
I
could
centralize
how
I'm
versioning
all
my
packages?
C
B
C
Which
is
a
little
bit
more
succeed
so
now
we
can
see
that,
in
fact
the
version
numbers
are
still
getting
picked
up
in
division,
VideoStudio,
yeah
it
it's
loading
that
directory
dot,
build
targets,
file
and
including
that
with
each
project
file
under
the
solution.
So
you
can
also
have
a
directory
of
build
props
file
which
is
sort
of
prepended
to
each
project
and
the
targets
file
is
sort
of
appended
to
each
project
and
the
syntax.
The
LG
I'll
switch
back
to
that
file.
C
Really
is
that,
rather
than
include,
we've
got
an
update,
so
this
is
going
to
find
any
items
in
the
package.
Reference
item
group
with
this
name
and
it's
going
to
set
the
version
metadata
to
2.1
dot
3,
and
so
that's
how
we're
able
to
still
have
these
version
numbers
here
so
now,
with
that
one
file,
I
can
centralize
all
the
version
numbers
for
my
packages.
C
One
thing
to
be
aware
of
with
that,
though,
is
it's
very
convenient
for
managing
versions.
The
the
tooling
individual
studio
I
can
still
go
in
and
say
manage
you
get
packages
to
to
see
if
there's
updates,
but
if
I
try
and
apply
those
updates,
it
doesn't
know
how
to
update
directory
type
build-up
targets,
so
you
you'll
still
want
to
go
in
and
manually
update
those
that
file.
If
you
want
to
do
a
package
update.
C
Another
thing
without
our
project
file,
while
we're
up
here,
is
the
sdk
attribute.
This
is
a
new
addition
to
the
project
file,
format
and
you'll
notice
that
we
have
Microsoft
net
is
DK
there.
So
that's
the
sort
of
default
value
that
was
created
for
us.
If
you
create
a
unit
test
project,
you'll
have
a
slightly
different
name
there.
C
But
the
interesting
thing
is
that
this
name,
we
can
put
other
values
in
there
and
so
for
one
example
of
that
I'll
switch
over
to
my
browser
and
so
an
another
developer,
quite
well
known
in
the
dotnet
community.
Oren
Novotny
has
created
a
package
called
msbuild
sdk
extras,
and
so
this
is
a
new
get
package,
and
if
you
use
that
name
with
that
sdk
attribute,
then
you
it
will
download
this
package
and
or
add
some
extra
functionality
that
Ahrens
implemented.
So
in
this
case,
this
package
does
generate
reference
assemblies.
C
C
Looking
at
generating
files
as
part
of
the
build
process
and
how
they're
included
so
this
is
something
I've
seen
in
a
couple
of
different
places
where
you
have
a
project
or
a
solution
where
the
app
config
file
is
not
committed
to
version
control,
and
so
essentially,
because
every
developer
has
their
own
connection
string
and
their
own
preference
for
logging,
and
so
to
avoid
everybody
fighting
over
and
over
ID.
Everyone
else
is
config.
We
don't
commit
the
app
config,
then
I
won't
keep
doing
that.
C
We
commit
another
file
and
in
the
project
file
we
have
a
build
step
that
just
checks.
If
there's
no
app
config,
then
I'm
going
to
copy
the
app
default
config
to
app
config,
if
there
is
one
I
was
leave
it
alone,
so
that
allows
the
developers
to
have
their
own
customized
settings
in
this
file
and
sort
of
work
and
everyone's
happy.
One
thing
I
did
notice,
though,
is
if
I
open
this
folder
here
and
we
look
in
the
the
build
output.
C
Folder
is
there's
an
X
E
and
a
PDB,
but
there's
no
XE
config
file
there.
Now,
if
I
built
this
project
again,
then
it
would
create
one,
but
that
first
time
it
didn't
so,
if
I
delete
that
out
config
and
do
a
build,
we'll
see
that
yep
there's
still
no
config
file
there.
So
how
can
we
make
sure
that
that
first
time
around
that
the
the
config
'it's
copied
out
correctly?
So
what
I
discovered
was?
It
presumably
is
just
a
slight
change
in
the
sequence
in
which
things
happen
in
the
new
produce
system.
C
I
just
need
to
include
this
line
here
to
say
that
when
we
do
to
a
copy,
we
just
update
the
nun
group
with
that
file,
and
then
the
build
system
is
able
to
pick
that
up
later
on
and
generate
that
so
file
again,
we'll
build
our
project
again
and
we've
got
our
config
file
back.
So
that's
good,
so
that's
just
one
little
thing
that
I
needed
to
do
just
to
to
make
things
work
properly.
C
Particularly
you
might
want
to
use
this
because
even
at
that
first
time
is
something
that
would
Hoppe
evan
on
the
build
server.
So
something
to
be
aware
of
okay.
The
other
thing
that
I
noticed
is
that-
and
you
may
have
noticed,
is
too
already
is
that
the
output
path
for
new
product
system
projects
is
slightly
different,
so
I've
got
two
console
applications
here,
I'll
run
the
first
one,
it's
a
very
simple
application.
C
It
just
looks
for
a
file
loads
that
file
and
just
outputs
some
content
from
that
file,
which
happens
to
be
the
program
dot,
C
s
file.
So
not
that
exciting,
that's
using
the
old
various
it's
done.
The
same
application
migrated
to
the
new
project
system
will
run
that
one
and
we
actually
get
an
exception
it
filed
it
couldn't
find
the
file
to
open
it,
and
the
reason
is
that,
under
the
new
product
system,
it's
not
just
been
slash.
Debug,
it's
been.
C
Debug,
and
also
by
default,
the
the
target
framework
name,
so
there's
air
XE
there
and
for
most
of
the
time
that's
that's
quite
reasonable,
and
one
advantage
of
that
is
actually
it
one
of
the
reasons
that
they
did.
That
was
because
you
can
target
multiple
frame,
so
I
can
go
in
here.
There's
actually
I
want
a
target,
dot
net
4.5
and
done
in
four
point:
seven,
five,
four
seven,
and
so
it
needs
two
different
directories
to
output
those
two.
C
But
if
you're
migrating
a
sort
of
a
legacy
application
I've
seen
this
in
some
unit
test
libraries
that
I've
worked
on
where
they're
loading
data
files
from
the
project
itself,
and
so
one
way
to
to
go
back
to
the
old
way
of
output
path
used
to
set
this
property
here,
pen
target
framework
to
output
path.
So
that's
a
false
and
then
things
should
work.
So
if
I
rebuild
that
application
and
press
f5
everything
works
again.
C
C
C
You
get
packages,
so
two
class
libraries
that
I'm
going
to
that
are
creating
you
get
packages
and
I've
got
to
console
applications
that
are
consuming
those
NuGet
packages,
so
I'm,
not
using
project
references
I'm
using
package
references
here,
the
old
ones,
using
the
old
product
system,
the
new
projects
or
the
not
old
ones,
are
using
the
new
product
system,
and
so
here
I've
got
my
old
class
library.
I've
got
a
text
file
there
and
that's
being
added
in
as
content
in
that
NuGet
package
and
in
the
old
application.
C
C
So
it's
not
only
going
in
content,
so
we
can
still
work
with
older
projects,
but
any
new
product
system
needs
to
be
under
content
files,
and
this
also
shows
that
we
can
generate
a
new
get
package
from
the
project
file
and
we
don't
need
to
have
a
separate
new
spec
file.
So
we
have
our
generate
package
on
build
property
set
to
true.
So
every
time
we
build
this
library,
it's
also
going
to
create
and
you
get
package.
C
If
you
can't
remember
what
that
setting
is,
then
just
open
up
the
project,
properties
and
you'll
see
there's
a
package
tab
here
and
that
corresponds
to
this
option
that
generate
new
get
package
on
build.
There's
also,
all
these
other
fields
that
you
can
fill
in
that
are
all
the
the
values
that
the
metadata
that's
going
to
be
added
to
the
package
as
well.
C
So
you
can
fill
all
those
in
so
that
you
don't
need
to
have
a
new
spec
file
necessarily
to
generate
a
negative,
which
is
another
nice,
optimization,
one
less
thing
to
worry
about,
so,
if
I
using
that
package
and
I'm
using
it
in
a
project,
that's
also
using
the
new
product
system
will
see
that
this
text
file
new
we've
sort
of
said
that
that
should
appear
under
the
special
directory.
So
in
this
project
here
sure
enough,
there
is
a
special
directory,
and
these
are
text
file
new.
Now,
one
other
thing
to
be
aware
of.
C
If
we
hover
down
here,
it
doesn't
quite
show
up
so
I'll
just
select
that
value.
This
is
the
path
to
where
that
actual
file
is
it's
not
located
under
our
project
anymore.
It's
actually
located
under
my
user
profile,
so
be
aware
of
that
that
the
new
product
system
package
references,
the
packages-
are
unpacked
in
this
directory
under
the
users
profile
that
the
developer
or
the
account
that
your
build
server
is
running
at.
So
that
means
again
if
you've
got
codes.
It's
making
assumptions
about
where
these
files
end
up.
C
You're
gonna
have
to
change
that
code
and
again
I've
encountered
this.
Where
was
using,
you
get
packages
to
to
wrap
backpack
database
files
for
use
with
integration
tests,
and
so
I
had
to
change
those
packages
to
be
able
to
find
where
those
files
were
so
that
we
could
run
those
against
the
database
all
right.
Moving
on
another
scenario:
I've
got
a
a
solution
here
and
I've
got
a
class
library
that
I'm
creating
and
you
get
packaged
for,
because
this
class
library
has
some
fantastic
business
logic
in
it.
C
I'm
pretty
sure
that
this
business
logic
is
so
good
because
it's
it's
bug
free,
I'm,
pretty
confident
of
that
and
I'm
sure
the
other
developers
in
my
company
are
going
to
want
to
use
this
because
they
love
bug
free
code,
but
I'm.
Also
using
this.
As
a
project
reference
for
this
tool,
that
I've
got
here,
that's
doing
some
fantastic
stuff,
and
so
this
is
a
new
get
package
tool.
So
I'll
show
you
in
the
project
file
I'm
using
is
two
littles.
C
Using
the
new
get
package-
Explorer,
okay,
so
it's
a
tool
project.
So
it's
going
to
put
things
under
the
tools
directory,
but
we've
only
got
the
exe.
We
don't
have
the
the
linked
assembly
that
we're
also
depending
on
with
that
fantastic
business
logic
in
it.
We've
also
added
a
dependency
here,
we're
depending
on
this
other
package,
but
we're
a
tool
package.
We
don't
want
that.
We
should
all
be
self-contained.
So
how
can
we
fix
that?
C
So,
let's
go
back
here
and,
first
of
all
to
bring
in
that
rift
that
project
reference
we
need
to
hook
into
the
the
build
process
here
so
is
going
to
uncomment
this
line,
which
allows
us
to
hook
this
extra
build
target
in,
and
this
build
target
just
goes
through
any
project
references
and
make
sure
that
we're
copying
any
of
those
project
references
to
our
package
output.
The
second
thing
I
want
to
do
is
remove
that
package
dependency
because
we
don't
want
that
for
a
tool
package.
C
So
there's
a
private
assets,
property
that
I
can
set
for
the
project.
Reference
only
set
that
to
all
what
that
does
is
it
means
that,
as
far
as
the
new
gate
goes,
this
reference
I'm
using
it,
but
no
one
else
needs
to
know
about
it.
You
can
also
see
this
through
the
GUI.
If
you
expand
dependencies
and
projects
and
down
here
in
the
properties,
you'll
also
see
private
assets
include
assets,
so
if
I
save,
then
we
should
see
that
down
there.
C
C
Ok
different
scenario:
now
we've
got
a
new
get
package
and
my
developers
that
are
using
my
package
they'd
like
to
have
a
better
experience
using
that
package.
As
far
as
if
something
goes
wrong,
it
would
be
nice
if
they
had
the
PD
B's
and
previously,
you
would
have
said
David.
Don't
include
PD,
B's
and
you'll
get
a
package
because
they're
so
massive
and
they
doesn't
make
it
so
big.
But
we
now
have
portable
PD
B's
and
a
portal
pdb
is
a
lot
smaller.
C
So
it
is
conceivable
to
include
that
in
the
package
itself
and
I'll
show
you
what
I
mean
in
this
example.
Here
I've
got
a
library
and
the
library
itself
is
4k
and
the
PDB
is
only
1
K,
so,
rather
than
that,
the
debugging
symbols,
the
PDB
files
being
much
larger
than
this.
The
output
assemblies
they're
actually
generally
a
lot
smaller
now.
C
So
adding
that
to
when
you
get
packaged
is
no
big
drama,
so
we
can
do
that,
and
so,
if
we
edit
our
class
library,
we
just
need
to
change
a
property
here
to
say:
I,
don't
just
want
to
include
the
dll.
I
also
want
to
include
the
dot
PDB
as
well
and
I'll
just
increment
my
version
number
for
the
package
as
well,
so
that
we
can
do
that.
I'm
gonna,
rebuild
I'm,
just
gonna
rebuild
that
package
and
then
we'll
switch
back
to
here
and
so
I've
now
got
there's
in
that
package.
C
C
My
sleeve
I'm
just
going
to
delete
that
directory
and
I
come
back
down
here,
I'm
going
to
delete
object
in
the
C
sharp
the
source
code
for
that
as
well
I'm
going
to
come
back
to
the
project,
I'm
gonna,
remove
that
library
from
this
solution
and
now
having
done
that,
I'm
gonna
upgrade
these
two
projects,
because
these
have
package
references
to
that
package.
I
want
to
upgrade
those
and
I've
just
configured
it
to
look
in
that
directory.
So
the
upgrades
go
on
ahead.
C
That's
all
good
I
know
it's
going
to
rebuild
everything
here
and
we'll
see
how
now
that
we've
got
that
PDB
inside
the
package,
we'll
see
what
the
experience
is
of
a
developer,
trying
to
sort
of
use
a
runner
program
and
debug
a
program
that's
using
that
package.
So
here
we
go
so
there
is
a
problem.
It
is
going
to
throw
an
exception.
That's
expected,
however,
if
we
look
down
here
and
I'll
sort
of
zoom
in
a
bit
for
that
there
is,
it
doesn't
doesn't
know
what
the
language
was
and
it
doesn't
have
the
line
number.
C
So
where
is
that
what's
going
on?
Well,
it
turns
out
that
there
is
a
little
bit
of
an
issue
with
dotnet
framework
projects
that
have
portal
PD
B's
in
a
new
get
package.
It's
not
copying
the
PDB
from
the
NuGet
package
output
to
the
program
output.
So
then
it
doesn't
find
a
PEP.
So
how
can
we
solve
that?
C
If
we
have
a
look
at
this
other
project
here
we
can
solve
that
by
adding
another
package
reference.
So
so
people
have
figured
out
that
there's
some
extra
build
steps
we
can
add
in
that.
Will
we'll
do
that
copying.
So
if
we
add
the
reference
to
this
new
get
package,
source
link
got
copied
up,
PDB
files
and
we
debug
this
one.
So
the
only
difference
is
including
that
extra
package
reference,
which
just
changes
our
build
process.
C
C
The
other
thing
we
could
do
I
stopped
debugging.
This
is
even
add,
support
for
source
link.
So
what
that
will
do
is
allow
consumers
of
our
package
to
actually
step
into
the
source
code
for
the
assembly
that
they're
debugging
from
our
package,
so
I've
already
unloaded
the
the
class
libraries
that
we
were
using
here
so
rather
than
trying
to
bring
that
back.
Let's
just
imagine
that
this
project
was
also
being
packed
in
a
new
game
package.
C
So
all
we
need
to
do
to
make
this
include
information
for
source
link
is
add
in
one
extra
line
here,
and
that
is
another
package
reference
and
so,
depending
on
what
kind
of
source
control
you're
using
so
or
what
source
control
provider
there's
different
packages
to
help
out
with
this.
So
in
this
case,
if
I
was
using
VST
s
or
as
it's
now
known
as
your
DevOps
we've
get,
I
could
use
that
one
or
if
I
was
using
github
I
would
use
that
package
and
what
it
does
is
by
including
this
package.
C
It
updates
the
PDB
to
include
some
extra
data
that
the
debugger
can
then
read
and
know
where
the
source
code
is
for
this
particular
package.
So
what
does
that
look
like?
Well,
let's
see
an
example:
I'll
jump
over
and
bring
up
a
project.
So
what
I've
got
here
is
an
asp
net
core
web
application,
and
I
didn't
want
to.
B
C
The
path
of
that
file
is
some
path
somewhere
on
my
computer,
it's
it's
already
been
downloaded
the
first
time
you
do
this.
It
will
take
a
little
while
to
go
and
download
those
files
have
already
done
that
before.
So
it
was
pretty
quick.
The
second
time
around,
but
I
can
step
through
I
can
press
f10
or
f/11
and
step
over
and
step
into
and
jump
through
all
that
code.
C
C
B
C
So
that's
all
good
I'm,
so
yeah
just
wrapping
up
just
to
keep
things
on
time.
So
I
just
showed
you
the
new
product
system
and
how
we
can
really
reduce
the
size
of
our
projects
and
reduce
the
amount
of
change
we
need
in
those
particularly
the
package
references
we
can
centralized
version
numbers
and
directory
build
targets,
there's
a
little
sort
of
differences
in
dealing
with
generated
files
and
the
output
paths.
We
can
generate
new,
get
packages
directly
from
our
project
files
and
include
PD
B's,
portable
PD
B's.
C
You
know,
and
you
get
packages
and
even
add
source
link
and
yeah,
give
the
consumers
of
our
packages
a
really
great
experience.
So
all
the
demos
I've
given
today
are
up
on
github
in
a
repo
and
that's
it
there
and
I
would
try
to
include
links
to
further
resources
and
also
links
to
the
original
sources
for
a
lot
of
those
tips,
because
don't
be
under
the
impression
that
I'm
that
clever
I
just
know
how
to
search
for
stuff.