What Is .NET?

 

 

What Is .NET?

And What Does It Mean for ASP Developers?

 

By Craig Utley

 

The old joke is that if you took 10 Microsoft employees and asked them what COM is, you'd get 10 different answers. Sadly, if you asked 10 Microsoft employees what .NET is, you might get 11 different answers.

 

That's because .NET encompasses a wide range of features and technologies. One Microsoft employee even described it to me in terms of the Arnold Schwarzenegger movie The 6th Day. In it, Schwarzenegger's character gets out of cab and just presses his thumb on a panel to pay for the ride. In other words, the computer in the cab is able to access the character's personal information and transfer the funds from his account to that of the cab company.

 

Is such functionality available today? Theoretically, yes. However, no one has yet tied all the pieces together - at least not to the level shown in the movie. That's part of what .NET is all about, and ASP.NET developers will be at the forefront of this unprecedented level of integration.

 

So, what is .NET? Given that there are more answers than people for the question, it is important to set a baseline. This article will focus on two key areas of .NET: the underlying .NET Framework and the ability to create distributed applications.

 

A New Framework

You often hear about the .NET Framework. Part of .NET is really a run time called the Common Language Runtime (CLR), upon which your applications run. The CLR provides many of the services for your .NET applications, regardless of the language used. This is important because it means two things: The functionality the CLR provides is available to any language built on the run time, and the CLR can handle many complex and error-prone tasks for you. As you can see in FIGURE 1, .NET provides the CLR for you at the bottom, which hosts a number of base classes. Applications are built using those base classes, and the base classes are available to any of the .NET languages.

 

FIGURE 1: The .NET Framework.

 

When it comes to languages, Microsoft will ship Visual Studio .NET with three languages: Visual Basic .NET, C# and Visual C++ with managed extensions for .NET.

 

VB .NET and C# are new languages, built just for the .NET platform. More than 15 other languages are being ported to the .NET platform, including Perl, Python, Rexx, and COBOL. Any one of these languages is capable of producing ASP.NET applications because ASP.NET is part of the underlying .NET Framework. In other words, the classes that enable ASP.NET to work will be available to any language targeting the CLR. Thus, the choice of language need not mean a trade-off in the final application's functionality.

 

The CLR handles a number of tasks for you. It manages memory automatically, which means the complexities of memory management are removed from the developer and handled by the run time. The CLR handles code-level security, meaning you can have trusted code that can access certain resources only. Threading is an integral part of the CLR, which handles starting and stopping threads and processes for you. The key benefits of .NET are summarized in FIGURE 2.

 

Benefit	What it means for developers
A common set of base classes	The same base classes will be available to any .NET language, reducing what you have to learn if you tackle a new language.
Automatic memory management	.NET manages creating and destroying objects, processes, and threads, freeing the developer from these tasks.
Code access security	Code can be trusted to various levels, which means code in e-mails may be prevented from accessing the file system or other protected resources.
The Common Type System (CTS)	A set of types that are supported directly by the run time. If you stick with the types defined in the CTS, cross-language integration is possible.

FIGURE 2: Some of .NET's major benefits.

 

.NET introduces the concept of a namespace, a way to organize classes into a hierarchy. The CLR contains a number of classes available to any .NET language, and these classes are stored in the System namespace. The System namespace includes all the classes for building ASP.NET applications, as well as any other type of application in .NET. The System namespace also includes the libraries for creating multithreaded applications, performing binary and text IO, and working with data.

 

Living in a Distributed World

Microsoft developers built many distributed features into .NET because they noticed applications were more frequently becoming distributed. This should come as no great surprise because Microsoft has pushed n-tier development using COM and DCOM for at least six years. However, think about what you have done with your ASP applications. You have taken some of the functionality and placed it into compiled COM components. Then, you called these components from your ASP pages, using either COM or DCOM, depending on the physical location of the component.

 

If your components were on another server, your call to them used DCOM. The problem with DCOM is that it is a binary standard and does not flow well across firewalls. In addition, DCOM had no meaning on non-Microsoft platforms. Therefore, Microsoft made .NET capable of calling components using open standards, such as HTTP, XML, and the Simple Object Access Protocol (SOAP). Components exposed via SOAP, called Web Services, are callable from any platform via standard HTTP. SOAP defines how they will expose interfaces. Calls to the component, and return values from it, are in XML format.

 

