Managing Vsix Deployments with Powershell

Sun, 30 Mar 2014 11:40:16 +0000

tl;dr - vsix-tools fixes the ‘Invalid Multiple Files in VSIX’ issue on the Visual Studio Gallery and lets you set vsix version numbers with Powershell.

I maintain a reasonably large project called SharpGL. This project contains two Vsix packages (Visual Studio Extensions), each of which contains project templates for Visual Studio.

If you have ever worked with Vsix files before you might have noticed that the tools for them in Visual Studio seem a little flaky - but even more so is that Visual Studio Gallery site that you have to use to upload your extensions.

Add more than one project template to your Vsix and try and upload it - this is what you’ll see:

It’s a pain to solve this problem - basically you need to change the folder structure within the vsix file, then change the xml that describes it. Now this is not too much of a problem if you do it once or twice, but if you’re in the situation where you want to be able to build a release of your code rapidly, including extensions, this will seriously slow you down.

Enter VsixTools, a little Powershell script that lets you resolve this issue and as a bonus lets you set the version in the Vsix as well - very useful for scripts that build releases. You can use it like this:

# Load vsix tools
. VsixTools.ps1
# Set the version number of 'MyPackage' and fix the zip issue for uploading to the gallery.
$vsixPath = "c:/MyPackage.vsix"
Vsix-SetVersion -VsixPath $vsixPath -Version "2.2.0.1"
Vsix-FixInvalidMultipleFiles -VsixPath $vsixPath</pre>

This Powershell script has no dependencies, it’s just Powershell 2.0. Get the script at github.com/dwmkerr/vsix-tools.

It works for package manifests of version 1 or 2 - for anyone who’s lucky enough to have not had to delve into the internals of this that means that it works from Visual Studio 2010 onwards.

WPF and Visual Studio Addins

Wed, 12 Jun 2013 01:36:18 +0000

If at all possible nowadays, I write all my Windows UI code in WPF, it’s just quicker and easier than WinForms. Recently however, I came across a situation that you should just avoid.

If you’re developing addins for multiple versions of Visual Studio - don’t use WPF for the Tools > Options windows. It’s just noit going to place nice out of the box. This is because there’s a lot of property page Win32 stuff going on in the host window that makes it hard to route messages properly - keyboard entry won’t work correctly, tab order will be messed up and more, it’s just not worth the pain.

If you’re developing addins for later versions of Visual Studio, you can actually use the VSPackage functionality to build options pages with WPF with ease, just check UIElementDialogPage. In fact, read the article here:

Creating Options Pages by using MPF

Final thoughts on this - if you want the functionality above in VS2010, you can get it (as long as you use MPF) by checking this page:

Unable to access WPF User Control in Options Dialog

You’ll see that about halfway down, Ryan Moulden has posted some code from Microsoft for the UIElementDialogPage, you can use that you get the functionality in VS2010.

Any other versions, or for a addin installed by an MSI, it’s probably best to stick with WinForms.

Visual Studio Extensibility on dwmkerr.com

Managing Vsix Deployments with Powershell

WPF and Visual Studio Addins