August 25, 2010
Fixing TeamCity errors in the Visual Studio experimental instance
The good people at JetBrains obviously think Visual Studio extensibility isn’t painful enough already, and the latest version of their otherwise nice TeamCity continuous integration server makes it positively excruciating. The Visual Studio add-in for TeamCity 5.1 installs itself into the experimental instance as well as the main instance, and makes a complete pig’s ear of the debugging experience. Not only does TeamCity fill up the debug window with endless first-chance InvalidOperationExceptions, making it hard to see your own debug output, but whenever you close a document window or Visual Studio itself under the debugger, TeamCity throws a NullReferenceException or InvalidOperationException and breaks into the debugger. This gets very tedious very quickly.
You can’t remove TeamCity through Extension Manager or Add-In Manager, but there is an obscure dialog that allows you to ‘suspend’ it:
- Go into Tools > Options
- In the list on the left, select TeamCity
- Click the Suspend button
- Click OK
(This dialog is helpfully documented in the Resharper help file, the obvious place to look for TeamCity troubleshooting.)
As a parting gift, TeamCity will throw a few more spurious exceptions (“No application shell running.” Er, yes it is), but after that you should be able to run the experimental instance under the debugger without getting bogged down in stupid errors.
Well, except the ones in your own code, of course.
August 18, 2010
Fixing the Server Explorer “The given key was not present in the dictionary” error
One of Visual Studio’s most cryptic error messages is Server Explorer’s infamous “the given key was not present in the dictionary.” This typically means that you’ve installed a custom data provider, created a Server Explorer connection using that provider, and then uninstalled the provider without deleting the Server Explorer entry. This pretty much kills Server Explorer: from now on, any time you try to add or remove a connection, it barfs up the useless error. This means you can’t even remove the dud connection.
The top Google hits for this issue recommend such brilliant solutions as creating a new user account and formatting your hard drive and reinstalling Windows. Fortunately, you don’t have to go to such extreme lengths.
If you can guess what provider you might have installed and uninstalled, then you can reinstall that provider, delete all associated connections, then uninstall the provider once and for all.
If you can’t identify the provider, or can’t reinstall it, then you can go under the hood to remove the invalid connection. Here’s how.
First, close all instances of Visual Studio.
Now, go into your user AppData directory (e.g. C:\Users\Alice\AppData) – note this may not be shown in Windows Explorer if you have “Show hidden files and folders” turned off – and drill down into Roaming > Microsoft > Visual Studio > 10.0 > ServerExplorer. You’ll find a file in there called DefaultView.SEView. This bad boy is where the connections are stored.
This is a plain XML file, so in theory, you can locate the dud connection by its Label and just remove the containing DataViewNode XML element. In practice, I didn’t have much luck with this – the file stores blobs against connections by index, so deleting individual items can throw those indexes off. But if you’ve got a lot of connections defined and you don’t want to have to recreate them, it’s probably worth giving this a try in case you get luckier than I did.
Otherwise, just delete the DefaultView.SEView file.
Then restart Visual Studio and party on.
Hat tip to Jason Short at VistaDB.
August 06, 2010
It has been that kind of a day
This morning I was doing one talk at TechEd New Zealand.
Now it looks like I’m doing four.