Cherry Picking in the Visual Studio Git Repository Window [Ep 1] Advanced Series

hi everyone thanks for joining this
session on cherry picking in the visual
studio get repository window where we'll
cover what cherry picking is and how to
do it easily with the help of the
multibranch git graph in vs cherry
picking a commit is a way to apply a
specific commit from one branch to
another this can be useful in situations
where you want to selectively apply
changes from one branch to another
without merging the entire Branch for
example if you have a feature branch
that contains multiple commits but you
only want to apply one of those commits
to your main branch you can use cherry
pick to apply that specific commit first
you want to make sure you don't have any
uncommitted changes you can double check
this in the get changes
window then you can visualize the two
branches you'll need the one you're
currently working on and the other one
that you want to cherry-pick the commit
from since I have the current working
Branch checked out all I need to do is
click on the I icon to add the second
Branch to my my view and easily see
which commit I might want to cherry pick
I'll bring up the commit details to
verify it's the commit I
want this is analogous to the falling
command on the command
line but with the multibranch git graph
I no longer need to Fumble with the git
log and commit hashes to create my
command and I'm confident that the
cherry-picked commit was added to my
working Branch correctly sometimes
cherry picking resolves in merge
conflicts if there are changes that
overlap
but Visual Studio will help you resolve
those easily with the merch editor which
you can learn how to use in this
previous video thanks for watching
everyone

Combining Dev and Test in the Org

