This book is about finding, understanding, fixing, and preferably preventing bugs when creating desktop, network, and Web applications with Visual Basic (VB) .NET. It explores the power of the new cross-language and cross-component debugging tools, and shows you how to dig down into or tunnel across your entire application to find bugs at whatever level they live.
With the arrival of VB .NET, many of the old debugging rules have changed. This means that some ominous storm clouds are gathering on the horizon.
Back in the personal computing Dark Ages, during a period when men were men and code was written in blood, it took some seriously hard- core work to create a viable and stable Windows application. Windows itself was still relatively immature and was being held back because of the lack of simple tools available for producing programs. Then in 1991 Visual Basic 1.0 and its successors (henceforth collectively referred to as VB.Classic) came riding to the rescue and changed the software development world in a dramatic way.
For the first time, Windows programming was made accessible, and people who had never before considered themselves to be developers could cast the spells necessary to bring their software ideas to life. Departmental business processes were automated by the thousand, often without any intervention from in-house technology departments. When these "accidental" programmers joined forces with the countless professional developers who valued the remarkable productivity that VB.Classic brought to Windows programming, the result was spectacular. Windows software applications exploded over the next decade , driven by speed of development and the greater pool of available developers. There is even a respectable argument that this ready availability of developers and their myriad applications drove the widespread adoption of Windows itself. It's entirely possible that VB.Classic was the real killer application for Windows.
One of the results of this programming explosion was many managers and even developers started to think that much of the process of software development was relatively easy and that all of the hard plumbing that VB.Classic did behind the scenes meant that applications could be designed and developed much faster. The result was another explosion ”that of bug-ridden software. Windows applications have become notorious for their instability and unreliability. End users think nothing of rebooting hourly and killing errant applications. Lacking the understanding of the types of bugs that were possible, developers have introduced many wild and wonderful defects into their programs. It has taken us a decade to understand and solve many of the typical problems that personal computing involves.
Moving forward into the future, we can see that history might be repeating itself. Where VB.Classic worked by simplifying the creation of Windows desktop applications, the common language runtime (CLR) and the .NET languages are designed to simplify the creation and deployment of desktop and especially network applications. These new applications all use a common class library and can be written in any of at least a dozen different languages. Though the learning curve is significantly steeper than that associated with VB.Classic, the payoff also promises to be much higher. The promise is that everything from XML Web services and operating system services to Web pages and desktop programs will be available with a flick of an IDE wizard's magic wand. Deployment will usually be XCOPY-simple, and DLL hell is set to retreat into ancient folklore (though it may be replaced by policy hell).
The new world beckons, dangling shiny new technology to tempt us into its embrace. The CLR and the .NET Framework have the potential to do to network applications and the Internet what VB.Classic did to Windows. A whole new wave of interesting and innovative distributed applications may be around the corner, or at least in the next town. Developers who understand the network and network applications will be at a premium.