This is important for two reasons. First, it gives you the ability to call components from anywhere on the Web, meaning that all your components no longer need to be behind the corporate firewall. Second, it allows you to call Web Services running on non-Microsoft machines and allows non-Microsoft clients to call your Web Services. You make the call and retrieve the XML result, regardless of the operating system or Web server of the machine hosting the Web Service.

 

For example, eBay recently announced it would use the .NET platform to expose auctions as services, allowing you to add auctions as a fully integrated part of your site. Because the data being returned is XML, you will be able to format that data to fit the look and feel of your Web application, while eBay's site does all the work. What will appear to your users as an integrated auction module on your site actually will be the full power of eBay's engine behind the scenes. This is just the beginning of the level of integration possible in this brave, new, distributed world.

 

So just what does all of this mean for ASP developers? To support the promise of the .NET Framework and the increased demands of real-world applications, changes had to be made to the underlying Active Server Pages technology. The major changes are summarized in FIGURE 3.

 

Feature	What it means for developers
Truly-compiled code	Code will run faster, and you have access to full programming languages, not interpreted scripting languages. Compiled code will realize all the benefits of the .NET run time.
Code-behind files	Allows you to separate user interface and logic code into separate files. The logic code can then be compiled.
Session state can be stored outside the IIS process	Your session state can scale across the servers in a Web farm, and can survive crashes to an individual server in the farm.
Cookie-less sessions	You can now pass the session identifier to clients without using the cookie mechanism, and this change can be made easily.
Web Forms and server controls	Web Forms make it easy to create a Web application by dragging and dropping forms (if created from Visual Studio). The server controls allow you to write code in an event-driven manner similar to standard Windows forms and controls.
ADO.NET	The objects for accessing databases have changed, and the overall paradigm is to use a disconnected model.
Web Services	Functionality will increasingly be exposed via Web Services, which will allow you to quickly build components accessible from anywhere via HTTP, SOAP, and XML.

FIGURE 3: Some of the major changes from ASP to ASP.NET.

 

Web Forms

Web Forms are the forms on which you can build the user interface of your ASP.NET application. Web Forms can be created using a text editor such as Notepad, but are also fully supported (via drag and drop) in the Visual Studio .NET integrated development environment (IDE). Visual InterDev is gone, and Web applications are now a project type available to any .NET language. Web Forms allow you to drop server controls on them and program against the server controls as you would a Visual Basic 6 Windows application. You write code using standard events, such as a button's Click event, using the compiled language of your choice.

 

Web Forms automatically detect the browser and generate the correct HTML for it, to ease the developer's burden to determine the browser and the appropriate code. Web Forms also support WYSIWYG creation to make form layout easy.

 

Server Controls

If you used Visual InterDev 6's Design Time Controls (DTCs), you might be tempted to think server controls are similar nor worthy of another look. Indeed, much of the functionality appears to be the same at first glance, but there are some important differences.

 

Normally, if you place an HTML element on a page, such as a button, it is saved as a standard HTML tag and passed directly to the browser as HTML text. Server controls, however, are .NET controls that can be placed onto a page, are exposed to the developer, and are available as objects that can be accessed through code. There are actually several different types of server controls, with the basic type being the HTML server controls. HTML server controls are translated to standard HTML tags on the client, but you can program against them on the server. For example, an HTML button server control contains properties that map to HTML attributes for the corresponding HTML tag. HTML server controls are rendered on the client as a standard HTML tag, but their appearance in the ASPX page on the server is different.

 

If you used Visual InterDev's DTCs, you know that any control you placed on the page had a block of JScript code that was saved to the page. With ASP.NET server controls, however, an HTML button server control looks something like this:

 

 

It only takes one line of code to instantiate a server control, meaning you can create server controls by using a plain text editor, unlike the DTCs in Visual InterDev 6.

 

Another kind of server control is the Web server control, a more complex type of control that is rendered as HTML but may not correspond to an HTML tag directly. For example, Microsoft includes a Calendar server control that ends up mapping to an entire table, with multiple rows and cells. Despite this more complex control, the tag you place in your ASPX page is still a single tag and looks something like this:

 

 