so I've given this talk not you know
this exact talk but a version of this in
a quality discussion with customers and
you know we talked about how things have
changed in the cloud cadence and the
combine engineering and ship flap and
you know at the end of the presentation
they say wow that seems pretty drastic I
don't know if you are ready to do that
and the reality is that you know our
testing approach at Microsoft has been
evolving for quite some time I would say
for more than a decade so before I go
into what happened during the cloud
cadence I'll just give you a quick
history of what happened before that
because the customers that you might
talk to they may be at different phases
in this transformation and you know I
won't spend too much time in the h3 but
hopefully that will give you a sense of
how to kind of guide the customers
through this in case they are somewhere
you know prior to where the cloud
cadence happened in bsts
so you know I'm going to take you back
to 90s you know so for as long as
Microsoft shipped product we we always
had three distinct disciplines in in a
product team you know PM Devon Tosh PM's
gather customer requirements wrote specs
dev wrote code and design code and test
road tests roughly we would have a 1 is
to 1 is to 1.5 ratio it kind of varied
by teams but that's the general ratio we
used now within test we are two distinct
disciplines now many people may not know
this but this was a unique set up at
Microsoft where within test we would
have a software design engineering test
these are the s debts who developed the
automation the test infrastructure etc
and then software test engineer or the
STS who ran the automation or who ran
manual tests and this is a key point the
software design engineering touched we
are hired you know by the very similar
qualification as these of design
engineers or the developers you went to
the same colleges and if you hired from
industry would pretty much higher
developers and then convert them into SD
it is you know remember this point where
I come and talk about the combine
engineering because
this is this is important in in
particularly the way the test discipline
was set up at Microsoft so how did it
work well it worked reasonably well back
in the days you know we achieved
commercial success with big products
like Windows and Windows and Office one
of the benefits of this model was that
when we are ready to do a product
sign-off you will have the quality
discipline of the test discipline bring
in a very formal sign of criteria and
and formal measurements in quality and
so that give us a pretty good confidence
in you know declaring a product ready to
release it also developed deep expertise
in testing because the test discipline
was solely focused on testing they were
thinking about this day in day out so
that was the great thing but did it
really work though and the answer is no
it did not work there were problems the
problems were simply masked by the fact
that a we had commercial success of our
big products and B there was a long
product cycle but there are numerous
problems you know so the developers just
through the core over to the wall to the
testers s debts the s debts road
automation and then through that overall
to the ste the the software test
engineers so and these ste is the way
they responded is by just keep adding
more and more STS particularly the
vendors there was really no growth
opportunity for them that ste is because
they really didn't have any mobility
they couldn't go anywhere it was very
expensive to maintain this this set up
and testing became water-like and cause
product delays but again we couldn't see
some we didn't feel as much because our
product cycle was long we've shipped
Windows every two years or three years
so this sort of worked by V around 2000
late 90s it became very clear in the
company that this wasn't working and we
had to change something so a company my
decision was made to get rid of the STS
from the test discipline VRS debts and
STS I've no more STS they are gone
and we did that it was actually very
painful because those STS remember the
STS didn't have the same qualification
as the S debts and so a lot of them we
try to find them new roles in the
companies you know if some of them did
but many
many of them didn't so this this sort of
improved the model a little bit in the
sense that now you have s DT is one you
know responsible for not only writing
automation but operating the auto
automation so they they own the whole
thing so they were naturally incentive
as to a right good automation be you
know right more automation instead of
just throwing tests over to the another
team to take care of just running the
test they were now responsible for for
for it all but the core problems still
remain the developers would you know
through the code or wall to this s
that's a step are constantly trying to
catch up so we got clever and we said
you know what we're going to introduce
the thing called quality milestone or an
mq now these are milestone you
reintroduce or will have after a product
is released and before the next product
is about to start will block off a
certain period of time and say we you
know whatever the quality debt or test
that we've accumulated in the previous
release will just catch up and fix it
there now clever idea but it didn't work
it didn't work in practice
for just a couple of reasons one is that
now people knew that there was a
milestone coming up called quality so
they were just before the quality over
to that milestone and the other issue is
that your milestone dedicated to quality
so people would conjure up all kinds of
quality initiatives and things that they
think is creative inside the quality
realm and try to you know schedule that
work cause priority inversions and
sometimes that what didn't get done and
we just accumulated more more debt so a
clever idea that didn't really work so
the test was still a bottleneck but we
again we survived because we are in this
waterfall waterfall world
then came the cloud cadence so that I
have all of the cloud cadence around 20
2008 timeframe 2010 and it brought new
pressure on the system now there is
expectation that the you know we are
running a much faster faster cycle and
the expectation just continued to
increase you know faster faster faster
we long you know the gone are those
longer stabilization phases we don't
have
the opportunity to create a betta and
give it to customers do dog food you
know so those kind of validation phases
are gone which are crutches in the past
but they are now gone you know you're
living in the world of micro services
these micro services are deployed
independently so there is pretty much
pretty significant complexity in terms
of getting those services right the
quality right on an independent cadence
you know talked about how we had to
support no downtime deployments these
services need to stay up all the time
and so so what did we do well we knew
how to ship software for last 25 years
so we said well just use the same
approach just try to do it faster you
know if we went from two-year cycle to
six-month cycle to three-week cycle and
just try to figure out how to do
whatever we knew just do it faster so
our initial approach was same model run
faster he pushed for kind of getting
automation more streamlined and we got
clever again and we said oh what are the
ways we can deal with this is that we
don't need to run all the tasks guess
what you know we can be very smart about
which tests to run we'll pick some tests
here and pick some tests there and
that's how we'll survive but it was just
a matter of survival
it became very clear to us that the
model wasn't working and so the you know
we started seeing all kinds of issues
you know testing was a major bottleneck
by this time particularly bsts I think
bill or somebody mentioned that we had
some sprints where we do a three-week
sprint cycle we finished that then we go
through another three week of
stabilization by the time is a sprint
got deployed would take another three
weeks and this dead start running around
trying to stabilize the system and
deploy it the meantime though then the
work on the next sprint is already
completed and and so they're just you
know they're trying to catch up and in
the cycle would continue you know same
issues lack of accountability on the day
of the short the short version is that
we recognize that this model wasn't
working and we in fact we were not the
first one to recognize it there were
services before us like Bing was one of
the major services at Microsoft that
that saw this
and we we started seeing observing this
is you know based on the practices some
of the companies born in the cloud they
were following in the industry so so we
we we knew that maybe we needed a new
model in the in the cloud cadence so
that's what we we get to this point my
rest of the talk is about what happened
in the cloud cadence I just want to give
you a flavor of what happened before
that because you might run into
customers who probably still have the
world where you have Ste Zoo are running
around writing a running manual test and
there is not a lot of emphasis on
automation so you have to kind of bring
them along in the journey before you
kind of talk about some of the other
stuff you know I'll walk you through so
what happened what happened in the cloud
cadence in you know this is sort of
pretty much sums up the three big things
that we changed we changed the quality
ownership we fixed the quality
accountability so that's number one
the second thing is that we understood
that in order to ship frequently out of
a release branch you need to have a
master that is also in a pretty good
shape it's in always a shippable state
you know you see you saw Bill talk about
how you work in the master and then the
release will be released it's the
quality is not just about getting the
release branch right it's it's actually
quality you know starts in the master
branch and keeping it in a suitable
State now that you know the statement
about a lot of things sort of the code
flow and you know sort of how the branch
mechanics top that we'll talk about but
from testing perspective we focused on
two things one is this concept of shift
left shift left testing and I'll talk
about that in a second and then the
second thing was energy kicking it a
little getting rid of all the test
flakiness in the system the other thing
that we understood is that there is no
place like production this this is a
this is sort of I would call this the
shift right part of the strategy so on
shift flat you know run tests close to
the code run more unit tests to me ship
Fridays you know run tests close to
production because there is no place
like production and it's a set of
practices about
sort of both safeguarding the production
as well as ensuring quality in in
production so we you know even sense we
got rid of the the testing that was
happening in the middle you know sort of
the your integration style testing
functional testing that used to happen
in the lab that was the big departure
here all right so I'm going to walk
through each of these concepts in a
little bit more detail quality ownership
so though we did we did combine
engineering you heard this term before
you know we've talked about this
combined engineering in a nutshell is
you know those two disciplines Devon
test two roles taking those two roles
and merging them and putting it on a
single discipline single role call an
engineer so we got rid of the two SDNS
that roles just one role engineer the
key thing is that when we did this that
there is so first of all there is a that
individual has a combined responsibility
for both dev and and test so and it so
it's not just an organizational change
where you bring the dev and test him
together
it's an actual discipline merge you know
if you think about the set of
qualification or requirements of SDE for
set of qualification required per se
duties you merge them into a single set
that that's what this was and so
everyone had to learn new skills a lot
of times when I talk about this the
first question I get is this so what
happened to those s Nets they learn how
to write code well the reality is that
you know you remember the qualification
I mentioned earlier they knew how to
write code they got a little bit rusty
in terms of their design skills but this
was also a learning for the for the
developers because developers now have
to learn how to write tests write
automation run - you know do manual
testing do exploratory testing you know
things like that
so this required learning on both sides
and I think that's a key point when a
lot of times people talk about combine
engineering they say oh ok that means I
need to train my testers to be more like
there's no no it actually goes both ways
the other key concept here was that we
you know the idea behind this is that
you want to reduce handoffs there is no
you know in a short cadence you don't
have the opportunity to start somewhere
you know write your code give it to
another team to test and then give it to
maybe another team to do performance
testing and give it to another team to
do deployments the basic idea was that
we wanted to reduce handoffs in the in
the team and give an end to an
accountability to a feature team tour to
an engineer inside a feature team so
this was a big cultural shift across the
company this change happened in one team
but then it over few years every team
across Microsoft changed now different
divisions took a slight different
slightly different approach to doing
this in some cases like us in bsts when
we did combine engineering it was pure
like you know we just merged the two
disciplines there is no other team that
is responsible for quality every feature
team owns its own feature area featuring
equality so in some other orgs they they
had you know they still left another
small team and to kind of look after the
live site telemetry or live site
instrumentation you know things like
that but ultimately if you kind of
fast-forward now just about all teams
that Microsoft follows this model how
did we how did we make this transition I
think this is this is important thing to
talk about because it like I said it's a
pretty drastic change there our first
transition that I talked about where we
got rid of the SD rolls was very painful
and we had learned from that a lot so
when we rolled out this change
particularly bsts
fortunately for us there were a couple
of other teams that had done this at
Microsoft so we went and talked to them
we learned from them we had a lot of
discussions in the org kind of getting
the team ready to do this one of the
things that we were very concerned about
was that you know there is all these
things that
test him does some of it what I
described at the time is dark matter
like nobody understands what they do but
they do it and somehow that's magic
happens and the in the right quality you
know happens at the end
so we meticulously went and inventoried
everything that the test team does it
was a spreadsheet giant spreadsheet I
forgot how many rows but there was rows
of like we you know it's not just like
we done automation or we write
automation it was all the little things
that the test team dead to kind of keep
track of quality in the org and we made
sure that all those responsibilities
were reassigned to somebody in the org
basically to these new roles that was
that was very key the second thing we we
were very clear about is that this is
not just changing roles and
responsibilities we are going to have to
change the way we test period if we
continue to test the way we were testing
before it's not gonna work in this new
world so this is where you know I'll
talk about the shift left testing
testing in production those concepts
were not only internalized but practiced
in the org and we give ourselves about
twelve months to go through this
transition now remember when we when we
did this six months later we were
shipping TFS 2015 so the the litmus test
was getting the quality right for TFS
2015 so we we said we will give
ourselves about twelve months it means
in during that time the the SDS and as
debts will will start off kind of
basically in their old roles but slowly
evolved into doing the combined
responsibility so you have a you may
have a feature team within that the the
people who were former as debts they
continue to do more of the S Network and
the former SDS continue to do more of
that SD works but sprint by Sprint the
ratio kept changing and eventually you
know after six months you cannot
recognize it there from the tests in the
org so that's kind of how how we managed
it now at the end of the transition
there were people some people who didn't
quite make the transition
and you know that was that was the sad
reality but we we supported the
transition through training through sort
of just the development of the new
skills letting people practice practice
sprint after spinning after sprint and
so kind of just giving yourself a more
practical timeframe to go do this is key
well I think feel free to ask me
questions otherwise this will yeah go
ahead
so in this new model where everyone on
the team is an engineer and how do you
take the responsibilities that were
previously spread across the quality
organization and when he ate
responsibilities on a team where
theoretically everyone has the same
skill set of responsibilities I'm
wondering how that how the division of
labor actually occurs is all right now
when I cook on the team I'm on for
instance our test automation occurs with
different engineers and they're
automating to test but there and they're
writing code but they're not writing
features right and it's on the same team
so theoretically we're doing this too
but it seems like it's different from
what you're describing - yes it is
different and that's I think it's
important thing to clarify in the
beginning it looked like what you just
said so think let's take a particular
feature team in the world old set up we
had five developers maybe five testers
and that constituted a feature team we
bring them together under a single
engineering manager so now that any
remain manager has ten engineers working
for him responsible for the same areas
sprint one after combine engineering
happened it probably looked very similar
to what you just described that the the
the the tester was still spending most
of time developing tests the developers
were spending most of the time
developing code and design but the North
Star was clear the North Star was that
an engineer who owns a feature owns it
end-to-end they can take lot of help
they can get lot of peer reviews of the
of the of their test plants of their
design of the
their telemetry they can get in fact
they were encouraged to get a lot of
help in terms of peer reviews but the
expectation was that the next sprint
guess what they will be the one writing
test automation for the feature that
they own maybe they start with a small
feature that where they do that and and
the same is true for the tester the
tester started picking up small features
of the backlog and they said we'll own
these features end-to-end all the way
from design phase to deploying to
production and and then monitoring into
production so it started off like that
and then over time we expected devs to
pick up more and more the tesa
sponsibility and vice versa you flip
roles at times also and and that's how
in that's that's why what I mean by
allowing the team the 12 months duration
to sort of transition into this new
world you speak to a little bit about
what happened to like your team's
velocity and particularly the
development velocity then producing some
business value did that suffered during
this transition period and you guys feel
like you're back to where it was yeah so
on the velocity I don't know if Aaron
showed you a chart that showed sort of
our feature one of the ways we measured
a Pilate was the velocity was just
number of features delivered in a every
year on average per sprint and if you
look at that chart it's it's constant
it's been constantly going up since 2012
I believe we've been tracking and now
2017 so the short answer to your
question is no with the feature velocity
did not did not drop because remember
you still have the same number of
engineers in the future team you just
took the two separate teams you put it
together yes you're spending little bit
more time in terms of learning and
development and training sort of new
skills but there was also an efficiency
gate through this process and that is
the key efficience again is that you are
not handing things off to another team
when you hand things off to another team
guess what happens this is context
switch this is like one thread waiting
for the other thread to complete and
then then it has to pick up the con
and kind of run run again that constant
back input that is to happen between dev
and test that's gone and so you you gain
quite a lot so the longer and you
absolutely gain velocity you absolutely
gain more capacity in the short run you
could argue that hey there is there is a
some period of training and learning so
you so but it's it's it's a good
investment in just building out the
rounding out the skills and you'll see
as I talked about in a second the change
was pretty profound across New York it's
not just by feature team we got rid of
in fact I can talk about that now we we
got rid of basically this notion of
specialization there is you there are no
handoffs
you don't take a feature you write it
you design it you give it to another
person to test it then you give it to
another person to deploy it maybe
there's another person like we'll talk
about is a branch mechanic whose job is
to push code around maybe there's
another person whose job is to make sure
the product is ready and it's got the
right performance metrics like all this
different there's another person who's
testing the deployment configuration
testing you know things like that we we
took the core principle that there are
no central teams there are no
specialized teams that do certain tasks
that was a core principle but at the
same time we understood the importance
of specialization specialization is
important creating a central team where
you hand things off to in a fast cadence
is is a problem so we didn't want to
lose specialization so we did form a
bunch of V teams and I know what
deliberately call them V teams because
these are not dedicated teams the right
now in pranks or there is only one team
you could call that a dedicated team
that does you know sort of the EPS team
or the team that runs our central
engineering system it's a small small
feature team but they again they do core
engineering work for the they they're
contributing to the engineering system
the nobody is handing things off to
their team so set of V teams we form one
of them
was best architecture we team now this
was a new new thing we didn't have this
before we had an architectural we team
that looked after the product
architecture we didn't have anybody
looking after the test architecture and
remember we we learned that we knew that
we had to change the way we test which
means we had to rebuild our test
infrastructure we had to rebuild the way
we ask our tests from the ground up so
we we picked our senior-most engineer in
fact bill you know it's a partner i see
in the orc senior-most i see he said
you're going to lead this team and he
had a set of other engineers from across
york part of the v team and this team's
job was to like I said it not only build
the next architecture for - but champion
set of practices that we were talking
about yes this question can you please
explain the concept of each team via
team means virtual team so these are
members from different parts of the
organization okay it's not a dedicated
team reporting to a single manager
that's what I mean
we had tests sorry tenets champs V team
so what are ten attempts so these are
people who are looking after your
subject matter experts who are looking
after some specialized activity that we
do in - whether it's making sure the
product is accessible whether it's
making sure product has good performance
and reliability it's its global ready
you know things like that this used to
be again you know largely be done by the
by the test team in the past in the new
world we refactor this responsibilities
again every feature team is responsible
for making sure that their feature is
accessible is performance is global
ready but we we would have a we team of
experts from throughout the
organizations whose job is to build deep
expertise in this type of activities
this type of work
so the subject matter expertise is still
valued in the org specialization is
still valued in the org the the main
difference is that it's not you know
sort of consolidated into a
dedicated team I mentioned performance
we team you know this is important
because when you're looking at service
performance product performance
oftentimes you find bottlenecks in let's
say you are a and one of the top-level
feature and you're doing performance
testing for work item tracking and you
find water like somewhere deeper in the
system which is owned by somebody else
so we formed a performance V teams job
was to identify common bottlenecks
across the entire product and come up
with the right design solutions and
drives that you know this kind of work
you cannot just farm it out to
individual feature team because the
performance is an end-to-end end-to-end
problem is not isolated to a particular
layer of the product of the product
couple of other B teams be marred don't
even ask me what to be more stand for
because I'd right here at the moment I
may not be able to figure that out but
it's B mods are the people who look
after our daily build health and the CI
health and these guys are constantly
watching the builds and the runs and if
there are any failures in the in them
they do a quick triage and assigned to
the appropriate owners so we formed a
beam or team and and you'll see that
over time the the size of the beam or
team also shrunk as well as the what we
expected be much to do also shrunk as
the system and the engineering system
got better
finally we retained a small vendor
vendor we team that own sounds really
hard to automate type of tests he knows
like config tests you know we TFS being
deployed on on Prem different
configuration environment but again over
the last three years this team has
constantly shrunk because we every year
we ask the question why do we need so
many vendors who need to do this manual
testing let's go automate that or let's
figure out a different way of running
those tests so that's that's the end of
sort of what happened in terms of
changing the quality ownership and
bility so good question about what
tenant champ sweetie my donors in the
word tenant I really do yeah so tenet
means
so performance is a tenant accessibility
is a tenant like an aspect yeah aspect
of the product there you go yeah an
attribute of the product yeah
quality here to the other question was I
heard from Scott good three in a person
take some time ago the move to
everything being done through the
command line
did that help in automating some of
those aspects that the vendor team was
having to do manually no vendor team is
actually you know there it today our
render teams doing things like we have
TFS on Prem and can be deployed on so
many different configuration that we can
automate that in theory it will require
a significant amount of investment and
you know for things like that where the
cost of automating you know
significantly more than you know kind of
cost of just running it through
extensive the questions so it's it's a
matter of trade off that's right
initially it was a matter of survival
because remember we came from a world
where you're half the team that is
basically running tests and writing
tests to world where suddenly that
responsibility is is kind of you know
distributed out to the org and so
initially just you know as we
inventoried the whole list of things
that the test team was doing and we knew
that there was a good chunk of testing
doing this manual testing and even then
we had the vendor team even test him
used to retain a vendor team that would
run this kind of hard to automate tests
we didn't want that to drop on the floor
the creaky corrected are going through
this was we are shipping TFS 2015 in six
months it needs to be as good quality if
not better then it was in the previous
model not only that we are you know
shipping whenever you would continue to
ship to the cloud every three weeks so
in in going through this the key
criteria was that nothing should fall on
the floor nothing should go slip through
the crack so even if we were doing
something that was not
optimally design or efficient we just
continue to to run that in the new world
until we figured out a way to do it
better doesn't make sense the initial
thing was take whatever we have just
refactor give it to different set of
people meaning give it to the feature
team but don't drop it on the floor even
if it looks questionable like why are we
why are we running this test it's not
adding any value just keep running it
for now until you figure out that there
is there is a different way to do that
yeah question so if I understand well
these are like will CH all teams does
this seem that these people have other
assignments and if this is so was the
ratio between their capacity in these
assignments and some other things that
they do yeah so these are the same
people that we have in the feature teams
these in and so let's take a specific
example let's take accessibility for
accessibility we have subject matter
expert by location so in Redmond we have
two people who are some accessibility
except export and we have another couple
people in North Carolina our locations
and maybe another couple people in India
they they are deep expert in
accessibility techniques philosophy etc
but they are engineers inside a
particular feature team they just happen
to have this secondary responsibility
accessibility happens to be one of those
tenets that requires quite a bit of it's
not work but there's a quite a bit of
responsibility on that subject matter
expert so the person who's the
accessibility champ probably spends half
their time doing accessibility and half
the time doing feature work but the idea
is that that responsibility also over
time rotates so it's not the same person
every single sprint we pitched it to the
same person for a given release so TFS
2018 there's 1% maybe TF is 2019 we'll
try to give that respond you to somebody
else so nobody is doing this for for
life if you will
in the number of experts vary by by the
tenant that we are talking about I
performance via team I think it has
about dozen people yeah the question so
in this model I see that now individual
is probably taking care of many things
now one who did testing had to take care
of so many tenants and things now as a
developer he has other responsibilities
so I imagine you manage that by maybe
making smaller features and things like
that
did you have any challenges with
entering coverage because now my
responsibility as a little is even
smaller and how did you manage that end
to end were there any gaps that were
unveiled by these things so if I
understand your question correctly so
yes you know it it appears on the
surface it looks like your engineer is
now doing twice the amount of work you
know feature team because you know the
previously you have I'm our dev our
tester who's paired up with me and he's
doing half the part of the feature work
or the testing work now I am responsible
for the feature but remember now I have
if I am the manager of the feature team
I have twice as me you know sorry I'd
pass as many engineer size as I had
before you know so the net capacity
hasn't changed net capacities are still
the same what I give you more time one
of the two right you know yeah
[Music]

