Public Class GeoffAppleby

Bitten By A Bug I Never Knew

We were bitten by a pretty savage bug today. It started the moment I walked in the door at work, and we didn't have a work around in place until about 4.30 this afternoon - pretty much a full day wasted on a fairly tight schedule. Not happy Jan :(

The really sad bit is where the bug lives. I've spent a long time lording it over the C# guys that the VB IDE is better. Sure, curly brackets and semi colons don't really make that much of a big deal, default forms a BIG time mistake, nullable types in C# give the appearance of a confused developer (int? hmm...not sure :), but our IDE kicks major butt over the C# one.

In all honesty, there's some things in C# I wish we had, but mostly it's only IDE things - post build events are a good one - and there's some stuff that VB got right and C# just screwed up - go to definition is a good example - but we have background compilation! To me it's a fantastic feature, and while I've heard some people whinge about how much slower things are in VB (IDE-wise) I've never noticed it myself.

But today we were hit by a bug in the background compiler. Let me explain.

<insert cheesy whooshy wobbly scene change effect> (Yes, stolen from Jay who stole it from me in the first place :)

I arrive at work. I update my code base with the latest that's in the source repository, since I knew one of the guys was working later than me last night.

I open up the solution, and there's an error in the task list - Can't find type X from assembly foo.dll, add a reference to foo.dll - or words to that effect.

Ah, no problem, I think to myself. He's got the skeleton code in, and didn't finish. I'll just add it. So I go to add it...but it's already added.

Damn C# guys, I think to myself. I have to compile it before the IDE knows anything about it. How 90s.

So I do a full rebuild...and the error is still there. WTF?

A lot of research later, once we'd narrowed down the cause for ourselves (I should have just damn well googled to begin with!) I discover a post from Paul Vick that explains exactly what's going on.

<whooshy time slice effect again, bringing us back to the present>

So to describe our problem (you can be bit in other ways) if some VB code uses a class in a C# project, which exposes a type from a VB project, then the background compiler shits itself and throws a tantrum, and won't build.

We tested - a command line compile will work. This is crap, as we shouldn't have to leave the IDE.

Using file references instead of project references will work, but that's pretty crappy too.

For now, just to get to the next ship-target (the next couple of days) that one VB base class that it has trouble dealing with has been rewritten in C# and will live in a parallel state for the next few days until I tell the C# guys that they're going to have to convert some of their assemblies to VB (hey, if I'm going to be team leader, I get the final say, right?! *smirk*)

The good news is that the problem has been fixed in VS2005B2...but that doesn't help us now.

But there's always a bright side. It's better it happened now that in a couple more days when we're really getting close to the wire!