Server controls have another huge advantage over normal HTML controls: They can maintain their values automatically between round trips to the server. This means that even if the page is submitted to the server and reprocessed, you do not have to write all the code to pull out the existing values entered in fields and then place them back in as the page is rendered on the server. Instead, server controls do this automatically, which makes the pages much more functional and easy to create.

 

Finally, a new set of server controls, called validator controls, makes form validation much easier. If you have a field that must be filled out in order to submit the form, you can place a RequiredFieldValidator control on the form. If the user does not fill in the required field, you can notify them using any text you prefer. One of the more interesting aspects of the validator controls is that the logic can run on the client, if ASP.NET determines the client is capable of running the appropriate client-side code. If not, the validation is performed at the server. There are several different validator controls, including those to require fields, to make sure values are within a certain range, and to ensure values match a certain format.

 

With server controls, the code is simple, clean, and easy to use, unlike the DTCs from Visual InterDev.

 

Compiled Code and Code-behind Files

One of the biggest changes in ASP.NET is that the code you write is compiled. No longer are your VBScript or JScript scripts interpreted on the server. Instead, they are truly compiled into what .NET calls assemblies, the approximate equivalent of a component in COM terms.

 

ASP.NET gives you the option of storing code separate from content in what are termed code-behind files. In fact, when using Visual Studio .NET, the IDE automatically creates the code behind file for you. ASP often was criticized for having a spaghetti code look, with the HTML and script code intertwined. ASP.NET allows you to separate the user interface (HTML) code from the event-driven logic of your application. The HTML is stored in the ASPX page, such as MyForm.aspx, while the logic is stored in the code-behind file called MyForm.aspx.vb (or MyForm.aspx.cs if you are using C#). The code-behind file is compiled into a DLL file and stored on the server. When the ASPX page is requested, any necessary code is executed and only HTML is sent to the browser, as was done in ASP.

 

Being able to use the code-behind files means your ASPX file is much cleaner and easier to read, and all your logic is stored in a separate, fully compiled file. By utilizing the server controls in the ASPX file and placing the code in the code-behind file, you avoid the spaghetti code of ASP.

 

State Management

State management has been improved greatly in ASP.NET. State management on the server was handled in ASP using IIS's Session object, and this is still available in ASP.NET. However, ASP.NET makes some major improvements to how session state is maintained. ASP.NET also has some client-side state enhancements.

 

In ASP, you could store session state on one server only, because the Session object ran in process with IIS. To maintain state across a Web farm using the Session object, you had to set IP affinity on the Web farm, returning users to the same server on which they initially started their session. In effect, this destroyed some of the scalability you were hoping to gain with Web farms, and it meant that if one particular server crashed, all sessions on that server were lost. ASP.NET can continue to use this model, or you can store session state out of process to IIS. In fact, you have two out-of-process choices: You can store session state in a Windows service or in SQL Server. Either choice means session state is stored independently of any particular IIS instance and allows returning users to be routed to any server in a Web farm. Regardless of whether state is stored in process with IIS, out of process in a service, or out of process in SQL Server, the code you write to access the Session object remains the same.

 

On the client side, ASP passed the SessionID to the client via the cookie mechanism. While the cookie was memory-only (not written to disk), it still required the browser to have cookies enabled. If you want to maintain state without using cookies, you can pass the SessionID to the client now by changing a single setting in a file. Then, ASP.NET modifies all the URLs by inserting the SessionID into the URL, eliminating the need for cookies. This allows you to maintain state even if the client browser does not accept cookies. This was possible in ASP, but it was not as simple as changing one parameter in a file.

 

Finally, as has been mentioned previously, the server controls can automatically retain values between trips to the server. In fact, this is the server controls' default behavior and eliminates the work required to read all the values from the form, store them in variables, and write them back into the form when it is rendered to be sent back to the client.

 

New Database Access Technology

Microsoft introduced OLE DB and ADO about the same time that the company introduced ASP technology. .NET introduces a new database-access technology: ADO.NET. It is not built on top of OLE DB, although it can use OLE DB if it must. Instead, ADO.NET uses managed providers, which are drivers that make a direct connection to the database without the need for OLE DB. Initially, .NET will ship with just two managed providers: one for SQL Server 7.0/2000 and one for OLE DB. Expect to see more managed providers in the future.

 

ADO.NET introduces a new set of objects for working with data. Much is being written about the disconnected paradigm of ADO.NET; disconnected data makes a lot of sense in a distributed environment. However, disconnected data may or may not make sense in many ASP.NET applications. After all, most pages perform a forward-only pass through the data to render it on the page, and they have no need to hold data in memory on the server between calls. Proper use of disconnected data will allow ASP.NET applications to scale more efficiently, just as was the case with ADO.

 

ADO.NET gives you a new way to access data in a connected mode, although the access is just the forward-only, or firehose, method ASP developers favored. The DataReader object is used to read data in a forward-only manner, and the data can be manipulated and displayed on the page. Note that there is no object called DataReader, however, because each managed provider has its own. Therefore, in the first release of .NET, you will have the SqlDataReader and the OleDbDataReader.

 

Just as the server controls can make your life easier when building forms, some controls can bind directly to data. They can bind to the DataReader objects mentioned above or to the DataSet, ADO.NET's object for caching data in a disconnected manner. Using these data-bound controls can reduce significantly the time and effort required to create a data-driven Web application.

 

ADO.NET is very much XML-aware. It can read and write XML data directly, and it even stores schema information in XML Schema (XSD) format. This means you can stream data from one process to another in XML format, rather than ADO's default ADTG (advanced data tablegram) format, a binary format that typically did not flow across firewalls or proxy servers.

 

Web Services

It seems the entire computing world is jumping on the Web Services bandwagon. Not only is Microsoft pushing Web Services, but also Sun, IBM, HP and many others are touting Web services as the next big thing. As mentioned in the introduction, Web Services will enable integration between sites around the world, even if they are running disparate operating systems. Web Services will open the door to distributed computing across the Internet, thanks to open standards like XML that are text-based and flow via HTTP.

 

SOAP is an industry standard that allows for data exchange in a distributed environment. It is based on XML and uses HTTP as the protocol to transmit requests and receive data. As long as both sides talk XML, you can publish and consume Web Services.

 

.NET has inherent support for Web Services and Visual Studio .NET now supports creating a Web Service project. You write your code in much the same way as in any other .NET project, but the compiled application can be exposed over the Internet and consumed by others. The requests will come in an XML string, and the results will be sent back in XML.

 

One of the great promises of Web Services is that you might not even have to build an ASPX to deliver your Web applications. Web Services can deliver the data to anyone in XML format. This includes other Web applications as well as Web browsers, Web-enabled phones, Web-enabled PDAs, and any other device capable of making an HTTP call.

 

Conclusion

This article touches on just a few of the changes in .NET. But, as you can see, the impact is significant. ASP.NET applications take full advantage of the .NET Framework and the Common Language Runtime, including such features as memory management and security. The logic you create in your Web applications does not have to be intertwined with the HTML. The code is truly compiled into a .NET assembly for faster performance and to give you the programming power of a full language.

 

ASP.NET includes controls to make your life easier. Unlike Visual InterDev 6.0's Design-Time Controls, ASP.NET's server controls can be instantiated with a single tag. The controls generate the appropriate HTML for the target browser, and you can code against them as easily as you code against a button in VB 6. The controls have the added benefit of maintaining their values between round trips to the server.

 

Session state also is enhanced greatly, to allow you to store state outside of IIS and to give you better scalability and the benefit of maintaining state even if one server in a farm crashes. Now, Session information can be sent to the client without the use of cookies, which opens your application to more clients.

 

Web Services are one of the most exciting features of .NET, and they undoubtedly will find their way into many ASP.NET and other types of applications. The XML basis of Web Services opens them up to non-Microsoft applications and likely will lead to applications that allow your data to follow you wherever you go. If you want a future in which you can pay for an item just by pressing your thumb on a panel, .NET is a great place to start.

 

Craig Utley is a consultant, author, and trainer on Microsoft development tools and strategies. His book, A Programmer's Introduction to Visual Basic .NET, was given to all attendees at TechEd. Learn more about .NET by visiting Volant Training at http://www.volanttraining.com. Readers may contact Utley at mailto:[email protected].