>> Hey everyone, I'm Leslie Richardson from
the Visual Studio Extensibility team and welcome to this talk
on what's new for both existing and
aspiring extension developers in Visual Studio 2022.
VS 2022 is super exciting,
there are a lot of major updates to it,
including 64-bit,
which can help improve performance across the board,
and there have never been more ways to
customize your ideal development environment with addition,
such as colored tabs or themes or
just all the new GitHub integrations
than there have been in this version.
But for a lot of people creating
that ideal development environment is
not complete without the extensions
that they've come to know and love,
and that's where you-all fit in as extension authors.
The goal for this talk is to share with
you some steps for how to successfully migrate
your extension to Visual Studio
2022 so that everyone can continue taking
advantage of all the awesome productivity and
customization add-ons that your extension offers,
while also introducing a new toolkit that can help you
write your extensions even faster and easier than before.
Let's check it out. Migration is
the first and probably most important topic
that we'll be discussing today.
In order for your extensions to
continue being used in Visual Studio 2022,
you're going to have to follow a couple of
migration steps that we're going to demonstrate today.
I am currently in Visual Studio 2022 and I've got
this 2019 extension that I've written that
I'd like to migrate to VS 2022.
After doing all my modernization updates,
so making sure that my.NET Framework is
still compatible with Visual Studio 2022,
as well as any other package references,
we can get into the core of migration,
which comes down to creating two separate VSIXs.
You want to create two projects,
one that targets Visual Studio 2019 and lower,
and the other one that is targeting Visual Studio 2022.
Both of these VSIX projects are going to be tied
together by what's called a shared project,
which allows us to share
code that's going to be similar between the two versions.
The reason why we are setting up
the extension in this way when migrating is because we
need to address all of the breaking API changes and
interrupt assembly changes that have
happened in the transition to 2022,
of which there are a lot of,
especially with the addition of 64-bits.
In order to make sure that
certain assembly references work
and one version but not the other,
then we can use the shared project setup
to differentiate between the two fairly easily.
I've got my 2019 targeting project
and the first thing that I'm going to
do is just add my shared project to the solution.
Create a new project.
Go into shared. I'm going to call mine AddAuthor_Shared.
There's my shared project.
Of course, we need to include a reference to
that project and the 2019 product.
Let's go to reference, add that.
Now the question becomes what goes in this shared project?
Usually most of your CS and RESX files are fair game,
anything you intend to share between
both versions of your extension,
specifically your commands, your tool
windows, that sort of
thing and that's what I'm going to add in mine.
As for what not to add to this shared folder,
you don't want to add your VSET file,
but you do want to make sure that your build action under
properties is set to VSET compile.
There you go. You want to make sure that
you're including VSIX property is set to false.
Similarly, you also don't want to move your VSIX manifests,
which we're going to play around with in a second.
We've got the VS2019 projects
set up and we have the shared folder or the shared project,
and now we're going to add the VS2022 project,
which I've already setup.
I'm going to add an existing project, let me go find that.
Great. There is our VS2022 project
and there's a couple things that we need to address here
in order to actually get this extension to run properly in VS2022.
The first theme,
let's add a reference to that shared project like we did with
the 2019 one. There it is.
Then we need to make sure that we
have our NuGet packages updated,
specifically the SDK and the build tools ones.
You want them to target a 17.0 version of Visual Studio and
this is what will allow us to continue using
the extension libraries and APIs and Visual Studio 2022.
From there, we're going to modify our VSIX manifest.
I'm going to open up the code version because we're going to
add a different tag manually.
First and foremost, make sure that your installation target is
set to 17.0 to 18.0.
Then inside your installation target,
we're going to add a new tag called product architecture.
This is like the money shot right here.
This is something that you have to make sure
that you have, otherwise,
your users won't be able to
install your extension in
Visual Studio 2022, and we don't want that.
We're going to add 64,
and this is accounting for the fact that Visual Studio is 64-bit,
therefore your extension needs to be compatible with 64-bit VS.
Also make sure you update your prerequisites
to go to 17.0, 218.0 as well.
From there, we've updated our manifest,
we've updated our NuGet packages,
and before you hit "Run", stop,
do not passcode, do not collect $200 because we need to
address those breaking API changes
that have happened in that transition.
Luckily, even though there's a lot of them,
we have provided a lot of resources with
the list of all the different APIs that have changed,
have been broken or have been moved,
as well as solutions for how to fix them.
In my case, my issue is going to deal with
this DTE and _DTE type cast failure.
I bet it would be addressed if I just change my namespace to
the latest EnvDTE AD namespace instead.
Going into my code,
specifically this issue is going to take place
in one of my shared files.
You'll notice that I get an error.
But if I'm looking at the Visual Studio 2019 version
of this shared file,
it's not giving me an error when I use this definition.
But if I were to swap over to VS 2022,
then it is going to give me the error.
We can just fix this by changing to EnvDTE80.
From there, we should be good to go and
give this a try and see if
the extension has successfully been migrated.
I'm going set that project as my start-up and hit run.
Depending on the complexity or the size of your extension,
you may have to address a lot of
breaking changes or you might
get lucky and not have to address any.
Keep in mind, please double-check them either way just
to make sure that it's going to work right for all the users.
I've got this random project open,
and this is a very basic extension that is supposed to write
my name as a comment in the doc of my choice.
I'm going to go to Edit.
That's a good sign, there's my command right there.
I'm going to add my author name to the file, and there we go.
We successfully migrated this extension.
Awesome. Basically the core in summary of
migrating consist of two separate VSIX projects
tied together by a shared project.
Make sure you update your manifest,
especially that product architecture tag
that you'll need to include for 64-bit.
Last but certainly not least,
make sure that you are addressing
any breaking API changes that might have occurred.
We just finished migrating,
but I'm not as happy as I could be because honestly,
the time it took me to write
that extension was a bit longer than I expected
because something as seemingly simple as
writing text to a text buffer to a document,
turned out it was actually really
hard to find in a document or online,
and then once I finally did find that information,
I needed to learn up on several different APIs,
which took a long time.
If you've ever been in
that situation where it's taking a long time just to get
started applying all of
your great extension ideas and implementing them,
then we are addressing that by introducing
a new toolkit called the Visual Studio Community Toolkit.
Emphasis on community here.
This is a completely open-source,
community-driven project that has the goal of
writing your extensions easier by providing helpful templates,
helper methods, and API wrappers.
My personal favorite visual and textual IntelliSense additions
to a lot of the common APIs.
We're also providing more descriptive and accurate documentation
with more examples than ever.
Also, the end game of this toolkit is to provide
a smoother transition into the outer process extensibility model,
which is still a work in progress,
but it's coming very soon,
and that model has the goal of also writing
your extensions easier while
also making them more secure and more reliable.
As an experiment, let's try to write that same extension
using the Community Toolkit in order to see the differences.
I'm back in VS 2022 and I've already got my project open,
that I want to use with the Community Toolkit.
I actually used one of the templates that this toolkit gave me,
which provided me by default with
a commands folder and my commands file,
as well as the VSAT file, which is great.
If you want to get started using this toolkit,
make sure that you
have Extensibility Essentials 2022 pack installed.
This is a pack that consists of multiple extensions such
as insert guide and image optimizer,
and just a lot of tools that help expedite some of
those everyday extensibility writing
tasks that you might experience.
From there, the first thing that I'm going to do is
define where I'd like my command to be placed.
By default, it's set in tools and you'll notice when I
hover over tools, this is awesome.
You get a visual representation in
IntelliSense of what that window looks like.
It's like a cheat sheet of here are
all the different possible locations where you can
place your extension in the Tools Window.
Really great if you're not as familiar with VS or
you're not as familiar with all the different IDE choices.
I'm going to change mine to Edit because
I'd like mine to go in the Edit window, there it is.
Again, if we compare and contrast,
we can go to that same location,
and you'll see that this is a lot less intuitive to understand.
There's a lot of ideas that look
like this that you may not really know what
corresponds to what off the top of your head
and require you to have a dock open at the same time.
It gives you less of an opportunity to
experiment and just test the waters of it.
We got that in place.
Then I think the most noticeable difference with
the toolkit comes when you open up your command file by default.
This is awesome.
It's only 11 lines versus if you go
into your version of the extension that doesn't use the toolkit.
There is a lot more going on that you need to consider addressing,
such as the initialized async function or service provider.
What is service provider?
I don't know, but you're going to have to learn up on it when
you get started writing your extensions.
If you want just a quick way to put down
all of your ideas in one spot and just see your extension
running that much faster than having the toolkit and place
to define the stuff that's most important to you is great.
In this case, the thing that's most important to me is defining
what my command is supposed to do once it gets triggered,
which is why execute an async is here by default.
I'd like to write that same comment,
in this case, my name to text buffer,
and as I mentioned before,
we have a lot of
great documentation for this ongoing toolkit project.
My personal favorite is the Tips and Tricks section,
which has a lot of very common scenarios that
occur when you're writing an extension
that you probably want to know about.
I'm going to copy paste this top one,
which will allow me to write text to the active text view.
We're going to add that in. I'm going to change this to my name,
and let's go ahead and hit "Run."
We're back with that same random console application that I
have and I'm just going to add my name to the top of it.
As you can see, I now have the toolkit version
of that extension command,
and there it is.
See how much simpler that was.
That was really quick just to put
that basic idea on paper and
have it out in world and action like that.
If you want to take advantage of that toolkit,
be sure to check out the Extensibility Essentials
extension downloaded and experiment.
Also, because this is open source and community-driven,
share your feedback and also get involved.
If you've got ideas that only your mind could come up with,
the possibilities are endless and you have the power to change it.
That concludes the talk on what's new
for extension developers in Visual Studio 2022.
We talked about migrations.
If you haven't migrated your extension
already and want to learn more,
be sure to check out the extension support link.
We also talked about the toolkit to
help make writing your extensions easier,
and if you want to learn more about how to get started with
that, go to vsixcookbook.com.
Last but not least, as I mentioned before,
that toolkit is going to be a transition into
the upcoming out-of-process extensibility model
designed to let you write your extensions easier,
help your extensions to be more reliable, and more secure.
If you'd like to learn more about that,
experiment with the initial bits, see samples,
and honestly just see
any more upcoming announcements in
the world of Visual Studio extensibility.
Be sure to check out the VS extensibility repo.
With that, thank you so much for watching,
and thank you so much for providing all of
your awesome extensibility ideas to
help users be more productive across Visual Studio.
Until next time, happy coding.