It seems at least to me that as more bells and whistles were added to each new release of Microsoft’s products, the qualities of which have been deteriorating. My observation not only manifested itself in the public perception of Windows Vista, but also became self-evident in my and many of my peers’ daily frustration with Microsoft’s flag-ship IDE – Visual Studio .Net.
Recently, while working on some projects, I accidentally found out how easy it is to crash the Visual Studio .Net IDE and all it takes is literately one line of code.
Apparently, it seems that some developers at Microsoft must have forgotten the old design principal in software engineering: Never assume that a user won’t do certain things. From the surface Visual studio 2005 and 2008 look much fancier than their old cousin Visual Studio .Net 2003. But neither of them can handle the following line of code correctly without crashing:
s = s.Trim().Trim()….. Trim(); //will crash if the line length is too long
If you try to move the cursor to the end of the line in either VB or C#, the IDE will crash (here is the sample code for VB.Net and C#). And it seems that there’s little consistency between the different .Net language compilers (vbc and csc) in terms of what is the maximum line length it can handle. It seems that for C#, the IDE can handle line width (in terms of the code above) of roughly 20,000 before crashing while VB.Net could not handle even half of that. It is also interesting that the code line length limitation seemed to be more restrictive in Visual Studio 2008 than in Visual Studio 2005 (note, it could as well be the OS limitation since in my experiment, the Visual Studio 2008 instance was running under Windows Vista whereas the Visual Studio 2005 instance was running under Windows Server 2003).
Also, the error messages you received when running the same program within VS 2005 and VS2008 were different as well. For instance, if you are compiling the sample programs under Visual Studio 2008, the C# program gives a pretty accurate error message:
An expression is too long or complex to compile near ”
But the VB program could not be compiled at all, and you will get an internal error from the VB compiler:
The "Vbc" task failed unexpectedly.
System.Runtime.InteropServices.SEHException: External component has thrown an exception.
at Microsoft.Build.Tasks.Hosting.IVbcHostObject.EndInitialization()
at Microsoft.Build.Tasks.Vbc.InitializeHostCompiler(IVbcHostObject vbcHostObject)
at Microsoft.Build.Tasks.Vbc.InitializeHostObject()
at Microsoft.Build.Utilities.ToolTask.Execute()
at Microsoft.Build.BuildEngine.TaskEngine.ExecuteInstantiatedTask(EngineProxy engineProxy, ItemBucket bucket, TaskExecutionMode howToExecuteTask, ITask task, Boolean& taskResult)
Sometimes, you will get this error when trying to compile the VB program:
And here are the corresponding application events in event viewer (corresponding to the VB environment crash):
When trying to move to the end of the line, both VB and C# application would crash the IDE and give the following error:
And the Visual Studio 2008 IDE would then close.
Within Visual Studio .Net 2005, if you try to move the cursor to the end of the line in the C# version, the application simply closes (crashed) but no error message is given. But if you try to compile the C# code, you actually get the following error indicating that the line is too long:
An expression is too long or complex to compile near ‘VSCrash.Program.Main(string[])’
The same code in VB would not even load without giving the following error:
And if you close the error dialog and try to compile the VB.Net code, you get this error message:
Visual Basic compiler is unable to recover from the following error:
System Error &Hc00000fd&
Save your work and restart Visual Studio.
Which is the same error message as in Visual Studio 2008. And the event viewer records the following information:
The VB.Net environment’s crashes are more troublesome. As indicated by the event viewer, it seems that the the exception chain went all the way to the kernel32.dll (note, if you choose the debug option when the VS 2005/2008 environment crashes, you can actually see the full exception chain along the execution path).
In my opinion it is one thing that the IDE has some design or practical limitations and it is totally another if the IDE simply crashes. Alas,
the only IDE that can handle this code correctly is Visual Studio .Net 2003.