Committing code changes (2 of 5) Getting started with GitHub

on this episode of Visual Studio toolbox
we're continuing our mini series on
getting started with GitHub we're going
to see what happens when you actually
write code
[Music]
hi welcome to visual studio toolbox I'm
your host Robert Greene and this is
episode 2 in our five part miniseries on
getting started with GitHub in the
previous episode we looked at how to
create a project in visual studio and
then we created a GitHub repository with
that code and in this episode we're
going to start writing some code and see
how we work with GitHub
so I created a simple console
application we have a simple line of
code here let's make a change to it so
I'm going to change the greeting to
hello Visual Studio toolbox
now get is watching locally and I can
see that we have a change so if I come
down here to the lower right and I look
at this little pencil in the status bar
it says one telling me I have one change
I click that and I go to the get changes
window where I can see all of the
changes I've made and I can see that
program.cs has been modified well from
here I can undo the changes if I want I
can also stage these or stash them which
means I'm not ready to commit now but
I'll commit them later on but in this
case I think I'm ready to go so I'm
going to enter a message which is
required when I do a commit I have to
enter a message which is a good thing so
I'll just say changed greeting
and then I have some choices I can
commit all commit them to my local
repository which does not send them to
GitHub I might do that if I want to uh
if I'm done working for the day and I
want to make sure that I've kind of
backed up that code committed it to the
repository locally in my machine and
then when I'm ready to send it up to
GitHub I'll do a push so I'm going to do
this right now this is one of my
favorite features you have to save your
files before you commit I almost never
remember to so like Visual Studio warns
me so I'll save this and commit it and
what that's going to do is copy these
changes up to the master branch in
GitHub so successfully pushed so not
presumably we can pop over to GitHub
and look in the code and look in program
and there's the change I made very cool
now what we can also do in GitHub is
click on this changed greeting and see
what the changes were oh I changed it
from world to visual studio toolbox very
nice
now if I come back into Visual Studio I
know I have this change here what I can
do is again go to our Branch history and
see that I changed the greeting so again
Robert is me locally Robert Green are
any changes I make on GitHub
representing another developer or me on
a different machine and then I change
this locally and if I double click on
this I can see the changes so this is
the code that was this is the code that
is I can switch around from side by side
mode to inline mode whichever one works
best for you
okay
so now
I'm not the only one working on this
application turns out
so
maybe the other developer also decides
to change the greeting and I'm going to
do this in GitHub just to keep it simple
typically you'd probably do this in
Visual Studio or Visual Studio code but
rather than have multiple visual Studios
floating around I'm just going to make
all my changes in GitHub
so I'm going to change this to visual
studio developers I mean commit the
changes
commit message defaults to update
program name and extended description
I'll type changed greeting and I'll
commit this to the master branch
okay so another developer is made a
change
now back in Visual Studio
I'm told hey somebody changed your code
now I've got a couple choices I can do a
pull which will bring down those changes
in overwrote what I wrote but maybe I
want to see what the changes are ahead
of time so I can do a Fetch and what a
fetch will do is bring down from GitHub
the latest version of the master branch
and store it in my repository history
but not overwrite my version
so now I can see what the differences
are so if I click here I see I have one
incoming
and I can see that
program.cs was updated by somebody on
the server I double click on that and I
can see
the code that I have Visual Studio
toolbox and the code it was changed to
visual studio developers and I'll decide
okay that's fine I'll take that so now I
can do a git pull and copy down the
remote version to my local version
and now if I go look at my program.cs
I've got the latest version so this is
how I can keep my local version of the
repository in sync with the remote
version up in GitHub which will be sort
of our official version and then if I
come into the history and do a refresh
here I see that I changed the greeting
locally somebody else changed it on the
server I did a poll to bring everything
down and now my version of the code
locally is in sync with the version of
the code remotely that's basically how
we're going to have multiple people
changing code and everybody then pushes
it up into the remote repository which
is the official version and then by
polling we can keep our local copy in
sync
so what we've seen in this episode is
what happens when we start making
changes to code so we made a change we
pushed it up to GitHub somebody else
made a change they pushed it up to
GitHub so we saw you can have multiple
developers or you working on multiple
machines or multiple versions of Visual
Studio it all works how we can keep our
local repository in sync with the remote
repository which is essentially the
official version of the code
if you're watching on YouTube and you
like this please like us share with your
friends and come back for episode three
in our mini series we're going to look
at working with branches and see what
pull requests are used for
we'll see you next time on Visual Studio
toolbox
foreign
[Music]

Conditional Breakpoints [4 of 5] Beginner’s Series to Visual Studio Tooling for Unity Developers

