Conclusion in Visual C#

Making ECC200 in Visual C# Conclusion

ASP programmers seldom needed to understand the underlying Win32 API that supported ASP within IIS. Indeed, VBScript and JScript offered extremely limited options for doing anything more than the language itself allowed. ASP.NET programmers, on the other hand, have full access to all that the .NET Framework has to offer. Using C# or Visual Basic .NET, along with the .NET Framework, enable the ASP.NET programmer to do virtually anything the Win32 programmer can do.

When developing real-world systems today, you ll encounter two significant problems: one is the problem of making software work on multiple platforms, and the other is the problem of enabling the various pieces of an application written in different languages to communicate. As you ll see in this chapter, the .NET Framework offers elegant solutions to both these problems. But first, let s review a little history. One attempt to solve the problem of creating software that will work on multiple platforms has been to use Sun Microsystems Java programming language. To run Java, a computer must have a Java Virtual Machine (JVM), which will interpret the Java byte code at runtime. Because JVMs are available in browsers for multiple platforms, it would appear that Java has solved part of the problem. In reality, however, there can be incompatibility in the execution of the same Java byte code even on the same platform. For example, in a recent Java project, I needed to use radio buttons but without any text associated with them. I accomplished this by setting the radio button text to an empty string. This approach worked, but in Microsoft Internet Explorer, when the radio button with no text was selected, a small dotted-line box appeared next to the radio button where the text would have been. The solution seemed simple: instead of not setting the text of the radio button or setting the text of the radio button to an empty string, I explicitly set the text of the radio button to null. This remedy worked for a time. Unfortunately,

when a new version of Netscape Navigator came out, setting the text of the radio button to null not only didn t work, but also actually caused the browser to end hard, displaying an error message referencing some C++ source code. So much for Java s crossplatform compatibility. In the beginning of the PC revolution, cross-platform compatibility was a much bigger requirement. With so many slightly different variants of PCs, as well as other platforms, having a single development environment was very important. Several circumstances have minimized this issue. First, Intel x86 assembly code has become close to a universal assembly language. Virtually any application of any significance these days is available for an Intel-based machine. Even other hardware platforms, notably the Apple Macintosh, provide emulation environments that allow Intel-based applications to run. The second important change that has affected the issue of cross-platform compatibility has been the explosion of the Internet. The Internet provides a single platform that allows applications from a variety of platforms to work on virtually any other platform, including even the newer ones, such as wireless devices. For many applications, HTML, along with client-side JavaScript, provides a rich enough environment. Of course, in some places, the Internet boom has increased the requirement for cross-platform execution notably in creating richer user interfaces on the client side and here s where Java has found a place. As I mentioned at the beginning of the chapter, another difficulty for software developers today is enabling the various pieces of an application written in different languages to communicate. Currently, a number of languages and technologies are used on the dominant platform (Microsoft Windows running on an Intel processor). Common languages include Microsoft Visual Basic, C/C++, and Borland Delphi. Less common, but still used, are languages such as COBOL, Fortran, and PERL. From the first days of Windows development, it has been possible to call into dynamiclink libraries (DLLs) from virtually any significant program development environment, but that doesn t mean it s always been easy. For example, something as simple as passing a string as a parameter that will accept some information can cause great problems. In most programming languages, you must ensure that before the string is passed in, it has sufficient allocated space. This task isn t something that many programmers in some programming environments are used to doing. For instance, in Visual Basic, strings are managed, and if you pass a string into another function by reference, the string can have information added to it without worrying about who allocated the space. User-defined data types are much worse, and on at least one occasion not so long ago, the way that Visual Basic padded members of user-defined types wreaked havoc on many a program that had relied on structures being packaged just so. In recent years, COM has been the glue that holds components from the various languages together. COM provides a least common denominator approach to things like data types and does nothing to address issues involved with using the Win32 API. Using the Win32 API from Visual Basic requires some very un-Visual-Basic-like data structures, and the Win32 API can often be difficult to use from other languages as well. The string type supported by COM is BSTR, a not entirely friendly type for C/C++ programmers. The .NET Framework offers solutions to all these problems. First it provides a system of data types that can be marshaled between multiple .NET languages without any loss of fidelity. Developers using the .NET Framework will no longer have to worry about what language might be consuming the class or component they re writing. They can spend more time solving the problem at hand and less time worrying about how the C++ client for the server program is going to interpret a string or a currency type. Next the .NET Framework provides a virtual execution environment that addresses the need for portability without forsaking performance. Applications built on the .NET platform run as native applications on whatever platform they re running on. I ll explain the technological magic that allows this to occur in the following sections.