I had the opportunity to present at the DevTools Ecocsystem Summit held in Redmond between October 19 and 23. I had two presentations, the first with the title “Best Practices for Extending the IDE with a Focus on Performance”, and the second held in cooperation with Quan To with the title of “Deploying Visual Studio 2010 Extensions”.
After the presentations I decided to blog the presentations in a transcript-like way including demos with source code and screenshots.
This post is the first part of the “Extension Deployment” presentation held together with Quan.
[Quan] Good Aftenoon! Welcome to the Deploying Visual Studio 2010 Extensions session! I’m Quan To, a program manager on the Visual Studio Platform team. My partner for this talk is Istvan Novak, one of our VSX MVPs and an expert in extending Visual Studio.
I’ve spent 3 years as the Visual Studio Deployment Program Manager prior to joining the platform team and even though I know MSI pretty well, it’s still hard to deploy a VS extension!
There’s already a lot to know when building an extension. Why do you need to learn even more stuff and all the nuisances about deploying an extension? Everyone knows creating an MSI is hard. You need to learn MSI, buy install shield or spend some time learning Wix, then search for which registry keys you need to write for VS to find your extension, and hope everything works when you build your setup.
Setup is painful. Instead of having these experiences when deploying your extensions…
We want you to make you happy, happy, happy!
I’m going to hand things over to Istvan who is going to show you our cool new deployment and acquisition experience we built into VS 2010.
[Istvan] Good Afternoon! It is great to be here on this Summit and see that so many attendees cannot be seduced by the other track!
In this demo I will show you one of my favorite features in the new Visual Studio release, namely Extension Manager and the related user experience. I can easily access the Extension manager from the Tools menu or from the toolbar by clicking on this Tetris-like button.
When this window opens up you immediately see the extensions already installed that can be templates or tools. This time I have only the Power Commands tool installed. There are two nice tabs in the left pane. By clicking on the Online Gallery tab you start browsing the components available in Visual Studio Gallery. The list is created in a few seconds and when you select an item in it, the related description is displayed in the right pane.
Well, I’m searching for a tool that could help me in navigating through my source code files. Let’s try to search for the word “source” and look if I can find a tool like that…
There are many tools having the word “source” somewhere in their description… Here is one named Source Outliner! It’s description suggests that it may the tool I’m looking for! I click on the Download button and Extension manager immediately starts downloading the extension.
I Click on install signing I accept the licence agreement. The tool installs in a second, and appears in the Installed Extensions tab immediately.
As you can see from the message at the bottom of the dialog, installing a tool requires a Visual Studio restart. I do not want to go into details why this restart it is necessary, and please believe me, it is not because the VS team is lazy and simply did not want to implement some features to avoid the restart. This has more deep architecture reasons. Restarting VS is not painful. The IDE returns back to the state where you left it before, and also loads your recent solution. As you see it is quite quick.
Now, I can use the View|Other Windows|Source Outliner Power Toy command to display this tool. I “dogfood” it by opening its source and selecting the CodeOutlineFileManager.cs file for further examination. When I click a member in the tool window, the corresponding code is marked in the source file window.
I like this tool! If I did not like it, I could uninstall it from Extension Manager simply selecting this tool from the Installed Extensions tab, and clicking on Uninstall. Just as when I installed the tool, I have to restart Visual Studio to finish removing it.
I hope, now you can understand why it is one my favorite features.
[Quan] As Istvan mentioned, the backend to the Extension Manager is the Visual Studio Gallery. Some of you may know that we launched the Visual Studio Gallery back in VS 2008. In less than 2 years, we have over 1200 extensions on the gallery! As a side note, we surpassed our competition a month ago J
Some other notable changes we made to the gallery include moving to be a part of MSDN, the UI and navigation, we’ve improved the ratings and reviews, added things like notifications and statistics, and web services for the extension manager to talk to. The other big thing we now provide is a place to host your extension. Instead of just reference links, you now have the option to post your extension bits on the gallery.
I’m going to walk you through the Extension Manager architecture to show you the flow of an extension through the system.
We start with Visual Studio and the new Extension Manager service. This service will talk to the online gallery and handle downloading, installing, uninstalling, enabling, disabling, and querying of extensions.
Within Visual Studio, there are extension manager clients that talk to the Extension Manager Service. This includes the Extension Manager UI, the New Project Dialog, and even the Start Page talks to the extension manager.
The clients ask the extension manager for a list of extensions that can be downloaded and installed. The Extension manager queries the gallery and returns a list of extensions. The client then tells the extension manager which extension to install and the file gets downloaded onto the user’s machine. The extension then gets installed to a per user or per machine location.
The unit of deployment here is this purple box which we call a V-SIX or V.S.I.X.
The VSIX file is a renamed zip file. It’s our mechanism for packaging up an xcopy deployable extension. The VSIX contains two main parts, your payload and the manifest.
The VSIX manifest file contains three distinct parts. The first is the metadata about your extension including the name, company, version, license and icons. The second part allows you to declare dependencies on other VSIX files. If those aren’t installed on the machine, you won’t be able to install your VSIX. We also have a notion of nested VSIXes which means you can carry your dependency in your payload and have that installed first.
The third part is the content section which specifies the key content parts of your extension.
For VS 2010, we support several types of content. These include VS Packages, MEF Components, Project and item Templates, and Toolbox Controls. We also support custom types so if you build your own extensibility points, your own customers can extend your extension. Our custom start pages inside VS is an example of a custom type.
Things that didn’t make it as a supported VSIX type in Dev 10 are Addins and Snippets. We are hoping to add those in a future release of VS.
Part 2>
Posted
Oct 20 2009, 08:28 PM
by
inovak