Files open in the wrong version of Visual Studio


28 September 2011, by

Here at Softwire we keep pace with the latest  technologies and tools as much as we can. However it is often safer to leave a completed, tested and deployed project running in older technologies if there is no compelling reason to upgrade. This can mean that with several new projects in development and old projects in support, in the past I have had two, three or even four different versions of Visual Studio installed on my development machine.

The problem

Microsoft periodically releases service packs and security fixes for Visual Studio. Unfortunately part of the installation process includes a registry ‘repair’ install, which resets all registry keys back to their defaults – for the version of Visual Studio that you’re patching, regardless of other versions present on the machine. This includes resetting the version independent registry keys, e.g. for the primary automation interface VisualStudio.DTE:

The Registry Editor showing HKEY_CLASSES_ROOTVisualStudio.DTE for a machine with Visual Studios 2008 and 2010 installed after the recent VS 2008 MFC security fix

This is a machine with Visual Studio 2008 (version 9) and 2010 (version 10) after the recent VS 2008 MFC security fix. As you can see the version-independent program ID for this interface has been reset to the 2008 version, VisualStudio.DTE.9.0. If you now double-clicked a file that would usually open in Visual Studio, e.g. an XML file, it would open in Visual Studio 2008 not 2010.

The solution

Fortunately there’s an easy fix: run the Visual Studio 2010 installer from ‘Control Panel’, ‘Uninstall programs’ (or ‘Add / Remove programs’ on older version of Windows) and select ‘Repair / Reinstall’. This will refresh all of the affected registry keys to reference Visual Studio 2010 again.

The Visual Studio Editor

A final note about the Visual Studio editor: I’m a big fan. It’s good for working with text files other than just source code – it has plenty of selection and manipulation features (including regular expressions), it supports Unicode and gets character encoding right – and it’s broadly what I’m used to. It also has excellent support for other file types built-in such as editing HTML and XML. There’s one down-side: it does grind to halt with very long line lengths – tens of thousands of characters or more – but thankfully they’re fairly rare, or often a file format such as XML which Visual Studio can neatly reformat for you.

In particular if you’re an old (and stubborn!) programmer like me who still uses the command prompt for basic file-management tasks, there’s Visual Studio automation sample VSEdit which acts as a bridge between these the command line and Visual Studio. You can type

VSEdit readme.txt data.xml index.html

at a command prompt and it will open those files in your Visual Studio window, or start a new copy and open the files in that. And this where I usually run into the problem I’ve described above: VSEdit uses the VisualStudio.DTE automation interface, and will choose the wrong Visual Studio version after service packs and security fixes.

Tags: , ,

Categories: Technical

«
»

Leave a Reply

* Mandatory fields


six + 2 =

Submit Comment