>> [MUSIC] My name is
Charles. In this video,
I'm going to show you how to
use conditional breakpoints
to focus on the data and
values that actually matter.
That way, you can debug
smarter and fix bugs faster.
More often than not, your games
most crucial features are
the ones that present the
biggest debugging challenges.
Take this project, for example.
Spawning is one of its key mechanics
and I've tried to
improve that by writing
code that changes the SpawnRate in
response to the player's skill level.
The idea is that enemy
should spawn faster
when the player is doing well
and slower when the
player is lagging behind.
To achieve this, my logic
modifies an animation curve
that represents enemy
SpawnRate over time.
Here, the x-axis represents time
and the y-axis represents SpawnRate.
This graph represents a
linear progression in
which enemies will spawn
faster as time progresses.
However, that's just a
static, hard-coded example.
In reality, our graph will
fluctuate as the player plays
and there's no telling what it will
actually look like at runtime.
If it's working as expected,
the players should be
met with a challenging
yet manageable flow of enemies.
However, somehow I've
introduced a bug that causes
the SpawnRate animation
curve to fall below zero,
which results in a ton of
enemies being spawned.
That's no fun for the player
and especially no fun for me,
the developer who now
has to figure out
what in the world has gone wrong.
Looking at the code
that's responsible
for updating the animation curve,
we can see that it uses
an algorithm that applies
some modifiers to a
configurable base SpawnRate.
The key modifier here is
the difficulty modifier,
which is used to increase the
time in-between each spawn.
This is really good
information to work with,
but I'm not really sure where
to begin my debugging process.
The problem is that algorithms
are not my strong point
and I have no idea
what could be causing
the SpawnRate to spin so
wildly out of control.
I'll need to do some debugging.
Now, the standard approach is
to use debug.log statements
to get more information
about what's happening.
However, in this case,
we've got a lot of noises,
there's just too much
happening in the scene.
We could add some logic
to make our logging a
little more intelligent,
but then we just have a
bunch of debug code peppered
throughout our logic
and no one wants to maintain that.
Instead, we're going
to use a feature of
the Visual Studio
debugger that'll help us
quickly get more information
without all of this extra code.
Let's start by adding
a normal breakpoint on
the line right after
SpawnRate gets assigned.
Then let's attach
Visual Studio to Unity.
Perfect.
Now, switch back to
Unity and hit "Play".
This will cause the debugger
to immediately cause
the execution of our code on our
breakpoint just as expected.
Now that's helpful
because as we've covered
in our other videos about debugging,
we'll be able to inspect any
and all variables that
are currently in SQL.
But I'm not really interested in
inspecting those variables just yet.
At this point in our games lifecycle,
SpawnRate is being set
to a reasonable value,
it's working exactly
as I expect it to.
While I could poke around,
I don't know if I'd be able to
discern anything of importance.
What I really care about
is inspecting the code
when the bug occurs and
only when the bug occurs.
That's where conditional
breakpoints come in.
Conditional breakpoints
are a feature of
the Visual Studio debugger.
They allow you to pause
the execution of your code
when certain conditions
have been met.
This can give us a great deal of
additional control over
our debugging process.
Let's see it in action.
Back in Visual Studio.
Let's modify our existing
breakpoints so it pauses execution
when SpawnRate dips below
a certain threshold.
For example, a threshold that
we deemed to be unacceptable
or too dangerous for the player.
To do that, all we have to do is
right-click on the breakpoint
and then select "Conditions"
from the context menu.
This will present a breakpoint
settings block that appears
just below the line on which
the breakpoint is set.
From here, we have a couple
of options to choose from.
Let's expand the first drop down.
Our options are conditional
expression, hit count, and filter.
Conditional expressions represent
any logical condition
that you can think of,
so long as the values you
reference are in scope.
When using conditional expressions,
the breakpoint will be
triggered when your expression
has been satisfied or when
a value has been changed.
For example, I can
reference SpawnRate so that
execution pauses whenever
its value changes.
Hit count triggers your
break point whenever
the line has been executed
a certain amount of times.
This is great for loops that you
suspect have gotten out of control
and are iterating more
times than they should.
Finally, the filter option
triggers your break point
when specific low-level
conditions have been met.
There are a number of
predefined filters available,
such as machine name, process ID,
and thread name that
you can use to restrict
your breakpoints to select
devices, processes, or threads.
In our case, we don't need
anything complicated.
We'll just use a
conditional expression.
Since something is
causing the spawner
to spawn enemies way too quickly,
I suspect that SpawnRate is being
set to a ridiculously small number.
Let's confirm that suspicion by
adding a condition that triggers
the breakpoint when the value
of SpawnRate drops below 0.5,
then we can examine the other values
and try to determine what's going on.
This condition is possible
because SpawnRate
is in the same scope
as the breakpoint.
You may recall from
our debugging basics
video that you should
take care to add
breakpoints to the lines
of code for all of
the variables you want to
inspect are accessible.
In our case, SpawnRate is
a variable that's local
to the function where our
breakpoint is currently placed.
So we're good to go.
Let's play the scene until
our breakpoint is triggered.
[MUSIC].
Great. Our conditional
breakpoint worked.
The execution of our code
is pause at the point
where SpawnRate has reached
an unexpected value.
Now we can figure
out what's going on.
Again, I'm terrible with algorithms.
Hopefully, the solution
will be simple.
Let's analyze each variable
that's used in our dynamic
SpawnRate algorithm.
Base SpawnRate is a field that
can be set in the inspector.
It represents the base
SpawnRate of the spawner.
It should be set to a moderate value,
which it looks like it is.
Next, spawn enemies is an instance of
a scriptable object that
holds a list of game objects.
Here we're adding the count
to the base SpawnRate
in order to increase the
time between each spawn.
That way, the game becomes easier
when there are more
enemies in the scene.
Moving on, difficulty
modifier is another field
that can be set in the inspector.
Its job is to tune down the impact
that enemy count has
on the base SpawnRate.
The lower the value, the
harder the difficulty.
In this case, it looks
like it's way too low.
In fact, a negative value should
not be allowed here at all.
This is a common problem that happens
when you expose
properties in the editor,
especially when those properties have
an effect on your
games key algorithms.
Users will always
find a way to provide
values that fundamentally
break your logic.
That being said, being able to
parameterize your component
is extremely important
because you want to be able
to hand off tasks like
tuning difficulty to game
designers wherever possible.
Instead of restricting this
property to fix the bug,
we're going to make a
couple of quick changes
to guard against bad user input.
The first is the range attribute.
Range is a Unity specific
attribute that limits
the value of a property in the
editor to a predefined range.
Let's limit difficulty modifier
to a value between 0.1 and 1.
Perfect. Now, our game designer
won't be able to input
a game breaking value.
That's a great start, but we
still need one more check.
A dynamic SpawnRate algorithm
partially depends on elapsed time.
That means that given enough time,
SpawnRate will eventually dip
down into an unacceptable range.
Luckily for us, the
solution is as simple as
clamping SpawnRate between
two acceptable values.
This will allow us to provide
minimum and maximum values.
That's it, our game
is back to normal.
More importantly, we've limited
the ability for our game designer
or anyone else who modifies
the spawner component
to break our logic.
It was all thanks to
conditional breakpoints
in the Visual Studio debugger.
Without them, we either have to sift
through tons of log statements
or manually pause and continue
the execution of our code until
we reach the broken state.
Conditional breakpoints gave
us the ability to place
a breakpoint that pause
only when we needed it to,
which helps us close
our feedback loop
and dramatically speed up
our debugging workflow.
Best of all, it works the same way
across all Visual Studio products.
Whether you're using Visual Studio
for Mac or Visual Studio code,
be sure to take advantage of these
powerful time-saving features.
[MUSIC]

Containers and Existing .NET Apps (Part 2)

