Darren told me about Geoff’s issue with VB.NET over lunch today. After reading the post for myself I can’t help but have a bit of a chuckle – especially because he’s trying to blame a blatant VB.NET compiler bug on the C# compiler.
I’m not sure what the real reasons are the C# team didn’t implement background compilation, but I suspect that they may have known that its a remarkably tricky thing to do and if they cocked it up they could easily drop their users in it at critical phases of the project.
VB.NET obviously wasn’t designed for serious work, so they decided to slap it in and hope for the best (
) knowing that their legion of zealots would blame C#. So lets set the record straight on this one.
C# doesn’t do background compilation, although it does support intellisense intra-project without needing to recompile. This works really well. When the code is compiled it can offer up type information for other projects to consume – this also works well.
However – the VB.NET has a bug where it bombs out reading this type information in specific circumstances which Geoff and Paul Vick have already mentioned. To me this isn’t just a bug its a design flaw. The design flaw isn’t that it breaks, the design flaw is that the background compiler in VB.NET is believed when you hit CTRL-SHIFT-B to order a compile.
When I hit CTRL-SHIFT-B in C# you had better give me CSC.EXE baby otherwise there are going to be words – nasty words. Thats not to say that the C# compiler isn’t perfect, in VS.NET 2002 it had a pretty serious memory leak that anyone that had large solution files would have run in to, and from time to time assemblies and their PDB files can get out of sync and you need to do a full rebuild.
I think the reason this now all works in VS2005 is that the underlying build system is MSBuild and it actually runs VBC.EXE to compile code, and project references are also fed into the build system just like source files.