Managing Vsix Deployments with Powershell

tl;dr – VsixTools 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 ""
Vsix-FixInvalidMultipleFiles -VsixPath $vsixPath

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.


Recursive read lock acquisitions not allowed in this mode

If you are using the following combination of tools:

  • Visual Studio 2012
  • Visual Studio Tools for Git
  • Nuget

Then you may encounter some weird problems when trying to update Nuget packages. For me, updates regularly fail with:

Recursive read lock acquisitions not allowed in this mode.

I’m lost on the root cause of this, but it does seem that the project I’m working on has files set to read-only by something regularly, perhaps Visual Studio is trying to make Git more TFS-y by locking things all over the place. Whatever the cause, I’ve found that the following usually helps:

  1. Don’t use Update-Package – use Install-Package instead.
  2. Make sure the solution has all of its files read+write, not read only.
  3. Open the team explorer and go to ‘Commits’ – making sure that the Git tools have loaded various components.

This combination of tricks seems to solve the problem. If anyone has any other ideas or suggestions, just comment.


Visual Studio Deployment Projects – an Update

I received the following message in my inbox the other day:

‘[Uservoice declined - Bring back the basic setup and deployment project type Visual Studio Installer.’

Some readers may recall my post on the frustrating removal of the simple deployment project from Visual Studio. Unfortunately, with this message, they have closed the Uservoice request to bring back the basic setup projects (the request is at http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3041773-bring-back-the-basic-setup-and-deployment-project-).

It’s rare for me to blog or comment on products like visual studio, to complain or evangelise about features and so on, but in this case as the previous post had received some interest I thought I’d write an update.

It’s extremely frustrating for developers to have features like this removed from our toolkit. Is it fair to call it our toolkit? Perhaps not, but this is an extremely expensive product, we pay a lot of money for it and it’s a product that evolves in a sense based on what we do. As we start developing more and more web based applications, the product evolves in that area. As we develop less in other areas, features are no longer invested in. This is all fair enough.

However, it is difficult to keep your customers happy when a simple and extremely useful feature is removed, and replaced with essentially a cross sell link to another product. In fact, let’s look at this and really state what the problem is.

We’ve paid a hell of a lot of money for a feature rich toolkit, that can cope with diverse development requirements. An element we’ve used for years has been removed without explanation and replaced with an advert for an expensive alternative.

I doubt very much the deployment project was a difficult or expensive one to maintain. In fact, its simplicity is one of the reasons it was popular. So most of us are thinking that a working, heavily used feature has been deliberately removed. Why? To sell another product. This sort of mercenary behaviour is not appealing to us as customers.

I would end this post by saying that us computer nerds are fickle and highly strung about things like this. If we feel we’re getting screwed over, we’re likely to move to alternative products.

This indifference to customer opinion is rather worrying. (This was the second highest voted item in Visual Studio Uservoice). It also seems to not be isolated. Many customers seem deeply disenchanted with decisions taken in Windows 8, these concerns have been raised and roundly ignored.

I’m not going to go on any more about this, the comments and posts have been made, the requests ignored.

But I will say that if you have a online system to collect user feedback and requests for features for a product as expensive as Visual Studio, a request in the top three is for you to bring back something you’ve removed to get a kickback from Flexera, and you ignore the request, then don’t bother asking for feedback, because it feels like a middle finger to your customers.


Web Deploy – Could not connect to the remote computer

Using Web Deploy is a nice and easy way to publish websites and web applications with Visual Studio. However, I found one thing that can be a bit of a blocker, that didn’t seem to be explained anywhere very well.

Let’s imagine I administer a webserver that hosts the site www.something.com. I’ve installed the Remote Management tools for IIS and the Web Deploy stuff, and have also configured the site to allow Web Deploy. I now try and deploy using Visual Studio, with the settings below:


Validating the connection fails with the message:

‘Could not connect to the remote computer “somesite.com”. On the remote computer, make sure that Web Deploy is installed and that the required process (“Web Management Process”) is started. [more stuff] ERROR_DESTINATION_NOT_REACHABLE.

So what do we try first?

  • Check the Web Deploy feature is installed on the server, it is.
  • Check the Web Management Process is running, it is.
  • Check port 8172 is open, it is.
  • Read up on similar issues, they say the same as the above.

I spent quite some time pulling my hair out over this – is it because I’m on a different domain? Is there some other port that needs to be open too?

Now the error says ‘could not connect to the remote computer “somesite.com”‘ – so maybe the issue is here. I try the IP address, www.somesite.com and the IP address with the port 8172 specified – no joy.

It turns out, that even though it says ‘Server’ in the first box (leading us to think it would be the address of a server we need), it’s actually the server with http specified. Change the Server from somesite.com to http://www.somesite.com and it works a charm.

Not the most exciting post ever, but hopefully this’ll save someone else wasting the same amount of time that I did.


The Visual Studio Experimental Instance

Working on some addins lately has taught me a few really useful tricks about debugging in Visual Studio. I’ll update this post over time.

The Experimental Instance

Very useful to know – the experimental instance loads its extensions from a special folder, and debugging extensions drops them there. The location is:



Deployment Projects in Visual Studio 2012

[Note: They aren't bringing setup projects back, see http://www.dwmkerr.com/2013/06/visual-studio-deployment-projects-an-update/]

As part of Microsoft’s ongoing campaign to reduce the usability of their tools for anyone who isn’t working in exactly the way they want, Visual Studio 2012 no longer comes with the ability to create setup and deployment projects.

This is a pretty serious change. For anyone who is developing client applications, then an installer is pretty critical. Now the feature set in the VS deployment projects was fairly small – they were aimed towards making pretty basic, lean installers. And that was fine. That was what we needed it for. Installers for utility apps, installers for basic client applications, installers for testing out projects on other machines before we went to more advanced systems.

What’s truly disappointing is the lack of alternatives. Rather suspiciously there are links to InstallShield projects in Visual Studio now.

If you’ve never worked with InstallShield before then I envy you. It is truly awful – a maintainance nightmare combined with a user interface that makes creating basic installers baffling.

So Visual Studio now has no deployment projects. You can try using the free edition of InstallShield, but be ready for a world of pain. Also, considering the vast complexity of the UI, the free edition is incredibly limited in functionality – for example you cannot create ‘features’ (i.e. the chunks of functionality that you offer as an optional feature for an installation).

Example of Time Wasted

My Switch addin for Visual Studio adds a button to the UI that lets you switch between related files (cpp/h, aspx/aspx.cs etc etc).

I need to update it to work in Visual Studio 2012. I cannot develop VS 2012 addin projects in Visual Studio 2010. With a sigh I move the solution into 2012. I write the 2012 addin. The deployment project doesn’t load (as expected). I build the binaries into specific locations. I open the project in 2010. The 2012 addin doesn’t load (as expected). However, the setup project will not build due to an error when ‘updating dependencies’. This project has no dependencies – it builds from specific locations.

So now to release a version of Switch that supports VS2012, I need to use InstallShield. InstallShield’s free edition doesn’t support features – therefore I have to install Switch for 2008, 2010 and 2012 for everyone, always, regardless of whether they have it. A two hour update is not looking possible now. I don’t have the time to waste trying to bring back functionality I already had and have to move onto other work.


Thanks MS for removing this critical feature, and replacing it with an essentially useless and overly complicated alternative.

Please remember, we’ve paid for Visual Studio – not for a vessel to host adverts to other products. We had the functionality before, now its gone – replaced by links to an expensive (and frankly crap) suite of tools that aren’t suitable. Why has this happened? The cynical part of me thinks there’s some kind of deal going on between MS and InstallShield (well of course there is), and we’re suffering from it.

Hit the uservoice page here: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3041773-bring-back-the-basic-setup-and-deployment-project- to try and vote for it to go back in.


Come on MS – Improve MFC

Loads of developers still use MFC. OK – if you’re writing a new project, MFC would not be a great choice. But what if you’re maintaining a 1.5 million line MFC app? 

MFC support in Visual Studio has barely improved since VC++ 6.0 – in fact its got worse. Their cursory attempt to show an effort by adding support for the Ribbon Control with the MFC feature pack was not enough. Why can we still not properly use tab controls in the dialog editor?

Those who use MFC are probably supporting big enterprise applications – for a long time now we’ve been neglected. Please vote for more MFC support in Visual Studio Uservoice below:


Will they listen? Chances are not – unless lots of people vote. But I’d really like to see some effort on this, it’s a technology still used by many.

It would be interesting to see a survey of enterprise applications – and what they’re written in. It’d be interesting to then compare this to how well MS support that platform. MS will put lots of efforts into what they think that developers should be using – but how well are they supporting their real customers who are creating real products?