on this week's visual studio toolboxes
dd-do gar is going to finish our
two-part look at how you can
containerize your existing dotnet
applications hi welcome to visual studio
toolbox I'm your host Robert Greene and
joining me today is a dd-do guy hey
DeeDee hey this is part 2 of our chat
about containers in part 1 we looked at
adding container support by a docker to
an existing web forms up we used and the
whole idea is that we've talked quite a
bit about containers in the show lately
in the context of Micra services and the
smart hotel 360 app but this is our
opportunity to kind of step back and do
again two things one is kind of do a
more gentle introduction to containers
to the extent that's possible step back
and we talked quite a bit about what
they are and why and then focus on
existing apps you've got an existing web
forms app or MVC app you've got an
existing WCF service write all the code
that that we've that people built
earlier and are still maintaining and
how does containers fit into that story
exactly so that's what we're doing we in
episode 1 of this we created a container
we got it running locally which is great
but now the question is what do you do
with it right how do you get that
container out so that it can be used in
production one way of course is to run
it in Windows servers yes so you don't
need the cloud to run containers you can
run it on Windows server or of course
you can get these things up and running
in Azure and that's what we're gonna
talk about today right sounds great
excellent Ozzie um so I think the first
thing we're going to talk about is
orchestrators okay so the first thing
you want to think about when you're
deploying to the cloud is what
Orchestrator I'm going to choose and an
Orchestrator is basically a platform
that's going to help you manage all
aspects of deploying and setting up your
containerized application ok so there's
a lot of different orchestrators out
there there's
Nettie's there's service fabric there's
docker swarm there's all sorts of
options and all of them have their
different pros and cons but today I'm
gonna highlight a couple and those are
managed kubernetes and as your container
services and as your service fabric okay
and the main difference right now
between those that we're gonna highlight
is just that as your container services
it's a little bit more mature for Linux
containers versus service fabric as it's
part of the Microsoft ecosystem is a
little bit much R and Windows but really
it doesn't matter which one you choose
both of them will work just fine right
so I think we we talked about this last
time if you're kind of new to containers
if you're doing dotnet core so it's a
brand new app net cork and run a Windows
can run on Linux you might choose Linux
containers exactly if you're using
kubernetes they're smaller they're I
don't know performance wise if they're
faster but they're certainly smaller and
smaller to create so your dev work is a
little bit faster and then if your
dotnet core app is running on both then
you know that's then you've got the
flexibility there obviously if you get
an existing web forms app you don't want
to have to rewrite it as a core app yes
so that you can run it in a Linux
container so that you can use kubernetes
yeah exactly and we're building on the
scenarios that we talked about in the
last show which we're really your
existing write net applications so
windows containers so we do have windows
support for kubernetes which is there
and improving and will continue to
improve quickly exactly and so today for
the demo purposes I'm going to talk
about kubernetes and Roger container
services and focus on that in the demo
but we have both walkthroughs
highlighted online so you can follow
them step-by-step so on to kubernetes is
an Orchestrator and as your service
fabric is an Orchestrator what's as your
container services container services
outer container services is basically
the in Azure environment in which
kubernetes is going to work so you
basically will setup your resource group
and Azure and you'll set up your
kubernetes cluster and connect that into
as your container services but
kubernetes is the actual Orchestrator
that you
okay it's confusing I know so I want to
talk quickly about just the benefits of
orchestration and why you would want to
use it yes it's especially important
when you have things like microservices
in your application but even for smaller
applications it can be really convenient
you can have automated deployment and of
your end replication of your containers
you can easily scale in or scale out
just online which is makes things really
easy in terms of deployment load
balancing so you can load balance
between all of the containers and pods
that you have internet is pretty easily
you can have rolling upgrades it's a lot
more resilience because you can
automatically reschedule failed
containers so you don't have to worry
about all my container failed and
there's gonna be a break you can
automatically make sure that there's no
breaks in your service and then lastly
you can have controlled exposure of your
network ports so that people outside of
your cluster you can kind of control
that exposure so it really turns out
that containers is very much is really
DevOps yeah yeah everything you just
said I know like me is the developer I'm
like yeah it's great that's all
happening but I'm the dev right I write
the app right I hand it over to the Ops
guys to do that and I know DevOps whole
concept is to you know shrink that
barrier and merge those two were exactly
but in our you know demo we're doing
here and we did previously we didn't
touch the app nope we just got the app
up and running in a container added the
docker support which made the container
out of that app and then you go and
manage it mm-hmm exactly yeah that's a
great point I mean if you remember in
the first episode actually the first
picture that we showed was really
calling this sector cloud DevOps already
and it's really focused on highlighting
the fact that this is just really really
helpful
your DevOps you look at a lot of surveys
people why you know what they're
interested in containers and you find
that they're really interested in the
DevOps side exactly I want to use
containers for DevOps yes as a way of
more easily packaging up an application
yep exactly
cool um so we're gonna get into the demo
now but just a reminder of where we were
at when we ended last time so we had
a application with a WinForms front end
a WCF service in your middle tier and a
sequel server on the back end and we
went through and we containerize the WCF
service and the sequel server and got
those running locally on our machine
okay so let's go into basically if you
want to deploy the kubernetes there's
two really high-level steps the first is
setting up in Azure and making sure your
kubernetes cluster is set up and
deployed to Azure and then the second
part is deploying your application and
all of the resources needed into the
kubernetes cluster so today I'm gonna
focus on kind of that second half of
deploying your application actually into
kubernetes okay but that assumes that
you've gone through and in your Azure
portal you've created that kubernetes
cluster and you have that all set up
already so you can do in Azure now you
can also do that in kubernetes
kubernetes has a whole web-based UI for
setting up clusters and whatnot all of
this do a sure you can do all this
through a sure and set up the ACS that
you need as well and if you want
step-by-step instructions again we have
all of that yes lay it out on our shop
on containers repo so I'm not going to
go through it today cuz it would take
too much time but you can definitely
follow this through and be able to walk
through step-by-step okay cool and so
there's a few terms I want to bring up
in kubernetes before we dive deep into
it just so we're all on the same page so
the first is pods yes
so pods are kind of the basic unit in
kubernetes and that's really the pod
posterior container and so you could
have multiple containers in a pod or you
could have one container in a pod
but it's really the environment for your
container and then there is a service
and the service is really helping you
network between the different pods
mm-hmm and then what you have if you
have two services and two different
containers they need to be able to talk
to each other really just like we have
you know our sequel container and our
WCS retainer and we want to make sure
all of those services are set up
correctly and then lastly
there's a deployment so the deployment
is really going to help you automate
that setting up the replication the
deletion the creation of your pods okay
so those are the three key terms that
you kind of have to know going forward
so if we the first step in that second
part of the process would be to create
our kubernetes deployment files and this
is kind of similar to what we did with
our docker files so there's a couple of
files that we have to create again text
base so super easy to create but these
are really just describing the
step-by-step instructions for kubernetes
to make sure the deployment goes
smoothly so I've created this folder
here in the root of my project so this
is where my project is and I've created
this new folder and the folder hosts a
couple different files one for the
sequel container and one for the WCF
container on our yellow file there yet
another markup language that's literally
yes exactly
hilarious so let's go into both of these
and I can walk through what's going on
here so first here we're specifying that
its deployment we're giving it a name
and then everything under spec here is
just describing this deployment so we
have it labeled as a sequel data so
we're working on the sequel one first
and then here you're gonna see this
looks really similar to what we did in
our dr file
so you're just specifying what image you
want to use again so that same sequel
server windows image and then you're
defining some environmental variables
and then lastly this part is important
so this is saying that you want your pod
to be attached to a kubernetes node and
you want the kubernetes note to have
Windows running as the operating system
so that's where I'm specifying this is
kind of a one of the many tips and
tricks is that when you create
containers you need to be clear if it's
a Windows container you need to tell the
environment hosting it that it is right
exactly if you get this running up in
like an azure container instance it's
very easy to tell the ACI
that it's a Linux container when it's
really a Windows container hmm and then
Oh what do you know it doesn't work it
takes a long time to copy the file up so
you learn a long time after that it
didn't work because you told the thing
hosting the container that it was a
different OS right yes exactly so key to
put Windows I'll help you a lot but I've
heard of people who after they did that
a couple times learn to never to do it
again
yes exactly at all
and so then we've specified that this is
the end of the service here and we can
define another one right in the same
file and then the second service is
actually a load balancer and the load
balancer is going to do a couple of
things one it's allowing us to specify
this external IP here so that we can
understand where people need to go to
access this and then secondly it's
exposing this port here 1433 and this is
the default port that sequel listens on
so I'm just making sure that when
traffic goes there it's listening in on
that same port that your sequel
container is listening in on so
theoretically you could leave the sequel
server on Prem if you have the container
and Azure talked through it through the
hybrid connector right you could yes
theoretically if you wanted to do that
for sure so that's actually the extent
of this sequel file so not too much in
here I'm gonna take a brief look at the
WCF file and just highlight the one
difference in here so it's basically the
same as the sequel one but we've
specified a strategy here and this
strategy is a rolling update strategy
and all that's saying is really that we
want to make sure new pods are created
before the old ones go offline so
there's no break in your service so
that's that's really the main difference
here and you can go to the kubernetes
Docs and and find documentation on how
to build these files and what this all
means exactly yeah yeah we specified a
lot of that again in our wiki too as we
take you through that kubernetes has
more extensive
documentation sees some day and Visual
Studio right-click and publish using
kubernetes where these things are just
dialog maybe it's just like we have for
a docker how would be great okay cool um
so that's actually those are the only
two things we have the add docker
support that writes the docker file for
me and the docker compose file yep
so this could be this this would be nice
okay these are the only two files
actually that I need okay
now deploying into Azure so I'm gonna do
this through vs yes you can do this
through the command line if that's your
preferred method whichever way you want
to choose is fine but let's go into VST
yes so here in bsts I've created a new
release definition and this is really
first I'm adding an artifact which is
just specifying where I'm getting my
files and my code from so all of my code
is up in github so I'm just accessing
this repo where the code lies here okay
I'm specifying there and then here in
this environment I've added three
different tasks and that's to deploy the
sequel container deploy wucf container
and refresh the WCF pod
okay so here's actually where I'm
referencing those Hamel files that we
just created so that looks a lot easier
than having to learn the command line
prompts to do this yeah it depends if
you're familiar with Visual Studio teen
services I think it's easier in that
sense but there can be a learning curve
to just understand there's a lot of
different things in bsts so whatever is
easier for you it's not that many
commands as well in the command line so
I think a lot of people start with that
yeah that's easier so here in the
configuration file I've specified that
we're pointing at that sequel container
deployment file that we just created and
that was in the root directory that's
why I created it you know in that same
folder that we were working in for our
project and then down here you also have
to make sure that you had your images
pushed to a container registry so we had
them up in a docker registry
to use ACR yeah exactly so they have
options for container registry or
container registry whichever one you
want to choose WCF container same thing
except you're referring to this WCF yan
will file that we created and then
refreshing the WCF pod is pretty easy as
well
and what does that do that's really just
making sure that the pot is refreshed so
it's a step by step process right so
you're gonna deploy your sequel
container and then you're gonna deploy
or WCF container but things kind of
don't go in sync necessarily so you want
to make sure at the end that you refresh
because your WCF pod is really relying
on the data from your cereal container
you just want to refresh it at the end
make sure it's all kind of in sync
together so now I could go to the
releases and we will see that I was
looking at this one here
just now and I could create a new
release and this can obviously be part
of your usual flow you make changes you
build you release exactly or you could
just use the release here because it's
easier yep okay specifying that
environment that I just defined with
those three tasks mhm and then I can
choose if I want you know the latest
build from getting up or which kind of
version I wanted shoes here mm-hmm and
say create
so release 10 has been created so if I
go to release 10 it's not automatically
deployed so I'll just go here press
deploy and it's just telling me that
release 10 is the same as release 9
because that's what I created this
morning and if I go to the logs here's
where you can see the step by step
process so this will actually take you
through the entire process of those
running through all those tasks that I
just showed you but we're not going to
go through this right time place exactly
The Container which is we large yeah so
it'll take a little bit of time so I've
actually already done a deployment
earlier today and so we can go and take
a look at that in my career Nettie's
dashboard so - now you you're now over
in kubernetes you're you're into
kubernetes yeah and that's where I can
really discover all my pods and
deployments and services and to pull
that up all you do is type cube CTL
proxy into your command line and what do
you have to do to get cube Cuddalore
however you want to call it on your
computer in the first place you do have
to install it before that ok so if you
type cube CTL you can find instructions
on how to install that it's like any
other CLI that you have to install on
your computer yeah but that will allow
you to access this IP here so thank you
cuddle proxy and that connects mm-hmm
I give you the ability then to go into
the browser and see the dashboard right
so it's at some point you have to login
presumably I'd know so you've actually
when you set up that whole first step
when you actually set up a CS and
kubernetes you connect cube CTL there to
make sure that those two are connected
so you've already done the login there
all right and that connection so here
because I've already logged in it knows
what dashboard I want to access ok so if
I look here at my deployments you can
see that
had a sequel data for WCF I have a shot
modernize WCF and those are this WCF
service and the sequel server container
like we talked about and those are
containers those are deployments though
so that was in deployments so remember I
talked about pods which is the
containers so we have one pod for each
of them right now because we've only
just done one for each of them and then
we have services and so here's actually
where you can see the external endpoints
so this page is really useful so
actually for my WCF service I can go
visit this endpoint and I can say hey
this is that catalog service that I was
trying to reference before you can see
that is WCF service running in Azure
mm-hmm orchestrated by kubernetes
correct all right exactly so I can take
this IP just like we did before and head
back to visual studio yeah and remember
our app config file is where that
endpoint address was before specifying
where your the services you can plug in
this new service and restart this
WinForms application and when this
starts this is actually going to be the
WinForms application talking to the WCF
service and the sequel server that are
running in the cloud so we've gone from
making it from local containers on your
machine to actually running it in the
club cool now I think we might have
talked about this last time but it's
always worth revisiting I've done
similar demos of modernizing you know
take a wind former WPF app talking to
WCF talking to sequel server and I've
taken the sequel server database and
migrated it to sequel Azure yes that
sequel server running in Azure which is
yes and then I took the WCF service and
I plugged published it to a web app
mm-hmm or slash website running in Azure
and then the clients still sitting on
the desktop is talking to the server's
talking to this to the server to the
data up in the cloud
mm-hm
which is exactly the same thing we're
doing here although we've done it
through containers of orchestrators so
when how when do I do which because the
first yeah the easier route is easier
these are is easier I think I mean the
key is dependencies same so a lot of the
times you have dependencies that are you
need to kind of bake into running your
application and the container is gonna
host all of that for you which makes it
really easy so you don't have to think
about like oh is my like is it updated
do I have all the right things installed
here things worked in development but is
it gonna work in production all those
worries about whether it's gonna work or
not or whether you have all the right
things installed right it's taken care
of with containers because that's like a
full environment in itself
the other cool thing is scaling yeah
right so it's super easy to scale now
and I can scale out these containers
with just a couple clicks so if I
actually go back to the kubernetes
dashboard here and go back to my
deployments and say I want to scale out
this WCF service right now I only have
that one pod running what I have to do
is click say scale and say okay now I
want five pots and say okay and now you
can see one out of five pods have been
created so if I go to my pods here it's
working on creating those other four
pods okay that was super easy yeah all
right so all I had to do is go to my
kubernetes dashboard and say scale it
out right easy so I think that's a big
benefit of using an Orchestrator as well
right okay so I think that's kind of
kind of good answer to the question is
if you're just gonna stick it in a
container and just run it you know you
could do it either way but if it's gonna
stick in any container just run it
you're really not necessarily taking
advantage of all the stuff that
containers does right the when you get
the orchestrators and have the
flexibility to manage them and have
failover and you've got five pods
running if one goes down there's four
others run
yep not miss a beat or you could easily
increase so if you're doing like ticket
sales or something right tickets go on
sale at 10:00 a.m. so you know that
between 955 and 1030 there's a gigantic
spike I trap the house when you saw the
bulk of your tickets you don't want to
go down yeah that's a great situation
and there's 1030 when the concert sold
out right you can just scale it back to
you know maybe two three because they're
stragglers and by 11 o'clock scale it
back to long yeah really easily okay
yeah I mean it was just a couple clicks
and it does automatically for you um
which is really nice cool and then it's
also really important if you have my
courses like we were talking about
before and you have so many different
things to manage and you can load
balanced kubernetes will take care of
all the load balancing for you so that
you have to so it's running in as you're
so obviously we're charging for Azure
use kubernetes charging for any of this
no it's free open source kubernetes is
actually pretty awesome like that so
it's from Google okay I mean it's an
open source project okay yes cool all
right
so asher is the only thing that's
charging you here writing there
excellent and that's actually about it
all right
we've taken you from your existing dinah
application running on Prem locally to
adding containers running that locally
and now we actually have it running in
the cloud cool and then the repo you
showed that you shop contains yes
there's exactly khaliv walkthroughs on
how to do a lot of this stuff we will
write people to those please do yeah
exactly so the dotnet architecture repo
on github has this a shotgun containers
and this really has so many samples and
walkthroughs on how to do this step by
step and if you want more detailed if
you prefer ebooks you can actually visit
our architecture page on the dotnet site
and this will tell you give you books
that you can download it will refer you
to those same samples and you can
explore kind of micro services or
modernizing dotnet apps is really what
we talked about in this demo cool or
other things all right excellent
awesome
like I said early we've done a fair
amount of containers stuff on the show
we'll probably put it aside for a while
and go do some other stuff but I
hopefully these last couple episodes if
you weren't that familiar with it before
I've given you some good ideas on how to
get started doing this we've really
again focused on the existing
applications yeah they're the smart
hotel 360 is cool but it's kind of a the
new modern thing you've got dotnet core
services and Java services and again if
you've got existing web forms and wind
forms and WPF apps and WCF services
containers is also for you
exactly thanks so much thank you all
right we will see you next time on
visual studio toolbox
[Music]
you

