Microsoft did a hell of a job following up on the obscure bug that I posted (I'm sure that the fact the post was published on eWeek , The Register and other places helped a bit in speeding things up..). It involved lots of emails, my creating a mini-dump and FTPing it over, and sending the the full project code. But it worked.
So what was it, Roy?
It was a namespace thing. Before I give out the full answer I got, it's important to realize that even though this was something which is a "feature" rather than a bug (I screwed up namespace bindings for the compiler in my own code) it should not be this hard to understand what went wrong and how to fix this. Microsoft has promised that this specific issue and error ID will be address directly in a help topic online, which will be easily "findable" using the various search engines out there given the error description.
"Hi Roy,
I took a look at your project and have found the problem.
This code will repro the problem:
Namespace System.ComponentModel
End Namespace
Module Module1
Sub Main()
Dim x As System.Object
End Sub
End Module
When you declare the namespace System.ComponentModel you are really defining the namespace Global.ConsoleApplication1.System.ComponentModel assuming your project’s rootnamespace is ConsoleApplication1.
Thus when the compiler try’s to bind to System.Object it will find and look inside of Global.ConsoleApplication1.System and it will now not find Object. Hence the error.
If you wants to bind to the real System.Object you will have to qualify with the Global keyword to get to the right System namespace:
Dim x as Global.System.Object
However, are you sure that you want to be defining your own namespaces underneath the Rootnamespace that shadow .NET Framework namespaces?
Perhaps your intention was to extend the .NET Framework namespaces. If that’s the case you need to set your Rootnamespace to blank in your project properties. This will also resolve your problem."
I highlighted the last paragraph because that's exactly what I was trying to do.
This is also reproducible in C#. Like I said the main problem here was the discover-ability of the underlying problem and its solution. It shouldn't take a team of engineers (who actually built the thing) a couple of days to track down what the problem really is.
How do I know this is reproducible in C#? I asked. Here's the answer I got:
"Actually, the problem does exist in C#. This code will repro the problem:
namespace ConsoleApplication167
namespace ConsoleApplication167
{
namespace System
{
}
class Program
{
static void Main(string[] args)
{
object x = new System.Object(); ß-- This line will give an error
}
}
}
In VB a new class or module is implicity defined inside of the Root namespace. In C# they spit the explicit Namespace for the Root Namespace. Thus if the definition of Namespace System is placed outside of the explicit Namespace ConsoleApplication67 you are extending the “real” system namespace. But (as in the example above) if it’s placed inside of the root namespace you end up with the same problem."
In the end, thanks to MS this was resolved. Good job hunting this down.