The official source of product insight from the Visual Studio Engineering Team
VSIX is a new technology created for deploying Visual Studio extensions. It’s a zip file that uses the Open Packaging Convention. By renaming the file extension of any .VSIX file to .ZIP, you can open up the file in Windows Explorer and take a look at the contents.
I’ve written a separate post about the details of a VSIX and one of our MVPs, Istvan Novak and I gave a talk at the VSX Developer’s Conference last week about general extension deployment. Istvan was gracious enough to post the transcript of our talk.
After the talk, several VSX partners asked me to go into more details on how they can deploy their extensions using an MSI but still play in the VSIX space and show up in the Extension Manager.
Our recommendation is to ship your product as a VSIX but we understand there are limitations preventing you from doing that such as legacy requirements to support older tools that expect files to be in a specific location, configuring an IIS server or Database on install, or supporting VS 2005, 2008 and 2010 all within a single installer.
If you have to use an MSI, we want to make sure the MSI gets the exposure it needs and plays nicely with the Extension Manager. Here are some tips to follow to ensure that:
<InstalledByMsi>True</InstalledByMsi> Adding this tag will tell the Extension Manager that the extension came from an MSI and not to allow the user to enable, disable, or uninstall it through the Extension Manager, since that could cause problems with the other files still installed via the MSI.
Adding this tag will tell the Extension Manager that the extension came from an MSI and not to allow the user to enable, disable, or uninstall it through the Extension Manager, since that could cause problems with the other files still installed via the MSI.
3. If you have any registry keys that get written under the Visual Studio registry have, create a .pkgdef file instead of using the MSI to write the registry keys for you. To create a pkgdef file, create a tool window or menu command using the Visual Studio Integration Package template. Use that as an example pkgdef file to include in your MSI.
4. Drop your files under %VSInstallDir%\Common7\Ide\Extensions\Your Company\Your Product\Version. Use a registry look up under HK:LM\Software\Microsoft\VisualStudio\10.0\Setup to find the install path of Visual Studio and substitute that with %VSInstallDir%. (Check out MSI Registry look up for more information if you need to create one).
By following these best practices, your customer can still get a great extension experience and see your extension in the Extension Manager.
You can also upload your MSI to the Visual Studio Gallery and have it appear in the online tab of the Extension Manager.
Quan To | Program Manager | Visual Studio Platform
Visual Studio 2010 introduced VSIX as a new way to install extensions. A VSIX file conforms to the ECMA
This post is about a new way to install extensions to Visual Studio, introduced in VS 2010, called the
What you mean by "Drop your files ...", could you please list of files need to drop there.
What's the story in VS 2012? Because the extension is not being installed/enabled automatically.
And also I'm including some VS templates which are not automatically installed when using an MSI in VS 2010.
Is it possible to include an MSI into VSIX, so that when I double-click the VSIX, it should run an MSI which I included into the VSIX after finishing installing the VSIX.
@Adrian The answer to your question is at blogs.msdn.com/.../your-vs-package-may-not-load-after-porting-it-to-vs-2012.aspx
@Nithin AFAIK no, you will have to do whatever custom actions the MSI is doing from within devenv.exe on the first time it loads.