Convert VS Code themes to Visual Studio

in this video we're going to convert a
vs code color theme to visual studio in
a few easy
steps we start in vs code by making sure
that the theme we want to export is also
the one that's
active then using the command pallet
we're going to invoke the command for
generating a color theme from the
current
settings that will generate a huge Json
file with all the color Tok tokens from
the theme so all we have to do now is to
save it on
disk back in Visual Studio 20122 we're
going to create a new extension project
I'm going to search for V6 and select
the empty V6 project
template let's call this project my
theme in the project I can now add an
existing item and in the dialogue select
to show all files so we can see the new
Json C file that we exported from vs
code
that brings it into my project and I can
now right click and say convert to
visual studio
theme it will produce a code behind file
a package St this is the visual studio
theme file format and all I have to do
now is to register it with the V6
manifest so I'm going to open that file
and click the assets Tab and select a
new vs package then point to a file on
the file system and notice how it
already suggest the package that file
that was generated for
me I can now test by hitting F5 to open
a new instance of Visual
Studio when I go to the tools menu I
should be able to see my new theme show
up and clicking that will select it and
show it right
here this works for any vs code color
theme all you have to do is to install
the vs code theme converter extension
into Visual Studio that enables the
conversion of the Json C color theme
file into the package def
file this is what makes it all so easy
you can get that extension for free at
the visual studio Marketplace

Cool features in Visual Studio 2022

