Visual Studio strangeness #.NET

Just goes to show that Delphi 8 isn't the only IDE that does incomprehensible things now and then.

I just got our latest code from VSS and tried to compile our solution in Visual Studio. I got an error list a mile long, because, of course, VS isn't bright enough to, oh, stop compiling when it gets a compiler error. No, it just goes right on its merry little way, compiling the rest of the solution without a care in the world. And since one of the projects failed to compile, the old version of its assembly is still lying around, so it compiles all the other projects in the solution against the old version of that assembly — but against the newer version of any other assemblies that did compile successfully. So, of course, the errors snowball, because the versions expect different properties, different method signatures, etc. And then, to top it all off, it shows the errors in some sort of wacky reverse-chronological-yet-not-quite-reverse-chronological order, so that the errors you need to see are very nearly at the bottom of the list (about 5 or 10 lines up, usually, though sometimes more), and the chain-reaction errors (from linking against the old version of an assembly that didn't compile) are at the top. So helpful. So very, very helpful it is indeed. One can only hope that Whidbey and MSBuild will be a little more intelligent about the whole thing. Here's hoping fervently.

But I digress.

Anyway, it turns out that the first-generation errors were on a class we had descended from the Xceed Grid's Cell class. The compiler was saying things like "GridControl doesn't have a property of type GridControl".

Mind you, nothing (relevant) had changed. I looked through the diffs to make sure. The project file hasn't changed in weeks. The source file it was complaining about hasn't changed in weeks. It just... wouldn't compile.

Eventually I puzzled out the reason. Visual Studio had arbitrarily, capriciously, and with malice aforethought decided to load the wrong version of the Xceed Grid assembly. (Not any of the other Xceed assemblies. Not even the other Xceed assemblies that themselves reference the newer grid assembly.) It just up and loaded version 1.1 of Xceed.Grid.dll instead of version 2.1. It even had the gall to pretend it was supposed to do this — when I clicked on the project's Xceed.Grid.dll reference in Solution Explorer, it merrily told me the path it had loaded from, and the version it had loaded. Meanwhile, the project file explicitly lists the exact version that it's supposed to load (and it ain't 1.1), and even specifies the exact path where that version of the assembly can be found.

Visual Studio actually went to the wrong drive to load the older version. That's how bound and determined it was to make my day... interesting.

The fix was simple: I closed the solution, deleted the entire Xceed Grid 1.1 directory from my (second) hard drive, and reopened the solution. (cue singing angels) And all is now well with the world.

Still, I'm... disturbed... at the lengths it had to go to to screw up. It had to work at it. It really had to work at it.