Arrgh. Today I got back to a LINQ to SQL app that’s been sitting idle for some time. It’s a demo app and as I started the app up and compiled the solution I got:

Error 1 Build failed due to validation errors in C:\projects2008\TimeTrakker\TimeTrakkerBusiness\model\TimeTrakker.dbml. Open the file and resolve the issues in the Error List, then try rebuilding the project. C:\projects2008\TimeTrakker\TimeTrakkerBusiness\model\TimeTrakker.dbml

Well, I opened the file and looked at the error list – according to the error list it’s a parsing error at a / with no line number and not even a filename. Swell.

I remember odd parser behavior when upgrading between the beta version and the final release. I think the change at the time was an encoding change from UTF-16 to UTF-8 or something along those lines that caused the document not to be readable. But it turns out that wasn’t the problem. I checked encoding saved the file and validated the XML – no problem there.

I then opened another project with another Linq to SQL model and it too fails with the same error.

So this is a more serious issue. At this point I turned to Google to search and sure enough this has been found on a few occasions (like this post from Michael James).

As Michael points out the fix is to reset the Visual Studio Packages. Apparently at one of the many times that VS starts and complains about a package load failure – you know those failures where you usually have no idea what you’re consenting to exactly :-} - I must have unknowingly unloaded the DBML parsing package.

The fix is to run devenv /ResetSkipPkgs:

This fires up Visual Studio and reloads all packages that were previously skipped.

What’s really odd about this is that this is a fairly new machine that has been running solidly and so I don’t actually remember any package load errors. I sure hope that this problem doesn’t show up like this out of the box after an install of VS 2008 SP1? Anybody seen this on a ‘clean’ machine?

Thankfully we have the Internet to search for stuff like this and I found Michael’s post in short order. This is also a good reminder – at least to me – that quite a few Visual Studio problems can be solved by the various reset flags available via the devenv command line switches. Just a few days ago I got my toolbox mangled by a bad component install that actually cause VS to crash on startup. I was able to get into VS in Safemode and reset the toolbox that way.

Imagine having to deal with this sort of issue without the resources of shared knowledge.  So much time is wasted on crap like this that shouldn’t be happening in the first place, and which reduces the productivity that a powerful IDE like VS provides. I’d really hate to total up the hours I spent tracking down some obscure Visual Studio bug or behavior in a year… I’m sure it totals out to a full week of billable time.