Ran into a real pain in the @ss today. While working with Team Foundation Server I was refactoring a couple of projects and at one point I needed to "Undo" my changes. This is normally accomplished by what you see on the left.

Well, to my dismay, as soon as I clicked on that button, Visual Studio 2005 would HANG. I mean, it would just stop. The only way to get it to respond (and yes this is odd)  was to go to Task Manager, then right click on the application (on the Applications tab) and then click "Minimize" then click "Maximize" and the app would respond. Unfortunately the "Undo" didn't happen though.

I looked all around the net, and couldn't find anything. I did the following...

devenv /resetskippkgs (didn't work)

devenv /resetsettings (or something like that - anyway - it didn't work)

I also installed hot fixes that seemed to be related to this problem. Didn't work. Reboot - didn't work. Installed last nights updates - didn't work.

I repaired Team Foundation Explorer - didn't work.

As a last resort I decided to take VS2005 back to its clean slate state by firing off this command. This command is kind of hidden and is not supported by Microsoft (details - all the way at the bottom of that link).

Fix: devenv /resetuserdata

MSDN - Disclaimer: you will lose all your environment settings and customizations if you use this switch. It is for this reason that this switch is not officially supported and Microsoft does not advertise this switch to the public through devenv /? command.

After I fired that bad boy off, waited a few minutes and fired up VS2005 and everything worked again. Thank the big baby jeebus for not having to re-install VS2005 or use a MS Support call. 

I was creating a solution file for an application at a client and I got this error message.

Sara Ford explains why this happens here. The OS limit is 260 chars for the MAX_PATH variable according to Sara Ford's blog.

So how do you get around it? In this case, Visual studio was creating a folder for my solution. So I just created a solution somewhere else on the system and copied it over to my destination folder. I knew that the files wouldn't be exceeding the 260 character limit anytime soon so it wasn't a problem.

But what if you do need to exceed the file path? Easy, create a file share. Share a folder as a new drive on your machine, then create the solution on the new share (its still in the old folder) but you're referencing it with the new path. Kind of a kludge, but it works.

Sara Ford posted a blog entry (which I got from the VS2008 Tip of the Day Gadget on Vista) which made me slap my forehead and say "... #$@#! why didn't I find that before."

Pretty much, you can show syntax highlighting for custom file extensions.

When I make build files, I like to name them .build or .msbuild (depends on whether its a NAnt script or MSBuild script).

Previously, I would edit my build script in Notepad++ and set the style to XML for syntax highlighting. It worked well, but I hated having to leave Visual Studio to edit my build file with nice pretty colors.

Now, with this tip (see the link above) I have set my build file extensions to open with the XML Editor.

Here's what I did:

Now when I open the build files I get the pretty colors.

Oh how the simple things impress me at times. I just wish I knew about this before. It just goes to show you that Visual Studio is a very in depth program.

Thanks for the tip Sara!

I'm getting ready to move over to BlogEngine.NET and I was working with the DasBlog Converter that comes with BlogEngine.

To get this tool to work you have to set your feed to something like 1000 items your RSS feed. That way the importer can read the feed, and then pull in everything from there. Well... here's the thing... I set my feed to 1000+ items and left it there on accident.

I use FeedBurner as my RSS feed provider and this week I noticed my feed on google.com/ig/ was showing VERY OLD posts. I couldn't figure out why off the top of my head. After some quick investigation I saw that Feed Burner was returning a 500 Server Error. The feed was too large - it was over 512K.

This was a problem for new subscribers... I couldn't get anyone new because feed burner was rejecting any requests because the feed was obnoxiously huge.

If you have already subscribed to the blog, you would have OLD posts showing up on Google.com/Ig/. BUT.. if you used Google.com/Reader/ or Bloglines, or RssBandit, or anything else, the feed worked as expected. But Google.com/IG/ just barfed on huge feeds.

I cut back the feed and then everything started working like normal. So, if you have weird things happening on google.com/ig/ with your feed, check your feed size!

Argh! Nearly an hour wasted,

I was building a source tree today for a new TFS installation and in the middle of my workday VS2005 decided to puke on the screen. It straight up died, froze, hung, whatever you want to call it, it was gone and it wasn't coming back. I was forced to kill the process after taking a 10 minute break and seeing it still hung.

Prior to the crash, the solution built fine. The solution had 32 projects in it and everything was running smoothly. After the crash I restarted VS2005 and then re-built the solution. VS2005 BARFs on a file.

The error I get is something like this:

"metadata file could not be opened (... file path ..) -- file is corrupt"

Huh? So I try moving references, adding them, deleting them, changing namespaces, changing dll names, everything.

I then try to open up the DLL in Reflector and I get the gem:

"File is not a portable executable. DOS header does not contain 'MZ' signature"

What? This solution just build 5 minutes ago, I didn't change anything except a crash.

Well, apparently when the crash happened, that particular project GOT HOSED, BAD. Who knows how, who knows why, but it did. I took a back up copy, replaced it on top of that project and rebuilt the solution and like magic it starts working again.

So, if this happens to you, just drop the project get another copy, then re-add it and hopefully it works. I hate giving these types of answers, but unless I go digging into the root cause of the crash (would could take forever in a project like VS2005) I wont know what exactly caused it. CRAPPY MAN, CRAPPY.

Moral of the story: This takes it back to the "K.I.S.S." principle. I spent nearly an hour trying to fix this problem by tracking it down and moving things around, troubleshooting, etc. I should have just tried the "replace" first and I would have saved an hour.

So, Next time...

Keep it simple, stupid.