Hello everybody and welcome to this video where I 
want to go through some of my favorite things in  
Visual Studio 2022. My name is Mads Kristensen and 
I work on Visual Studio and I have for the past 12  
years and I just want to share some of my favorite 
things, because I think that there's something  
here that you might not be aware of that will make 
you more productive and more happy as a developer  
I want to go through a bunch of new features 
some updates some tweaks to existing features  
that kind of just makes it all feel a lot 
better to be a developer when we're using 
Visual Studio. But before we dive in where I 
want to begin is with the new kind of reality  
in the way we work right. A lot of people have 
gone back to the offices but a lot of people  
have not and then there are people that are 
sometimes in the office and sometimes at home  
And when we have environments like this 
we tend to move between different screen  
resolutions and different monitor setups. 
So, for instance even though when I'm at  
home sometimes I take my laptop out of the 
docking station here and I sit in the couch  
and I do a little work from there. In that 
situation, I just have a small little screen  
but when I'm up at my desk like I am here 
I have a one of these ultra-wide monitors,  
so that's a completely different layout right 
and when I go to the office I will I might  
have multi-monitors and, so I want to make sure 
that no matter where I am where I'm plugged in  
what screen setup I've got Visual Studio is 
always in an optimal condition to allow me  
to do my best work and so let's take a look at 
some of the cool things that we can do with that  
So, here I have visual studio and you know and 
I have my various different windows like the  
Toolbox and I have the Solution Explorer out on 
the right side here and this works well for this  
particular monitor with this resolution that 
I'm using right now when I'm sitting with my  
laptop I want more of a kind of a minimal layout 
like this so in this situation I have a small  
screen so I don't want all these tool windows 
to show up I need that extra space to code  
and I actually also have a kind of a 
separate thing is when I work on extensions
I like my layout to be a little bit different 
so I write extensions for Visual Studio and  
when I do that, I always want like the errorless 
to be visible like you see here, and I show a third  
tool window over here by the Solution Explorer  
but that's only relevant for when I do that 
if I work with websites I might have other  
requirements different tool windows like the 
Task Runner Explorer or other things that I  
want to have shown that I otherwise don't 
need and then when I'm at my ultra-wide  
I really like to spread out horizontally over 
that big area and so it will look something  
like this now this doesn't look very good 
on this monitor and this screen resolution  
that I'm using right here but maybe you can get 
the idea how I can like spread out horizontally
Let's go back here so let's say you have dual 
monitors you could actually take the different  
tool windows in Visual Studio and spread 
out on these various different monitors  
so I don't have that here for this 
video so we'll have to pretend  
So, let's open a window here. A 
tool window - the Test Explorer  
and let's imagine that I take this and I drag 
that onto my secondary monitor okay and maybe  
I'll make it full screen or make it really 
big so I can easily see all my unit tests
All I have to do to save that windows layout 
so I can easily come back and forth to it  
is to go to window it's a save window layout and 
then we give it a name let's call it "testing"  
and that's it so now I saved this layout 
if I go back up to window you can see that  
I have all of my saved window layouts 
right here and I can apply any of them  
For instance, we can go to this one and 
then back to the one we just created  
"Testing". And I can do that with keyboard 
shortcuts to make that very very easy and fast  
So, this is super helpful I use this every day all 
the time as I move between different development  
scenarios but also different monitor setups so I 
can't recommend this high enough go check that out  
it was a feature we were introducing 
in Visual Studio 2019 and we've been  
improving it uh as time has gone by so 
super life saver for this new world a new  
situation with dual monitors and oh sorry 
multi-monitors for different locations
All right, so here's another thing. I have my 
code base here I got a bunch of files open  
but I can't really see how many how many 
files do I have open and it you know I don't  
really know I can only see what whatever my screen 
resolution allows me to see how wide the screen is  
and that's why we always have had this 
little thing up here you can click next to the  
the tabs and if you click that, now notice how 
you can see the list of open files  
There are some that are grayed out and italics.
Those are the ones that are not visible right now  
And then we have the ones that just look 
kind of normal. Those are the ones you see  
on the screen. And the one in bold 
is the one that's currently active  
So, that makes it really easy for me to get a 
picture of what's open and where can I find things  
But you know, sometimes I kind of just want to see 
everything all the time all the open documents  
So, if I go to the settings icon I can 
now click "Show tabs in multiple rows" 
and what's really nice here is that if you have 
the screen real-estate - if you have the vertical  
space, you can now stack all these tabs so you 
can see everything that's open. Very very handy
But there are some monitors that are you know 
have you know that are extra wide for instance  
and in those it would be kind 
of nice if we can take our  
tabs and instead of having them on top then 
move them to the side where we have more space  
So again, go into the settings and 
click on "Place tabs on the left"
So, it's really nice I can resize 
this to whatever. I want to make it fit exactly  
my monitor here right so what I'm doing here is 
I'm getting that extra vertical space. I can now  
see maybe a couple lines more of code in the 
editor because I moved the tabs to the side
But let's see what else we can do here because I 
have all these open documents and you can see by  
default, it's actually kind of nice they are sorted 
by the project they belong to, so my solution has  
multiple projects and they're all listed under 
each of those projects. That's very nice I don't  
have to sort that or, sorry, group by project. I 
don't have to do any grouping at all, but I really  
like that so now it's just alphabetically sorted. 
But I want it to be group by project like here
And if we
take it one step further here what if 
we colorize these documents per project  
So, now each tab has the same color if 
it belongs to the same project and that  
makes it even easier for me to kind of 
at a glance see where these files belong  
If we don't want it per project because 
I already group my tabs for project here  
Instead, we could do it by file extension so 
that's also very handy, so I can see all my Razor  
files, all my C# files, all my JavaScript 
files. They all have a separate color so  
it makes it easier for me to get that overview and 
that might be exactly what you'd like to do here  
And as a new thing we can also go in and 
say, let's do it by regular expression and  
let's configure the regular expressions. So, it's 
a file here that opens up and I can start typing  
I'm just going to copy that line up 
from above and let's say we want to do  
CSS and as soon as I save the file we can see 
the CSS file has now got updated with a color  
we have Razor I want to have something specific 
here and we can even take it further we can say  
you know everything that contains the 
word um you know category let's say  
so like something like this foreign so not all 
everything that has the word or c-a-t-e-g will  
be colorized so you can do that by folder 
you can do that by file name and all these  
things so you can really customize how you 
colorize these tabs it's pretty phenomenal
And, of course, if you move uh back up and use 
the tabs on the top they maintain their colors  
so that's really really nice so let's go back 
to per project I kind of like to do per project  
when I have the tabs up top and that um because in 
this case they're not grouped by a project and so  
having them colorized by project is my preference 
yours might be different but I really enjoy this
So, colors can be very very helpful to us when 
it helps us kind of identify the different files  
and so on but there's another thing where 
I feel a color is a big deal and it has  
to do with us sitting in Visual Studio using 
visual studio for you know eight hours a day  
10 hours a day sometimes five days a week 
right. This is this is home away from home  
and just like you do with your regular home you 
want to have a certain furniture you put in your  
house right you have uh what colors do you want 
your walls and so on you want to make it yours you  
want to make it feel like a place where you're 
comfortable and visual studio is no different  
so what's really cool now in in Visual Studio 
2022 is that we have made it such that you can  
take any visuals any Visual Studio Code, VS Code 
color theme and convert that to a Visual Studio  
color theme very easily and there's a bunch of 
these available out on the extension Marketplace  
and I want to just show you a few right here so go 
to tools theme and you can choose from any of the  
themes that you've got installed of course you 
get some out of the box with Visual Studio you  
can choose from and you can always go 
and say click for get more themes and  
that will get you to the Marketplace where 
you can install all these different themes  
and they're fantastic there's so many great 
ones in here and they really help us if we  
want a nice dark theme if we're sitting in a 
dark room for instance and we can even have  
Visual Studio changed the theme automatically 
when Windows changes its theme there is this  
thing here called use system setting and when we 
do that if Windows is running in a dark theme at  
night for instance after sunset Visual Studio 
will automatically switch to the dark theme at  
that point in time and back to the light theme at 
Sunrise if that's your Windows settings right so  
that's really really cool so a whole lot of colors 
that makes our lives better in Visual Studio 2022
but let's change that back 
to the blue theme for now
and I'm gonna change to a different  
project here so here's a just a very simple 
.NET console app and I want to show you some  
cool things and improvements we've done to the 
AI-based coding assistant in in Visual Studio
so I'm gonna type a new line here oh  
and notice how Visual Studio automatically 
will suggest that I put in a last name which is  
exactly what I want in this case I want the last 
name property to be inserted for me right here  
I also want the full name so let's hit 
enter again and this time it suggests age  
which is could be could be the accurate one but 
I want full name so I'm just going to pretend  
it's not showing me anything and just start 
typing public string full name and notice here  
I can just hit tab and I get my full name and 
it understands that full name is a product of  
first name and last name this is really really 
fantastic so the AI engine here in Visual Studio  
understands the context I'm in it understands 
that I'm right under the first name property  
chances are that I might want another property is 
relatively big and based on the name it also then  
first name it then also suggests hey the last 
name is usually what other people will add when  
they you know as the next logical property but 
what I was really impressed by was the full name  
that it understands what a full name is right 
it understands that when people have a first  
name and a last name and they need a full name 
this is what they want absolutely fantastic here
Let's scroll down and you can see here 
I have a method here called remove data  
and all it does it removes some data from 
the list that I have defined above it  
so what's missing here is a method for adding 
data so again I'm going to hit enter and  
Visual Studio already knows what I'm gonna do 
here. I'm going to create an "AddData" method  
so notice that based on the name remove data you 
know it understands what remove means and add  
and so it suggests that I created a method 
called "Add" but what was crazy was that it  
knew what that would do inside the method 
right so it knew that it should not take  
the list and remove something it should add to 
that list so this is just absolutely fantastic  
here I'm just coding by tapping enter and hit 
hitting the tab key here it's absolutely great  
and we can take it a step further so let's say 
that I want to create a new method or I want  
some code but I'm not entirely sure how I should 
write it what I can do is that I can express it  
in a code comment like this one so here I have 
a comment it says take the two arguments and add  
them together so the args refers to the args 
that come into the to the main method up here  
so I'm just writing here in plain English what it  
is that I would like to have 
happen and now I can hit enter
and Visual Studio will automatically 
suggest what that code might look like  
so it understands what I'm saying in English 
in the code comment and can translate that  
into something that is might be what I 
want so this is absolutely fantastic so  
this is the AI engine that is built upon a huge 
data set and using machine learning it's able to  
take the context that the AI engine is aware of 
and pair that up with the big machine learning  
model of what do people do in situations like 
this that's basically what the machine learning  
model knows and when we pair those up together 
Visual Studio can do amazing things like this
so um a big step forward for the AI 
engine here in Visual Studio 2022  
now let's call our new method here the "AddData"
"AddData" and we're just going to give it
some string what are we going to call 
it we're going to call it just one  
here and I'm gonna just duplicate the 
line Ctrl+D duplicates the line like this
and then we can I'm using an extension here called 
Shifter that lets me change integers and other  
things by keyboard shortcut here Ctrl+Alt+Up/Down 
and so now I can fill my list here with data  
now let's set a breakpoint and I'm going to 
set a specific type of breakpoint this is a  
new type of breakpoint temporary breakpoint so 
what's really nice about a temporary breakpoint  
is that it disappears as soon as the debugger 
hits the breakpoint so let's run this console up
so here it runs and it comes down here and you 
see the breakpoint is now gone right the break  
point is gone because it was temporary it only 
hits once so let's stop debugging here and um  
let's scroll up so here on line 18 I'm making 
a method call into a nougat package called  
Newtonsoft JSON and I don't really know what's 
going on inside the method called serialize object  
I might be able to find the source code 
somewhere on GitHub and then go figure it out  
but it would be really nice if there's a way for 
me to just go straight to the definition hit F12  
and go to definition so let's try that and it 
takes me straight to the source so this is not  
um disassembly or anything like that this is the 
actual source code using something called Source  
Link all NuGet packages can opt in to Source Link 
and that will allow Visual Studio to understand  
how to get to the actual source code that made 
up this particular version of this NuGet package  
and even when you're inside these files you 
can keep hitting F12 you know go definition  
until we come down here and it's a serialized 
object internal and this is a private string  
so I'm F12 and I'm going to definition 
through a file that made up the NuGet  
packets that I'm working on and I can see 
everything that's happening super helpful
all right I want to switch over to uh  
different project and I'm going to open it 
here it's the one I had opened just before  
notice how how when I open it up here all the 
files that were opened before are now open again  
and in my Solution Explorer I can see 
that all my folders and projects have  
all been expanded to the same levels that 
they were last time I used this project  
and that's all good that means that I 
can get right back into where I left off  
but very often this is not what I want very often 
I come in I open the project in the morning to  
start working on something and I don't want sort 
of yesterday's state to be expanded into Visual  
Studio I want something clean I want something 
fresh I want that fresh car smell in the morning  
right I come in I just want none of this open 
but I want to be able to open my app and work  
with it so I'm going to show you a couple 
of settings that are really really helpful  
so if you go to Tools > Options and then go to 
Projects and Solutions there are two check boxes  
that are really good to uncheck here if you're 
if you're someone like me that likes that fresh  
car smell so "Reopen documents on solution 
load" I'm going to uncheck that and "Restore  
Solution Explorer project hierarchy state on 
solution load" I'm going to uncheck that as well  
so now let's go back to the previous 
console lab here we can see that
the document was not open and the demo console 
project over here is collapsed it's not expanded  
so now let's open this project again that 
we had before I'm going to switch again  
and first of all I don't know if you notice this 
but it's instant the loading of these projects  
are now instant because no other files have to 
be opened no state had to be read from disk and  
hydrated into memory and applied on the UI thread 
in Visual Studio to expand all the tree notes  
in Solution Explorer none of that was necessary 
when you open a file let's say you open a C# file  
if it's the first time you open a C# file in 
that instance of Visual Studio that you've got  
open then it has to boot up all of Roslyn and 
everything to get IntelliSense and colorization  
and all of that working and that's called a 
language service and a language service can  
sometimes take a little while to load 
now it's not necessarily a long time  
but it's not instant like it is if we don't 
need it and we do like I do here so this is  
my default this is what I always do just a little 
performance trick if you like the fresh car smell  
come on all right I'm going to show you a 
one of my favorite new features that we are  
putting into Visual Studio this one started its 
life as a an extension and it's now coming into  
visual studio so let me let me demonstrate 
that so let's say I want to add a file to  
my project you know I can right click go down to 
add and new item and that gives me this dialogue  
but what if I go in to Tools > Options 
here and click a preview feature flag here
and what I want to search for is here enable 
quick add okay so now when I right click and  
say add new item or kick Ctrl+Shift+A is the 
same thing I get this little dialog up instead  
so I can still click on this link that's shown 
as well that says show all templates which gives  
me that experience that I'm used to but I want to 
get the simplified view we call it the quick add  
dialog and so in here I can just 
type a file name so a name .cs  
and that's what it does it just gives 
me the internal class and this actually  
respects if I have how I how my namespace 
rules are in my editor config or in my  
settings and it will do the right thing 
it uses the templates behind the scenes
but it's a little bit more clever than that so 
control shift a again for add new item to bring  
it back up let's type something a little bit 
more interesting let's what if we create two  
files what if I create a Client.cs and IClient.cs 
now let's try that I just comma separated them  
and I now have those two files but check this 
out IClient is an interface whereas Client is a  
class so the quick add method or dialog is able 
to understand that I client that pattern naming  
pattern should match an interface template and 
then give me that so that's really really handy
but I can also click create folders so 
I'm going to create a folder here called  
"folder" and you can name it whatever you want 
and just end it with a forward slash hit enter  
and now you have an empty folder I could 
also have gone in and said okay let's do  
what if I do some sub directories here 
and then end with a file - file.css
so I can create subfolders I can create 
files in those folders again I can comma  
separate these to create multiples really 
really handy to have all this working  
so this is in the preview behind a feature flag 
so you saw how I went into Tools > Options under  
Preview Features and enabled this feature so I 
can't recommend this highly enough I love this  
thing I use the extension and for years and 
I'm very happy that this is now in the box
So ,now that we have a CSS file open 
let's write some CSS. Let's do background  
let's do blue and let's do set 
index you know three four something  
all right so I'm going to show you an extension 
here called Shifter it allows me to flip between  
values in the editor really really easily let 
me demonstrate so I have a keyboard shortcut  
here Ctrl+Alt and then either the Up Arrow 
or Down Arrow and so if I'm on a number here  
like the z-index and hit up Ctrl+Alt+Up it 
increments the number like this if it was a
I say 0.08 here you see it will know to keep those 
values depending on the decimals and all this sort  
of stuff so really really handy if you just need 
to like increment by one or something like that  
but we can do more it doesn't have 
to be just numbers it could also  
be colors so here's the color blue so 
if I do Ctrl+Alt+Up I get Royal Blue,  
Dodger Blue you see here it gets lighter and 
lighter the color gets lighter and lighter  
and lighter and then it gets darker if I go down 
Dark Blue and so on so forth so I can flip through  
these very easily I can do the same if if we 
have a let's see here let's grab a color here  
with the color picker that color right there 
so if I have a hex value like this I can do  
the same and it understands what hex is and it 
knows it's a color in this case and so it will  
make the color darker or lighter as I either 
go up or down with the keyboard shortcuts
so I'm just going to write some invalid 
CSS here we can do other things like  
switch between true and 
false or you know yes and no  
or on off and so on and so forth right so so every 
time we can toggle between kind of known values  
shifter comes in and makes that super 
easy for us Ctrl+Alt+Up and down
so let me pin the upper window here let me build 
our project now notice what's going on down here  
in the output window I'm 
getting a very nice colorized  
output here because I'm using an 
extension that colorizes everything  
which is really nice something is green or gray 
means like it's fine there's no no problem but  
let's introduce a syntax error let's forget all 
right let's delete this semicolon and run again  
so now yeah we get an error in the error list 
but we also see that our output is now red  
because there was an error so it makes 
the output window really really easy to  
kind of just glance over or skim and 
you can see if you have anything red  
or anything orange if it's like a warning and 
that's just really really helpful so there's  
a bunch of these extensions out there that you 
can use the one I use is called VSColorOutput,  
VSColorOutput so go check that out 
really really handy thing to have
and the last extension I want to show you  
is compile again is one called 
Solution Colors so you may have  
the issue where you have multiple instances of 
Visual Studio open and how can you tell them  
apart they all look the same what if it's the same 
repo you have open in both but different branches  
now they look almost identical the solution 
names are the same all the all the files in  
Solution Explorer are the same how do you tell the 
difference between open instances of Visual Studio  
well what we can do with Solution Color 
is that we can right click the solution  
and set a color so I can give it any color I 
want or I can enable auto mode so auto mode  
basically takes the solution path and the branch 
name and other things and makes like a unique  
color that it will always map to that same color 
so if if I now open another Visual Studio here
we can see here it will apply a color as the 
solution is low to see this one turns blue  
you can see the blue color up here and the other 
one got the magenta color or pink right up there  
now I can go in here and go to options 
and make it a little bit more visible  
I can go and say instead of just colorizing 
up here the up there and it also puts a line  
at the bottom of the screen you know maybe I 
want a little bit extra maybe I want it on the  
let's hear let's look at the borders instead 
of just the bottom what if I wanted at the top  
as well so I'm gonna go ahead and do that 
and so now I have a thing here at the top  
this is very very cool because 
now I can very very easily see  
that this is the you know I have a 
magenta one I have a blue one and so on  
and I can even tell by hovering down in the 
taskbar those colors are also present here  
under each of the thumbnails in the
Windows task bar
and if I don't like magenta I don't 
have to have the even though we have  
auto mode is on I can always say no 
no I want you know give me a burgundy  
and I can keep that color and all all other 
solutions will still have the automatic one  
except for the ones that I manually said hey no 
no I want to specify the exact color for this  
particular solution and of course I can also hit 
the custom one and then select any color you know  
RGB color that I can find here so or that that 
exists rather so you can be really really specific  
here and it stores it um in the .vs folder at the 
solution root so it's not something you want to  
check into source control you can but it's not by 
default so this is just a personal setting to you  
having you having put colors on yours does not 
change the colors that your team members might  
have chosen for theirs or if they don't want 
any colors that doesn't make any difference  
either because they're kind of 
just local to you your machine
so this is called Solution Colors - Solution 
Colors so throughout this whole demo you  
probably didn't notice because there's no way 
to tell that I've been working inside a VM  
but not just any VM or virtual machine I've been 
working inside a Dev Box a Microsoft Dev Box and  
just you can tell there's really no way to tell 
this is just Visual Studio running you can run  
with any other app that I have installed that 
I need to have installed to make my uh make me  
able to work on the project I'm working on right 
so it's it's just another VM but it's hosted in  
the cloud and it's super powerful so if I go to 
devbox.microsoft.com this is where I have access  
to my Dev Boxes and this is where my it department 
has given me the opportunity to create new  
Dev Boxes that I can connect to so I have two here 
I got Legacy and I got Podcast those are two and  
they're pretty powerful uh eight core 32 gigs of 
RAM and a terabyte of SSD very fast SSD drives  
so depending on your workload you may want 
to have a super-fast powerful machine or  
if you wanna if you have a lighter 
workload you can go sort of smaller  
and it's very easy to create a new one so anyone 
can just come in here say hey I want to start  
on a new project I want a clean machine and you 
just set it up very very easily from this website  
so it's a very very cool technology it makes sure 
that your Windows is always up to date and the  
latest patches it's kind of a managed thing 
your IT department can manage all these Dev  
Boxes the way they can also manage your own you 
know physical workstation or laptops um to always  
keep them secure compliant up to date connect 
them back to your network have all those things
um so that you won't even notice that you're on 
a VM and the first time I tried this I was I I  
will admit I was a little bit skeptical 
but I signed in for the first time and  
OneDrive started synchronizing my files so all of 
a sudden I had all my files everything was there  
all the images and all these different things 
that I have on my Desktop and you know in the  
My Documents and whatnot it was all there and the 
image came pre-installed with Visual Studio and a  
bunch of other tools that I needed so I could just 
get to work immediately and it really didn't feel  
like it was like a a VM that was hosted in the 
cloud or anything like that it felt just like  
another one of my machines and um I'm very excited 
for this I have I have a specific specific use  
case uh which is you know Visual Studio sometimes 
can use a lot of uh resources when you compile  
all the time and run debug and all that sort 
of stuff it takes a lot of resources we want  
it to take a lot of resources right we wanted to 
compile as fast as possible we don't want to sit  
and wait so we wanted to use be able to use all 
the resources that we've got now the problem with  
that is that it for me I have a laptop and it kind 
of drains the battery so I can't use Visual Studio  
on battery on my laptop for very long but with 
Dev Box I can I can go all day long because I  
don't do any of that heavy lifting locally on 
my laptop it all takes place in the cloud with  
much beefier hardware than what I've got in my 
laptop so I get a much faster experience and I  
get battery that lasts all day it's perfect so is 
it public preview you can go ahead and try it out  
um I encourage her to do that I think it would 
be fantastic and um there's a whole admin story  
for your it admin you may want to uh talk to 
them about it as well because there's a whole  
opportunity for them to make this secure and 
compliant and all this sort of stuff making sure  
that you don't spin anything up uh that they don't 
think you should and um it's so it's a win-win  
it's a win for the developer and it's a win for it 
you really get that flexibility that productivity  
that and get all the hardware you need when you 
need it so um go check out Dev Box - Microsoft 
Dev Box and that was it for this uh 
brief video of me going through some  
of my favorite features in Visual Studio 2022 
new features are added all the time so make  
sure you go check it out uh install the latest 
version and try it out for yourself thank you