- Shopping Bag ( 0 items )
Ships from: Bensalem, PA
Usually ships in 1-2 business days
Ships from: fallbrook, CA
Usually ships in 1-2 business days
Ships from: acton, MA
Usually ships in 1-2 business days
Ships from: Southampton, PA
Usually ships in 1-2 business days
|Part I||Starting the ASP.NET Journey||1|
|Chapter 1||Introducing .NET and ASP.NET||3|
|Welcome to .NET||3|
|A Closer Look at the .NET Foundation||8|
|What's New in .NET 1.1?||13|
|Chapter 2||Creating ASP.NET Applications with Visual Studio .NET||17|
|Visual Studio .NET for ASP.NET||18|
|Examining Hidden Items in Visual Studio .NET||25|
|Discovering the Power Behind the Server Explorer||33|
|Letting Visual Studio .NET Macros Do the Work for You||46|
|Chapter 3||Using the ASP.NET Web Matrix Project||51|
|Exploring the ASP.NET Web Matrix Project||52|
|Working with the Web Matrix||59|
|Extending the Web Matrix||68|
|Chapter 4||The What, Where, When, Why, and How of Controls||83|
|Why Make the Change to ASP.NET?||84|
|An Overview of ASP.NET Server Controls||85|
|HTML Server Controls||98|
|Web Server Controls||104|
|Formatting Web Server Controls||108|
|Chapter 5||Making HTML Server Controls Work for You||117|
|Creating HTML Server Controls||118|
|Playing with HTML Elements||123|
|Specific HTML Server Controls Provided by Visual Studio .NET and the Web Matrix||140|
|Chapter 6||Basic Web Controls||157|
|Introducing Web Server Controls||158|
|Displaying Text Using Web Server Controls||159|
|Form Input Web Server Controls||161|
|Form Submission Controls||189|
|Chapter 7||Understanding List Web Controls||209|
|Editing Data in a DataGrid||251|
|Chapter 8||Manipulating Rich Web Controls||273|
|Using the Calendar Control||274|
|The AdRotator Control||290|
|Chapter 9||Taking Advantage of Validation Server Controls||295|
|.NET to the Rescue!||298|
|Chapter 10||User Controls: Building Reusable Pieces of Code||329|
|Introducing User Controls||330|
|Building a Simple User Control||331|
|Creating a Navigation User Control||337|
|Exposing Properties and Methods from User Controls||341|
|Dynamically Loading User Controls||347|
|Creating User Controls Using the Code-Behind Technique||354|
|Chapter 11||Building Custom Controls||363|
|Creating Custom Controls with the Control Class||364|
|Creating Custom Controls Using the WebControl Class||375|
|Building a Composite Control||379|
|Raising Events from Controls||385|
|Creating a Templated Control||385|
|Causing Client-Side Postback from a Server Control||393|
|Using a Custom Control in Visual Studio .NET||399|
|Part III||Applications as a Whole||401|
|Chapter 12||An In-Depth Look at the .aspx Page||403|
|The Languages of Your Pages||404|
|Understanding Inline Versus Code-Behind||408|
|Working with ASP.NET Directives||417|
|Working with Page Events||425|
|Understanding the Page Lifecycle||426|
|Understanding the Page Class||428|
|Chapter 13||Understanding the Entire Application||431|
|Hosting Applications on a Server||432|
|A Visual Studio .NET ASP.NET Application||440|
|Versioning and Runtimes||441|
|Looking at Global.asax||447|
|Chapter 14||Debugging ASP.NET Pages and Handling Exceptions||453|
|Debugging ASP.NET Web Applications||454|
|Handling Exceptions in an ASP.NET Web Application||472|
|Chapter 15||Controlling Security for Your ASP.NET Applications||483|
|Authentication, Authorization, and Impersonation||484|
|Overview of Authentication in ASP.NET||485|
|Chapter 16||Packaging and Deploying Your ASP.NET Applications||509|
|Introduction to Setup and Deployment||510|
|Structure of an ASP.NET Web Application||510|
|Deployment Options Supported by .NET||511|
|COM Interop: Using COM within .NET||528|
|Using .NET from Unmanaged Code||542|
|Chapter 18||Networking: Understanding E-mail in .NET||553|
|Overview of E-mail||554|
|E-mailing a Web Page||563|
|Sending International E-Mails||569|
|Building Your Own SmtpClient Component||575|
|Chapter 19||Networking: Understanding File I/O in .NET||597|
|Overview of the System.IO Namespace||598|
|Manipulating Text Files||603|
|Manipulating Binary Files||605|
|Reading and Writing Data Asynchronously||607|
|Part IV||ASP.NET and Data||615|
|Chapter 20||Understanding ADO.NET||617|
|Realizing the Dream of Common Database Access||618|
|Picking a .NET Data Provider||619|
|Making Your Connection||621|
|Retrieving and Displaying Data with a DataReader||632|
|Calling Stored Procedures||639|
|The Disconnected Database: DataAdapter and DataSet||644|
|Chapter 21||Rendering and Data Binding with ADO.NET Objects||649|
|Data Binding with ASP.NET Server Controls||650|
|Implementing Sorting and Paging Using a DataGrid Control||663|
|In-Place Editing of a DataGrid||667|
|Embedding One DataGrid within Another DataGrid Control||673|
|Chapter 22||XML and ADO.NET||681|
|XML Support Provided by the DataSet Object||682|
|The XmlDataDocument Object and ADO.NET||693|
|Retrieving XML Data Directly from SQL Server||705|
|Chapter 23||XML Namespaces||709|
|XML Support in .NET Framework||710|
|Part V||Performance and Optimization||739|
|Chapter 24||Configuring Your Applications||741|
|Configuration File Locations and Meanings||742|
|Configuration File Structure||743|
|Categories and Settings||745|
|Consolidating and Locking Down Configuration Settings||756|
|Chapter 25||Applying Caching and Other Performance Enhancements||761|
|Understanding the Different Types of Caching||763|
|Creating a Callback Method for a Cached Item||788|
|Using Performance Counters Related to Caching||794|
|Chapter 26||State Management Techniques and Their Consequences||797|
|Introducing State Management||798|
|Client-Side State Management||798|
|Server-Side State Management||810|
|Part VI||XML Web Services||821|
|Chapter 27||Understanding the Basics of XML Web Services||823|
|XML, SOAP, and HTTP||825|
|Understanding the Problems That XML Web Services Address||826|
|The Composition of XML Web Services||827|
|Viewing and Testing XML Web Services||838|
|The Business of XML Web Services||849|
|Chapter 28||Building and Consuming XML Web Services||853|
|Building a Simple XML Web Service||854|
|Consuming an XML Web Service||860|
|From One XML Web Service to Another||879|
|Throwing SOAP Exceptions||883|
|Caching XML Web Services||885|
|Application Center Test (ACT)||887|
|Chapter 29||Taking XML Web Services One Step Farther||897|
|Asynchronous XML Web Services||898|
|Sending Images in Your SOAP Messages||903|
|Working with SOAP Headers||910|
|Tracing SOAP Messages||924|
|Chapter 30||Getting What You Need by Screen Scraping||929|
|Screen Scraping Niceties 101||930|
|The Screen Scraping Process||930|
|Stock Quote Example||931|
|The Delicate Nature of Screen Scraping||942|
|Building a Consuming Application||943|
|Part VII||Mobile Development||951|
|Chapter 31||Building Wireless Applications||953|
|Online and Offline Applications||954|
|Mobile Application Development Challenges||955|
|Mobile Application Development Process||956|
|Chapter 32||Uncovering the Secrets of Mobile Controls||971|
|Chapter 33||Advanced Techniques for Building Mobile Applications||1001|
|Examining the ObjectList Control||1002|
|Examining the PhoneCall Control||1011|
|Providing a Common Look and Feel||1014|
|Writing Device-Specific Code||1025|
|Appendix A||Language Lookup: Visual Basic .NET||1033|
|Appendix B||Language Lookup: C#||1055|
|Appendix C||ASP.NET Resources||1079|
by Bill Evjen
If you are new to .NET-Welcome!
If you are a .NET Framework 1.0 veteran-Welcome to .NET version 1.1!
.NET 1.0 was introduced with tremendous excitement. It was original, answered many developers' problems, and truly leap-frogged any of the other technologies out there-especially in the realm of browser-based Internet application development-or ASP.NET.
.NET 1.1 and ASP.NET 1.1 are minor releases and should not be considered substantially different versions from 1.0. The next major revision of .NET and ASP.NET will come with the release of version 2.0.
This chapter introduces the .NET Framework 1.1 and also shows you what's new in ASP.NET 1.1.
Welcome to .NET
Every so often, a technology company needs to step back from itself, look at what it is trying to achieve, and then determine whether it needs to try a different approach. Microsoft did this as it stood back from the COM world it had created and asked itself, "Is there a better way?" The .NET Framework is this better way.
.NET is confusing to many people because the Microsoft marketing folks took hold of the name and started applying it to every product that Microsoft produced. .NET had almost nothing to do with many products that acquired the.NET moniker. This problem is slowly being corrected. More products are now coming from Microsoft without .NET in their titles.
Microsoft's short definition of .NET is Microsoft's platform for building XML Web services. But the .NET that I am talking about (and the .NET that you should be focused on understanding) is the .NET Framework itself.
Microsoft's .NET Framework is a new computing platform built with the Internet in mind, but without sacrificing the traditional desktop application platform. The Internet has been around for a number of years now, and Microsoft has been busy developing technologies and tools that are totally focused on it. These earlier technologies, however, were built on Windows Distributed InterNet Applications Architecture (DNA), which was based on the Component Object Model (COM). Microsoft's COM was in development many years before the Internet became the force that we know today. Consequently, the COM model has been built upon and added to in order to adapt it to the world of the Internet.
The .NET Framework enabled Microsoft to build everything from the ground up with the Internet in mind. Therefore, the .NET Framework focuses heavily on Internet-enabling your applications, whether these applications are thin-client or thick-client applications. Building a new platform from the ground up also allowed Microsoft to take a close look at how developers developed. Even more importantly, Microsoft began examining how to correct the problems developers experience and how to make them more productive in this new environment.
.NET is a collection of tools, technologies, and languages that all work together in a framework to provide the solutions necessary for easily building and deploying truly robust enterprise applications. These .NET applications can also communicate with one another and provide information and application logic, regardless of platforms and languages.
You might have seen this simple diagram of the .NET Framework before, but take a closer look at it now. Consider the .NET Framework as something that sits on an operating system. Presently, the operating systems that can take the .NET Framework include Windows Server 2003, Windows XP Professional, Windows 2000, and Windows NT.
Support for the .NET Framework on Windows NT is limited to functioning as a client. Windows NT does not support the Framework as a server.
At the bottom layer of the .NET Framework is the Common Language Runtime (CLR). The CLR is the engine that manages the execution of the code, takes care of object management, provides security, and so much more.
The next layer up from the CLR is the .NET Framework Base Class Libraries (BCL). The BCL layer contains classes, value types, and interfaces that are often used in the development process. The many classes in the BCL are organized into a series of namespaces.
The third layer of the .NET Framework includes the Windows Forms model (more on that shortly), along with the area that is the primary focus of this book-ASP.NET. Don't think of ASP.NET as the latest version of Active Server Pages-the one that comes after ASP 3.0. Instead, think of it as a dramatic new shift in Web application development. Using ASP.NET, it's now possible to build robust Web applications that are even more functional than Win32 applications of the past, a difficult feat because of the stateless nature of the Internet. ASP.NET offers a number of different solutions to overcome the traditional limitations on the types of possible applications. The ASP.NET section of the .NET Framework is also where the XML Web services model resides.
As I mentioned a moment ago, ASP.NET shares the top layer of the .NET Framework with Windows Forms applications. These are the traditional .exe applications, or Win32 thick-client applications. The programming models of the ASP.NET world and the Windows Forms world are quite similar, and these two models use the same objects from the Framework to accomplish their tasks. If you become a good ASP.NET programmer, you also become a good Windows Forms programmer. Interestingly enough, because the models are so similar, you can build a class that you can use in either your ASP.NET application or in a Windows Forms application.
Looking to the future
The .NET Framework is focused on how people will use technology in the future. One view (held not only by Microsoft) says that all devices and applications will one day be connected to the Internet. When this day arrives, people won't use the Internet just for the browser-based applications as they currently do, but also for telephones, televisions, microwaves, Xbox and PlayStation units, and much more (see Figure 1-2). All these devices connected by the Internet can't possibly be built on a single platform. The world will continue to have multiple platforms and languages at its disposal for a long time to come. Consequently, we need a common language that can communicate with the various platforms, applications, and devices.
XML and SOAP are the common languages now facilitating communication among platforms, applications, and devices. By using these languages, devices can communicate over the Internet in an easy and straightforward manner.
Microsoft enables you to start bringing this disparate but connected vision to reality with the .NET Framework. By building XML Web services, you are expressing objects and using XML and SOAP to communicate the object's data or the application logic that it might provide.
XML Web services are considered part of the ASP.NET model and are covered in Part VI of this book.
You can also use your ASP.NET applications to consume data or application logic from other Web services on the Internet, regardless of the language or platform used in the creation of these Web services. Over time, more and more connections of applications with remote objects will use the XML Web services model in the .NET Framework.
Microsoft's .NET solution
Because of the prospect that the universe of devices and applications will be placed on the same medium and will be able to communicate with one another using a common language, Microsoft developed the .NET Framework. Developers using this platform can build their applications to take advantage now of this vision of the future.
Before the .NET Framework came along in 2002, Microsoft offered quite a number of tools and technologies for building a wide variety of applications. As a developer, you could choose the environment, language, or tool appropriate for what you were trying to accomplish.
For example, if you wanted to quickly build a thick-client application, you used Visual Basic. If you wanted to build low-level applications that gave you granular access to the platform, you used C++. If you wanted to build browser-based applications, you used Active Server Pages (ASP).
With the .NET Framework, Microsoft has taken the best of all these different worlds and merged them into a single environment-the .NET world, as shown in Figure 1-3.
Because of this new unified model, you need only one environment, one platform, and any .NET language to build any .NET application. It doesn't matter if the application is a desktop application, a browser-based application, a component, or even a driver. You now have a single environment to do all this work.
One of the main objectives of the Framework is to provide a simplified development model that eliminates a lot of the plumbing required to develop in the past. The .NET Framework gives developers more power over their applications. This framework uses the latest in Internet standards such as XML, SOAP, and HTTP. The applications that you build on this platform are easier to deploy and maintain.
Instead of multiple development environments for building various types of applications, Microsoft provides a single development environment to build any type of .NET application. This development environment is Visual Studio .NET. It's the development environment that I recommend you use with this book as you build and work with your .NET applications.
Visual Studio .NET enables you to build your ASP.NET applications in a code-only manner (writing code directly) or by dragging and dropping objects onto a design surface. You can also use Visual Studio .NET to build thick-client applications or Windows Forms and to build your classes, components, and everything else you need.
Another development environment offered by Microsoft is the ASP.NET Web Matrix. This free tool is available from the ASP.NET Web site at asp.net. It is a great tool to help you get a feel for building Web applications. Unlike Visual Studio .NET, however, the ASP.NET Web Matrix limits you to building only ASP.NET applications and XML Web services. You can't build any Windows Forms applications using the Web Matrix.
You learn about the Visual Studio .NET environment in Chapter 2 and the ASP.NET Web Matrix environment in Chapter 3.
Besides these two Microsoft IDEs, other IDEs are capable of building .NET applications. One of the more popular development environments is Macromedia's Dreamweaver MX. This IDE enables you to build ASP.NET applications as well as many other types, such as PHP and ColdFusion applications.
You can also build ASP.NET applications by using Notepad and the compilers provided with the .NET Framework. In fact, you can type much of the code from this book into Notepad to build your ASP.NET applications.
The .NET languages
When developing on the Microsoft platform in the past, you chose the development language based on the type of application you wanted to build.
The .NET Framework has completely changed this scenario for us. The .NET Framework enables you to build any type of application or object that can be used in the .NET platform, and you can also use any of the .NET languages to build these applications.
For a language to be part of the .NET Framework, a language has to follow certain rules. The biggest and most important rule for inclusion is that the language must be an object-oriented language. Microsoft provides five languages with the .NET Framework: Visual Basic .NET, C#, C++.NET, JScript .NET, and now J#.
You now have a choice of which language you are going to use to build your ASP.NET applications. For instance, you are not limited to just using Visual Basic .NET to build your browser-based applications; you can also use C#, JScript .NET, or even J# to build a Web-based application.
Whenever this idea is presented, people always ask: Which is the better language to use? Does one language provide better performance than another?
The answer to both these questions is an emphatic NO. There isn't one language that is better than another. They all have access to the same classes and capabilities that are provided with the .NET Framework. If there is no difference in which language you can use to build your .NET applications, it then becomes simply a matter of style when deciding which of the languages to use.
In addition to the languages that are provided with the install of the .NET Framework 1.1, quite a number (more than 40) of third-party languages are capable of being used in the .NET platform to build your .NET applications. For instance, you can also build ASP.NET applications using COBAL or Perl. To use either of these applications, however, you must install the language yourself because neither is provided with the default install of the .NET Framework.
This book focuses on the two most popular .NET languages: Visual Basic .NET and C#.
A Closer Look at the .NET Foundation
The foundation of the .NET platform is the .NET Framework, which I introduced in the preceding section. The .NET Framework sits on top of the operating system and is made up of two parts, the Common Language Runtime and the Base Class Libraries. Each of these parts plays an important role in the development of .NET applications and services.
The Common Language Runtime
Many different languages and platforms provide a runtime, and the .NET Framework is no exception. Its runtime, however, is quite different from most.
The Common Language Runtime (CLR) in the .NET Framework manages the execution of the code and provides access to a variety of services that make the development process easier.
The CLR has been developed to be far superior to previous runtimes, such as the VB runtime, by providing the following functionality:
* Cross-language integration
* Code access security
* Object lifetime management
* Debugging and profiling support
Code that is compiled and targeted to the CLR is known as managed code. Managed code has the metadata needed for the CLR to provide the services of multilanguage support, code security, object lifetime management, and memory management.
Metadata is basically data about data or a description of the contents of a .NET component. This metadata is stored within the assembly manifest. In the past, it was difficult for components written in competing languages to interact with one another. The .NET Framework uses metadata so that .NET components are self-describing, making them easy to interoperate with other components.
Compilation to managed code
When creating a .NET application, use one of the .NET languages. After the code is written, you (or Visual Studio .NET) uses the language's compiler to compile the code down to Microsoft Intermediate Language (IL).
Excerpted from ASP.NET Professional Secrets by Bill Evjen Thiru Thangarathinam Bill Hatfield Doug Seven Srinisava Sivakumar Dave Wanta Jason T. Roff Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.