It can also be installed by downloading and double clicking on the file, and uninstalled either in the Extension Manager, or by simply deleting the associated files. You can find introductory information about VSIX here<\/a> and here<\/a>.<\/p>\n The VSIX feature comes with a lot of options. In most cases you don\u2019t have to understand them all. This post is a list of tips that will give you some guidance about how to use the new VSIX capabilities in the best way. Here\u2019s what I\u2019m going to talk about:<\/p>\n Packaging your extensions using VSIX<\/strong><\/p>\n Installing via MSI<\/strong><\/p>\n Some extensions still need to be installed by MSI: for example some of your files might have to be in a specific, well-known loca\ntion, you might have a component like an MSBuild task that VSIX install doesn\u2019t support, you might need to use binding redirection \u2013 see more information here<\/a>. There\u2019s no problem with doing that. In fact, we provide a way for an MSI installed extension to make itself visible in the new Extension Manager, so that the customer can see all his extensions in one place.<\/p>\n To make your extension visible in the Extension Manager, your MSI install should create a subdirectory in the Extensions directory for the hosting product:<\/p>\n For a non-administrative, per-user install (recommended) in Visual Studio, the path will look like this:\nUsersuser id<\/em>AppDataLocalMicrosoftVisualStudio10.0Extensionsyour companyextension nameversion<\/em>\nand for a per-machine install:\nProgram FilesVS 10.0 install directory<\/em>Common7IdeExtensionsyour companyyour extension nameversion\n<\/em>An Isolated Shell application will define its own Extension directory.<\/p><\/blockquote>\n In that folder, put the extension.vsixmanifest file built by your VSIX project, with an added element that marks it as installed by MSI:<\/p>\n \u2026\n<\/Identifier><\/p><\/blockquote>\n Note that although the user will then see the extension in the Extension Manager, since it\u2019s installed by MSI, he still needs to manage it through Windows Add\/Remove Programs.<\/p>\n Versioning<\/strong><\/p>\n If your extension is self-contained (i.e. you distribute it in a single VSIX that doesn\u2019t have any dependencies on other ones), and no other VSIXs will depend on yours (i.e. your VSIX doesn\u2019t expose any APIs), you don\u2019t need to read this section. If your VSIX does offer or consume APIs, or you distribute multiple VSIXs with common shared assemblies, read on for more information.<\/p>\n First, let\u2019s do a quick review of how versioning works in the CLR. For an assembly with a strong name<\/a>, its CLR identity comes from a combination of the file name on disk, Assembly Version string<\/a>, an optional cultural attribute, and a digital signature. When one assembly references (i.e. consumes APIs from) another one, the consumer is targeted to a particular version of the referenced assembly at build time. (Binding redirection<\/a> can change this at run time, but the VSIX installer doesn\u2019t support that yet.) The version string contains four segments: <major version>.<minor version>.<build number>.<revision> (for example \u201c1.2.123.0\u201d). The recommended convention for using the version string is that when an assembly\u2019s API breaks binary compatibility<\/a>, the major version is incremented. (Note that I\u2019m talking about Assembly Version, which is part of the strong name, not<\/em> Assembly File Version, which is purely informational \u2013 you can use Assembly File Version any way you like. See more information here<\/a>.)<\/p>\n That\u2019s all background information. Now let\u2019s talk about using versioning with VSIX files. The first thing I\u2019m going to recommend, although it probably sounds a little unexpected, is that you not<\/em> change the Assembly Version strings when you ship an update of your VSIX. This is because, as I mentioned above, the VSIX installer doesn\u2019t support binding redirection yet, so if you do change any segment of an assembly version number, you may break downstream VSIXs that depend on the old version number of your assembly. The VSIX file has its own mechanism for version management, and I recommend that you use that one instead, because its added flexibility gets you around the binding redirection issue.<\/p>\n For a VSIX that uses an API from another VSIX:<\/em><\/p>\n The syntax of a VSIX version string is the same as the assembly one, and we will use the recommended convention to indicate that a new release breaks binary compatibility with the old one: incrementing the major version number. The big advantage of the VSIX versioning mechanism is that if you\u2019re consuming an API from another VSIX, you can specify a range of version numbers of the target VSIX that you\u2019re compatible with. Let\u2019s see how this works. When you raise the Add VSIX Reference dialog in the VSIX Manifest Editor:<\/p>\n in the Version fields just above, you can specify a range between minimum and maximum version numbers that you\u2019re compatible with. If the developer of the VSIX whose API you consume obeys the versioning conventions, you can specify a range like from Min 1.0 to Max 1.9999 to indicate that you will use any version of your dependency between those two. When the VSIX you depend on installs, for example, version 1.2, you will be compatible with it. When the user attempts to install 2.0, the installer will recognize the incompatibility:<\/p>\n and display a warning dialog:<\/p>\n If the user updates the extension you depend on anyway, your extension will be disabled because of the incompatibility, and he should look for an update from you that\u2019s compatible with the new version of the API.<\/p>\n If for any reason you believe you are dependent on a specific version of the target extension, you can code that number as the Min and Max values to target only that version:<\/p>\n If you only code the Min value, you will bind to anything equal or higher. I don\u2019t recommend that, because binary compatibility breakage (in the example below, from 1.x to 3.0) can lead to run time errors.<\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2010\/06\/8764.image_thumb_5D008069.png\" "\\"image\\"")
<\/a><\/p>\n\n
\n
![\"image\"](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2010\/06\/2055.image_thumb_7A08464C.png\" "\\"image\\"")
<\/a>\nBut be aware that it will load only one, and the first one loaded wins. So you should ship updates to all your VSIXs that contain common assemblies together.<\/li>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2010\/06\/5584.image_thumb_18DEBA2B.png\" "\\"image\\"")
<\/a>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2010\/06\/3580.image_thumb_64D89CB1.png\" "\\"image\\"")
<\/a>\nIn this case<\/p>\n\n
\n
\n
<Identifier Id=\"VSIXProject2.Microsoft IT.8532242f-afdc-44fa-82b2-0b6b5afc1c38\">\r\n\u00a0\u00a0\u00a0 <Name>VSIXProject2<\/Name>\r\n <InstalledByMsi>true<\/InstalledByMsi><\/span><\/strong><\/pre>\n<\/a><\/p>\n<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2010\/06\/5265.image_thumb_2CCE79F3.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2010\/06\/3438.image_thumb_11534ABE.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2010\/06\/0572.image_thumb_02CE7BCB.png\" "\\"image\\"")
<\/a><\/p>\n
![\"image\"](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2010\/06\/3531.image_thumb_62473C18.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2010\/06\/3482.image_thumb_0D9401FB.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2010\/06\/1030.image_thumb_41C82B41.png\" "\\"image\\"")
<\/a><\/p>\n