ASPNET是什么(计算机专业外文翻译)

英文文献及中文翻译 Overview is a unified Web development model that includes the services necessary for you to build enterprise-class Web applications with a minimum of is part of the .NET Framework, and when coding applications you have access to classes in the .NET Framework.You can code your applications in any language compatible with the common language runtime (CLR), including Microsoft Visual Basic and C#. These languages enable you to develop applications that benefit from the common language runtime, type safety, inheritance, and so on.If you want to try , you can install Visual Web Developer Express using the Microsoft Web Platform Installer, which is a free tool that makes it simple to download, install, and service components of the Microsoft Web Platform.These components include Visual Web Developer Express, Internet Information Services (IIS), SQL Server Express, and the .NET Framework. All of these are tools that you use to create Web applications. You can also use the Microsoft Web Platform Installer to install open-source and PHP Web applications.Visual Web DeveloperVisual Web Developer is a full-featured development environment for creating Web applications. Visual Web Developer provides an ideal environment in which to build Web sites and then publish them to a hosting site. Using the development tools in Visual Web Developer, you can develop Web pages on your own computer. Visual Web Developer includes a local Web server that provides all the features you need to test and debug Web pages, without requiring Internet Information Services (IIS) to be installed.Visual Web Developer provides an ideal environment in which to build Web sitesand then publish them to a hosting site. Using the development tools in Visual Web Developer, you can develop Web pages on your own computer. Visual Web Developer includes a local Web server that provides all the features you need to test and debug Web pages, without requiring Internet Information Services (IIS) to be installed.When your site is ready, you can publish it to the host computer using the built-in Copy Web tool, which transfers your files when you are ready to share them with others. Alternatively, you can precompile and deploy a Web site by using the Build Web Site command. The Build Web Sitecommand runs the compiler over the entire Web site (not just the code files) and produces a Web site layout that you can deploy to a production server.Finally, you can take advantage of the built-in support for File Transfer Protocol (FTP).Using the FTP capabilities of Visual Web Developer, you can connect directly to the host computer and then create and edit files on the server. Web Sites and Web Application ProjectsUsing Visual Studio tools, you can create different types of projects, which includes Web sites, Web applications, Web services, and AJAX server controls.There is a difference between Web site projects and Web application projects. Some features work only with Web application projects, such as MVC and certain tools for automating Web deployment. Other features, such as Dynamic Data, work with both Web sites and Web application projects.Page and Controls FrameworkThe page and controls framework is a programming framework that runs on a Web server to dynamically produce and render Web pages. Web pages can be requested from any browser or client device, and renders markup (such as HTML) to the requesting browser. As a rule, you can use the samepage for multiple browsers, because renders the appropriate markup for the browser making the request. However, you can design your Web page to target a specific browser and take advantage of the features of that browser. Web pages are completely object-oriented. Within Web pages you can work with HTML elements using properties, methods, and events. The page framework removes the implementation details of the separation of client and server inherent in Web-based applications by presenting a unified model for responding to client events in code that runs at the server. The framework also automatically maintains the state of a page and the controls on that page during the page processing life cycle.The page and controls framework also enables you to encapsulate common UI functionality in easy-to-use, reusable controls. Controls are written once, can be used in many pages, and are integrated into the Web page that they are placed in during rendering.The page and controls framework also provides features to control the overall look and feel of your Web site via themes and skins. You can define themes and skins and then apply them at a page level or at a control level.In addition to themes, you can define master pages that you use to create a consistent layout for the pages in your application. A single master page defines the layout and standard behavior that you want for all the pages (or a group of pages) in your application. You can then create individual content pages that contain the page-specific content you want to display. When users request the content pages, they merge with the master page to produce output that combines the layout of the master page with the content from the content page. The page framework also enables you to define the pattern for URLs that will be used in your site. This helps with search engine optimization (SEO) and makes URLs more user-friendly.The page and control framework is designed to generate HTML thatconforms to accessibility guidelines. CompilerAll code is compiled, which enables strong typing, performance optimizations, and early binding, among other benefits. Once the code has been compiled, the common language runtime further compiles code to native code, providing improved performance. includes a compiler that will compile all your application components including pages and controls into an assembly that the hosting environment can then use to service user requests.Security InfrastructureIn addition to the security features of .NET, provides an advanced security infrastructure for authenticating and authorizing user access as well as performing other security-related tasks. You can authenticate users using Windows authentication supplied by IIS, or you can manage authentication using your own user database using forms authentication and membership. Additionally, you can manage the authorization to the capabilities and information of your Web application using Windows groups or your own custom role database using roles. You can easily remove, add to, or replace these schemes depending upon the needs of your application. always runs with a particular Windows identity so you can secure your application using Windows capabilities such as NTFS Access Control Lists (ACLs),database permissions, and so on.State-Management Facilities provides intrinsic state management functionality that enables you to store information between page requests, such as customer information or the contents of a shopping cart. You can save and manage application-specific, session-specific, page-specific, user-specific, and developer-defined information. This information can beindependent of any controls on the page. offers distributed state facilities, which enable you to manage state information across multiple instances of the same application on one computer or on several computers. 概述是一个统一的Web开发模型，它包括您使用尽可能少的代码生成企业级Web应用程序所必需的各种服务。

Extreme 1.1Web Deployment ProjectsWhen ASP was first released, Web programming was more difficult because you needed IIS to serve your ASP pages. Later, 2.0 and Visual Studio® 2005 made everything easier by introducing the Web site model of development. Instead of creating a new project inside Visual Studio, the Web site model lets you point to a directory and start writing pages and code. Furthermore, you can quickly test your site with the built-in Development Server, which hosts in a local process and obviates the need to install IIS to begin developing. The beauty of the Web site model is that you can develop your Web application without thinking about packaging and deployment. Need another class? Add a .cs file to the App_Code directory and start writing. Want to store localizable strings in a resource file? Add a .resx file to the App_GlobalResources directory and type in the strings. Everything just works; you don't have to think about the compilation and deployment aspect at all.When you are ready to deploy, you have several options. The simplest choice is to copy your files to a live server and let everything be compiled on-demand (as it was in your test environment). The second option is to use the aspnet_compiler.exe utility and precompile the application into a binary release, which leaves you nothing but a collection of assemblies, static content, and configuration files to push to the server. The third option is to again use aspnet_compiler.exe, but to create an updateable binary deployment where your .as*x files remain intact (and modifiable) and all of your code files are compiled into binary assemblies.This seems to cover every possible scenario, leaving the developer to focus simply on writing the Web application, with packaging and deployment decisions to be made later when the application is actually deployed. There was a fair amount of backlash against this model, however, especially from developers who were used to their Web projects being real projects, specified in real project files, that let you inject pre-and post-build functions, exclude files from the build process, move between debug and release builds with a command-line switch, and so on. In response, Microsoft quickly introduced the Web Application Project or WAP, initially released as an add-in to Visual Studio 2005, and now included in Visual Studio 2005 Service available for download from /vstudio/support/vs2005sp1.WAP provides an alternative to the Web site model that is much closer to the Visual Studio .NET 2005 Web Project model. The new WAP model compiles all of the source code files during the build process and generates a single assembly in the local /bin directory for deployment. WAP also makes it much easier to incrementally adopt the new partial class codebehind modelintroduced in 2.0 because you can now open a Visual Studio .NET 2003 project and only your .sln and .csproj (or .vbproj) files will be modified during the conversion. You can then convert each file and its codebehind class to the new partial class model independently of any other file in the project (by right-clicking on the file in the Solution Explorer and selecting Convert to Web Application), or just leave them using the old model. This is in contrast to converting a Visual Studio .NET 2003 Web project to the Web site model, which converts all files at once and does not support incremental adoption.Finally, there is a new project type called Web Deployment Projects (the main topic of this column), which introduces myriad additional deployment options for both Web site projects and Web Application Projects. Web Deployment Projects fill the remaining holes in the deployment options for both Web site apps and Web Application Projects and make it possible to implement practically any deployment scenario in a simple and extensible way. To understand exactly what this new project type adds, let's first review what we had before Web Deployment Projects were available.When you build an application using the Web site model, you have the option of precompiling the site for deployment. You can access the precompilation utility through the Build | Publish menu in Visual Studio 2005 or directly through the command-line utility aspnet_compiler.exe. Figure 1 shows the interface to this tool exposed by Visual Studio.The first decision you have to make when using the publish utility is whether you want your .as*x files to be updatable once deployed (use the "Allow this precompiled site to be updatable" option of -u switch in the aspnet_compiler.exe command-line utility). This decision hinges on whether you want to be able to make minor changes to your pages once deployed without having to go through the entire deployment process again. You may, in fact, want to explicitly disallow any modifications to the deployed pages and require that all modifications go through the standard deployment (and hopefully testing) process, in which case publishing the site as not updatable is the proper choice.When a site is published as not updatable, it is possible to completely remove all .as*x files and publish only binary assemblies (plus configuration files and static content). However, without the physical files in place, it is impossible for to tell which classes to use for which endpoint requests. For example, if a request comes into your application for Page1.aspx and you have used non-updatable binary deployment, there very well may not be any Page1.aspx file on disk, and there is nothing in the existing configuration files to indicate which class in the collection of assemblies deployed to the /bin directory should actually be the handler for this request. To remedy this, the compilation process will also generate a collection of .compiled filesthat contain endpoint-to-type mapping and file dependency information in a simple XML format, and these files must be published along with the binary assemblies in the /bin directory of the deployed site. As an example, if you did have a page named Page1.aspx in your application, the aspnet_compiler.exe utility would generate a file named piled (with the hash code varying) that contained the following XML:<?xml version="1.0" encoding="utf-8"?><preserve resultType="3"virtualPath="/SampleWebSite/Page1.aspx"hash="8a8da6c5a" filehash="42c4a74221152888"flags="110000" assembly="App_Web_aq9bt8mj"type="ASP.page1_aspx"><filedeps><filedep name="/SampleWebSite/Page1.aspx" /><filedep name="/SampleWebSite/Page1.aspx.cs" /></filedeps></preserve>The other major decision you have to make when publishing a Web site with this utility is the granularity of the packaging of the generated assemblies. You can either create a separate assembly for each directory in your site or create a separate assembly for each compilable file in your site (.aspx, .ascx, .asax, and so on.) by checking the Use fixed naming and single page assemblies (or -fixednames in the aspnet_compiler.exe command-line utility). This decision is not as obvious as you might think, as each option has its own potential issues. If you elect to not use the -fixednames option, then every time you publish your application a completely new set of assemblies will be generated, with completely different names from the ones published earlier. This means that deployment is trickier because you must take care to delete all of the previously published assemblies on the live server before deploying the new assemblies or you'll generate redundant class definition errors on the next request. Using the -fixednames option will resolve this problem as each file will correspond to a distinctly named assembly that will not change from one compilation to the next. If you have a large site, however, generating a separate assembly for each page, control, and Master Page can easily mean managing the publication of hundreds of assemblies. It is this problem of assembly granularity in deployment that Web Deployment Projects solve in a much more satisfying way, as you will see.You can also introduce assembly signing into the compilation process to create strong-named, versioned assemblies, suitable for deployment in the Global Assembly Cache(GAC) if needed. You can mark the generated assemblies with the assembly-level attribute AllowPartiallyTrustedCallers using the -aptca option, which would be necessary if you did deploy any assemblies to the GAC and were running at a low or medium level of trust. (Keep in mind that this attribute should only be applied to assemblies that have been shown not to expose any security vulnerabilities, as using it with a vulnerability could expose a luring attack.) One other detail about publishing your site is that if you do elect to use Web Application Projects instead of the Web site model, the Build | Publish dialog box will look quite different, as shown in Figure 2. Web Application Projects assume that you want to publish the application as updatable .as*x files and precompiled source files (the same model it uses in development), so the binary-only deployment options are not available. This utility is really closer in nature to the Copy Web site utility available with Web sites than it is to the Publish Web Site utility since it involves copying files produced by the standard build process.Technically you are not restricted from using binary-only (non-updatable) deployment, even if you are using Web Application Projects. If you think about it, the output of the build of a WAP is a valid Web site, which you can then pass through the aspnet_compiler.exe utility to generate create a binary deployment. You just can't invoke it from the Visual Studio 2005 interface which, fortunately, Web Deployment Projects rectify.So what's missing from the existing compilation and deployment options presented so far? Primarily two things: the ability to control the naming of assemblies, especially for deployment purposes, and the ability to consolidate all of the output assemblies into a single assembly for simplified deployment. Web Deployment Projects solve both of these problems. Perhaps even more significantly, however, they also tie up a lot of loose ends in the deployment story that existed with Web site applications and Web Application Projects.At their core, Web Deployment Projects (available for download at /aa336619.aspx) represent just another type of project you add to your solution. Like all Visual Studio project files, Web deployment projects are MSBuild scripts that can be compiled directly in the IDE or run from the command line. Instead of specifying a collection of source code files to compile, however, Web Deployment Projects contain build commands to compile and package Web sites (or Web Application Projects). This means that they will invoke the aspnet_compiler.exe utility (among others) to create a deployment of a particular Web application. Web Deployment Projects are shipped as a Visual Studio add-in package that includes an easy-to-use menu item for injecting new projects and a complete set of property pages to control all of the available settings. To add one to an existing application, right-click on an existing Web site (or Web Application Project) and select the Add Web Deployment Project itemas shown in Figure 3. This will add a new .wdproj file containing an MSBuild script to your solution, which will generate a deployment of the application you created it from.Once the Web Deployment Project is part of your solution, you can access the property pages of the project file to control exactly what the project does for you, as shown in Figure 4. The default setting for a new deployment project is to deploy the application in updatable mode, with all the .as*x files intact, and the source files compiled into a single assembly deployed in the top-level /bin directory. These deployment projects work the same regardless of whether the source application is using the Web site model or the Web Application Project model, which means that you can now select either development model without impacting your deployment options. One of the most significant features of Web Deployment Projects is the ability to configure the deployment to be all binary (not updatable) in the form of a single assembly, the name of which you can choose. Using this model of deployment means that you can update your entire site merely by pushing a single assembly to the /bin directory of your live site, and not concern yourself with deleting existing assemblies prior to deploying or dealing with a partially deployed site causing errors. It is still necessary to deploy the .compiled files for the endpoint mappings, but these files only change when you add, delete, or move pages in your site.Web Deployment Projects provide flexibility in deployment and let you make packaging and deployment decisions independently of how you actually built your Web applications. This independence between development and deployment was partially achieved in the original release of 2.0 with the aspnet_compiler.exe utility, but never fully realized because of the constraints imposed when performing the deployment. With Web Deployment Projects, the separation between development and deployment is now complete, and your decision about how to build your applications will no longer impact your deployment choices.Merging AssembliesMuch of what Web Deployment Projects provide is just a repackaging of existing utilities exposed via MSBuild tasks and a new interface, but there are also a couple of completely new features included. The most intriguing is the ability to merge assemblies.When you install Web Deployment Projects, you will find an executable called aspnet_merge.exe in the installation directory. This executable is capable of taking the multi-assembly output of a precompiled site and merging the assemblies into one. This is the utility that is incorporated into your build script if you select the merge option in a Web Deployment Project. As an example of what is possible with this utility, consider the output of a precompiled Web site, run without the updatable switch, shown in Figure 5. The source application for this output contained two subdirectories, a top-level global.asax file, a classdefined in App_Code, and a user control. The end result of the compilation is five different assemblies and a collection of .compiled files. If you run the aspnet_merge.exe utility on this directory with the -o switch to request a single assembly output, shown at the bottom of Figure 5, the result is a much more manageable single assembly named whatever you specify.Although the aspnet_merge.exe utility and the corresponding MSBuild task that ship with Web Deployment Projects are new, the underlying technology for merging assemblies has actually been around since the Microsoft® .NET Framework 1.1 in the form of a utility made available from Microsoft Research called ILMerge, the latest version of which is available for download from /~mbarnett/ILMerge.aspx. This utility is directly incorporated into aspnet_merge.exe and does all the heavy lifting involved with merging assemblies. If you think about it, the merging of assemblies is a rather complicated task. You need to take into consideration signing, versioning, and other assembly-level attributes, embedded resources, and XML documentation, as well as manage the details of clashing type names, and so on. The ILMerge utility manages all of these details for you, with switches to control various decisions about the process. It also gives you the ability to transform .exe assemblies into .dll assemblies for packaging purposes. As an example, suppose you have three assemblies: a.dll, b.dll, and c.exe which you would like to merge into a single library assembly. As long as there were no conflicts in typenames, the following command line would generate a new library, d.dll with all of the types defined in a.dll, b.dll, and c.exe:ilmerge.exe /t:library /ndebug /out:d.dll a.dll b.dll c.exePluggable Configuration FilesThe other completely new feature that comes with Web Deployment Projects is the ability to create pluggable configuration files. It is a common problem when deploying Web applications to find a way to manage the differences in your configuration files between development and deployment. For example, you may have a local test database to run your site, have another database used by a staging server, and yet another used by the live server. If you are storing your connection strings in web.config (typically in the connectionStrings section), then you need some way of modifying those strings when the application is pushed out to a staging server or to a production machine. Web Deployment Projects offer a clean solution to this problem with a new MSBuild task called ReplaceConfigSections.This task allows you to specify independent files that store the contents of a particular configuration section independently based on solution configurations. For example, you might create a debugconnectionstrings.config file to store the debug version of our connectionStrings configuration section that looked like this:<connectionStrings><add connectionString="server=localhost;database=sales;trusted_connection=yes" name="sales_dsn"/> </connectionStrings>Similarly, you would then create separate files for each of the solution configurations defined (release, stage, and so on) and populate them with the desired connection strings for their respective deployment environments. For the release configuration, you might name the file releaseconnectionstrings.config and populate it as follows:<connectionStrings><add connectionString="server=livedbserver;database=sales;trusted_connection=yes"name="sales_dsn"/></connectionStrings>Next, you would configure the MSBuild script added by Web Deployment Projects to describe which configuration sections in the main web.config file should be replaced, and the source files that will supply the content for the replacement. You could modify the script by hand, but there is a nice interface exposed through the property pages of the build script in Visual Studio that will do it for you, as Figure 6 shows. In this case, you are setting the properties for the debug solution configuration, so check the Enable Web.config file section replacement option and specify the section to be replaced along with the file with the contents to replace it: You would use this same dialog page to set the configuration replacement for the Release solution configuration (and any others we had defined) with the corresponding files.When you then run the build script, the ReplaceConfigSections task extracts the contents from any associated config files and replaces the contents of the corresponding configuration section, creating a new web.config file that is pushed to the deployment directory. This configuration file replacement feature means that you can maintain configuration differences between deployment environments in a manageable way with text files that can be versioned under source control, and you don't have to resort to referring to that sticky note reminding you to change the connection string when you deploy. It should be emphasized that this feature works with any section of the configuration file, even custom sections, so if you have differences in other configuration sections (for example, appSettings) you can easily specify those differences with this build task as well.Creating Reusable User ControlsThere is an interesting side application of Web deployment projects that solves a problem that has plagued developers for years-how to create reusable user controls to share across applications. User controls are fundamentally just composite custom controls whose child controls are laid out in an .ascx file. The ability to use the designer for laying out controls and adding handlers is a huge benefit for most developers since it feels almost identical to building a page, except that the resulting .ascx file can be included as a control in any page. The disadvantage has always been that you need the physical .ascx file in the application's directory to actually use it. Techniques for making .ascx controls shareable across applications are available, but they usually involve chores like creating shared virtual directories between applications or harvesting temporary assemblies generated by at request time, and they've never been satisfactory.The introduction of the aspnet_compiler.exe utility in version 2.0 brought us much closer to a decent solution. With the compiler, you can create a Web site consisting of only user controls and publish the site in non-updateable mode using the compiler to generate reusable assemblies. Once you have the resulting assembly (or assemblies), you can then deploy to any Web application and reference the user control just as you would a custom control (not by using the src attribute as you would for .ascx files). The only disadvantage to this technique is that you either have to accept the randomly named assembly produced by the compilation process or select the fixednames option in the compiler to generate a fixed named assembly for each Master Page in the site (not a single assembly for the entire collection).Web Deployment Projects provide the final step to create truly reusable user control assemblies. You can take the same Web site consisting exclusively of user controls and add a Web Deployment Project to create a single output assembly with the name of your choice. It's even straightforward to create a signed assembly to deploy to the GAC for sharing controls across multiple applications without redeploying the assembly in each /bin directory.ConclusionThe release of Web Deployment Projects completes the set of tools for deploying applications in a very satisfying way. It is now possible to deploy your applications in any manner ranging from all source to all binary, with complete control over the generation, packaging, and naming of the binary assemblies. In addition, Web Deployment Projects provide a solution for replacing sections of your configuration files based on your target build, and they solve the problem of distributing reusable user controls. Anyone who is building and deploying applications will undoubtedly find some aspect of Web Deployment Projects compelling enough to begin using them today.2.1 Client-Side Web Service Calls with AJAX ExtensionsSince its inception, has fundamentally been a server-side technology. There were certainly places where would generate client-side JavaScript, most notably in the validation controls and more recently with the Web Part infrastructure, but it was rarely more than a simple translation of server-side properties into client-side behavior-you as the developer didn't have to think about interacting with the client until you received the next POST request. Developers needing to build more interactive pages with client-side JavaScript and DHTML were left to do it on their own, with some help from the 2.0 script callbacks feature. This has changed completely in the last year.At the Microsoft Professional Developer's Conference in September 2005, Microsoft unveiled a new add-on to , code-named "Atlas," which was focused entirely on leveraging client-side JavaScript, DHTML, and the XMLHttpRequest object. The goal was to aid developers in creating more interactive AJAX-enabled Web applications. This framework, which has since been renamed with the official titles of Microsoft® AJAX Library and the 2.0 AJAX Extensions, provides a number of compelling features ranging from client-side data binding to DHTML animations and behaviors to sophisticated interception of client POST backs using an UpdatePanel. Underlying many of these features is the ability to retrieve data from the server asynchronously in a form that is easy to parse and interact with from client-side JavaScript calls. The topic for this month's column is this new and incredibly useful ability to call server-side Web services from client-side JavaScript in an 2.0 AJAX Extensions-enabled page.Calling Web Services with AJAXIf you have ever consumed a Web service in the Microsoft .NET Framework, either by creating a proxy using the wsel.exe utility or by using the Add Web Reference feature of Visual Studio®, you are accustomed to working with .NET types to call Web services. In fact, invoking a Web service method through a .NET proxy is exactly like calling methods on any other class. The proxy takes care of preparing the XML based on the parameters you pass, and it carefully translates the XML response it receives into the .NET type specified by the proxy method. The ease with which developers can use the .NET Framework to consume Web service endpoints is incredibly enabling, and is one of the pillars that make service-oriented applications feasible today.The 2.0 AJAX Extensions enable this exact same experience of seamless proxy generation for Web services for client-side JavaScript that will run in the browser. You can author an .asmx file hosted on your server and make calls to methods on that service through a client-side JavaScript class. For example, Figure 1 shows a simple .asmx service that implements a faux stock quote retrieval (with random data).In addition to the standard .asmx Web service attributes, this service is adorned with the ScriptService attribute that makes it available to JavaScript clients as well. If this .asmx file is deployed in an AJAX-Enabled Web application, you can invoke methods of the service from JavaScript by adding a ServiceReference to the ScriptManager control in your .aspx file (this control is added automatically to your default.aspx page when you create a Web site in Visual Studio using the AJAX-enabled Web site template):<asp:ScriptManager ID="_scriptManager" runat="server"><Services><asp:ServiceReference Path="StockQuoteService.asmx" /></Services></asp:ScriptManager>Now from any client-side JavaScript routine, you can use the MsdnMagazine.StockQuoteService class to call any methods on the service. Because the underlying mechanism for invocation is intrinsically asynchronous, there are no synchronous methods available. Instead, each proxy method takes one extra parameter (beyond the standard input parameters)- a reference to another client-side JavaScript function that will be called asynchronously when the method completes. The example page shown in Figure 2 uses client-side JavaScript to print the result of calling the stock quote Web service to a label (span) on the page.If something goes wrong with a client-side Web service call, you definitely want to let the client know, so it's usually wise to pass in another method that can be invoked if an error, abort, or timeout occurs. For example, you might change the OnLookup method shown previously as follows, and add an additional OnError method to display any problems:function OnLookup(){var stb = document.getElementById("_symbolTextBox");MsdnMagazine.StockQuoteService.GetStockQuote(stb.value, OnLookupComplete, OnError);}function OnError(result){alert("Error: " + result.get_message());}This way if the Web service call fails, you will notify the client with an alert box. You can also include a userContext parameter with any Web service calls made from the client, which is an arbitrary string passed in as the last parameter to the Web method, and it will be propagated to both the success and failure methods as an additional parameter. In this case, it might make sense to pass the actual symbol of the stock requested as the userContext so you can display it in the OnLookupComplete method:function OnLookup(){var stb = document.getElementById("_symbolTextBox");MsdnMagazine.StockQuoteService.GetStockQuote(stb.value, OnLookupComplete, OnError, stb.value);}function OnLookupComplete(result, userContext){// userContext contains symbol passed into methodvar res = document.getElementById("_resultLabel");res.innerHTML = userContext + " : <b>" + result + "</b>";}If you find that you're making many different calls to a Web service, and that you re-use the same error and/or complete methods for each call, you can also set the default error and succeeded callback method globally. This avoids having to specify the pair of callback methods each time you make a call (although you can choose to override the globally defined methods on a per-method basis). Here is a sample of the OnLookup method that sets the default succeeded and failed callback methods globally instead of on a per-call basis.// Set default callbacks for stock quote serviceMsdnMagazine.StockQuoteService.set_defaultSucceededCallback(OnLookupComplete);MsdnMagazine.StockQuoteService.set_defaultFailedCallback(OnError);function OnLookup(){MsdnMagazine.StockQuoteService.GetStockQuote(stb.value);}。

OverviewWhen ASP was first released,Web programming was more difficult because you needed IIS to serve your ASP ter,2.0and Visual Studio®2005made everything easier by introducing the Web site model of development. Instead of creating a new project inside Visual Studio,the Web site model lets you point to a directory and start writing pages and code.Furthermore,you can quickly test your site with the built-in Development Server,which hosts in a local process and obviates the need to install IIS to begin developing.we will introduce 2.0technology from different aspects. Framework Class Library is part of Microsoft's framework,which contains a vast set of programming classes designed to satisfy any conceivable programming need.because Visual Basic,JScript,and C++.A great deal of the functionality of these programming languages overlaps.for example,for each language,you would have to include methods for accessing the file system,working with databases,and manipulating strings.what’s more,these languages contain similar programming constructs,can represent loops and conditionals.Even though the syntax of a conditional written in Visual Basic differs from the syntax of a conditional written in C++,the programming function is the same.Maintaining all this functionality for multiple languages requires a lot of work.Wouldn't it be easier to create all this functionality once and use it for every language?however, Framework Class Library does exactly that.It consists of a vast set of classes designed to satisfy any conceivable programming need.For instance, framework contains classes for handling database access,working with the file system,manipulating text, and generating graphics.In addition,it contains more specialized classes for performing tasks such as working with regular expressions and handling network protocols.furthermore, framework contains classes that represent all the basic variable data types such as strings,integers,bytes,characters,and arrays. framework is huge.It contains thousands of classes(over3,400). Fortunately,the classes are not simply jumbled together.The classes of framework are organized into a hierarchy of namespaces.A namespace is a logical grouping of classes.For example,all the classes that relate to working with the file system are gathered together into the System.IO namespace.The namespaces are organized into a hierarchy(a logical tree).At the root of the tree is the System namespace.This namespace contains all the classes for the base data types,such as strings and arrays.It also contains classes for working with random numbers and dates and times.You can uniquely identify any class in framework by using the full namespace of the class.For example,to uniquely refer to the class that represents a file system file(the File class),you would use the following:System.IO.FileSystem.IO refers to the namespace,and File refers to the particular class.The classes contained in a select number of namespaces are available in your pages by default.(You must explicitly import other namespaces.)These default namespaces contain classes that you use most often in your applications:System—Contains all the base data types and other useful classes such as those related to generating random numbers and working with dates and times.System.Collections—Contains classes for working with standard collection types such as hash tables,and array lists.System.Collections.Specialized—Contains classes that represent specialized collections such as linked lists and string collections.System.Configuration—Contains classes for working with configuration files (Web.config files).System.Text—Contains classes for encoding,decoding,and manipulating the contents of strings.System.Text.RegularExpressions—Contains classes for performing regular expression match and replace operations.System.Web—Contains the basic classes for working with the World Wide Web, including classes for representing browser requests and server responses.System.Web.Caching—Contains classes used for caching the content of pages and classes for performing custom caching operations.System.Web.Security—Contains classes for implementing authentication and authorization such as Forms and Passport authentication.System.Web.SessionState—Contains classes for implementing session state.System.Web.UI—Contains the basic classes used in building the user interface of pages.System.Web.UI.HTMLControls—Contains the classes for the HTML controls.System.Web.UI.WebControls—Contains the classes for the Web controls.You can choose C#or or C++or Visual Basic to program page.regardless of the language that you use to develop your pages,you need to understand that pages are compiled before they are executed.This means that pages can execute very quickly.The first time you request an page,the page is compiled into class,and the resulting class file is saved beneath a special directory on your server named Temporary Files. For each and every page,a corresponding class file appears in the Temporary Files directory.Whenever you request the same page in the future,the corresponding class file is executed.When an page iscompiled,it is not compiled directly into machine code.Instead,it is compiled into an intermediate-level language called Microsoft Intermediate Language(MSIL).-compatible languages are compiled into this intermediate language.An page isn't compiled into native machine code until it is actually requested by a browser.At that point,the class file contained in the Temporary Files directory is compiled with framework Just in Time(JIT)compiler and executed.The magical aspect of this whole process is that it happens automatically in the background.All you have to do is create a text file with the source code for your page.2.Building Forms with Web Server ControlsUseingseveral of the basic Web controls to represent standard HTML form elements such as radio buttons,text boxes,and list boxes.You can use these controls in your pages to create the user interface for your Web application..3.Performing Form Validation with Validation ControlsTraditionally,Web developers have faced a tough choice when adding form validation logic to their pages.You can add form validation routines to your server-side code,or you can add the validation routines to your client-side code.The advantage of writing validation logic in client-side code is that you can provide instant feedback to your users.For example,if a user neglects to enter a value in a required form field,you can instantly display an error message without requiring a roundtrip back to the server.People really like client-side validation.It looks great and creates a better overall user experience.The problem,however,is that it does not work with all browsers.Not all browsers support JavaScript,and different versions of browsers support different versions of JavaScript,so client-side validation is never guaranteed to work.For this reason,in the past,many developers decided to add all their form validation logic exclusively to server-side code.Because server-side codefunctions correctly with any browser,this course of action was safer.At the same time, The Validation controls automatically generate both client-side and server-side code. If a browser is capable of supporting JavaScript,client-side validation scripts are automatically sent to the browser.If a browser is incapable of supporting JavaScript, the validation routines are automatically implemented in server-side code.Requiring Fields:The RequiredFieldValidator ControlYou use RequiredFieldValidator in a Web form to check whether a control has a value.Typically,you use this control with a TextBox control.However,nothing is wrong with using RequiredFieldValidator with other input controls such as RadioButtonList.Validating Expressions:The RegularExpressionValidator ControlYou can use RegularExpressionValidator to match the value entered into a form field to a regular expression.You can use this control to check whether a user has entered,for example,a valid e-mail address,telephone number,or username or password.Samples of how to use a regular expression to perform all these validation tasks are provided in the following sections.Comparing Values:The CompareValidator ControlThe CompareValidator control performs comparisons between the data entered into a form field and another value.The other value can be a fixed value,such as a particular number,or a value entered into another control.Summarizing Errors:The ValidationSummary ControlImagine that you have a form with50form fields.If you use only the Validation controls discussed in the previous sections of this chapter to display errors,seeing an error message on the page might be difficult.For example,you might have to scroll down to the48th form field to find the error message.Fortunately,Microsoft includes a ValidationSummary control with the Validation controls.You can use this control to summarize all the errors at the top of a page,or wherever else you want.4.Advanced Control ProgrammingWorking with View StateBy default,almost all controls retain the values of their properties between form posts.For example,if you assign text to a Label control and submit the form,when the page is rendered again,the contents of the Label control are preserved. The magic of view state is that it does not depend on any special server or browser properties.In particular,it does not depend on cookies,session variables,or application variables.View state is implemented with a hidden form field called VIEWSTATE that is automatically created in every Web Forms Page.When used wisely,view state can have a dramatic and positive effect on the performance of your Web site.For example,if you display database data in a control that has view state enabled,you do not have to return to the database each time the page is posted back to the server.You can automatically preserve the data within the page's view state between form posts.Displaying and Hiding ContentImagine that you want to break the tax form into multiple pages so that a person views only one part of the tax form at a time.you can set the Visible and Enabled properties with individual controls and groups of controls to hide and display page ing the Visible and Enabled PropertiesEvery control,including both HTML and Web controls,has a Visible property that determines whether the control is rendered.When a control's Visible property has the value False,the control is not displayed on the page;the control is not processed for either pre-rendering or rendering.Web controls(but not every HTML control)have an additional property named Enabled.When Enabled has the value False and you are using Internet Explorer version4.0or higher,the control appears ghosted and no longer functions.When used with other browsers,such as Netscape Navigator,the control might not appear ghosted,but it does not function.5.Web Deployment ProjectsThe beauty of the 2.0is that you can develop your Web application without thinking about packaging and deployment.when need another class,you can Add a.cs file to the App_Code directory and start writing.When want to store localizable strings in a resource file,you can add a.resx file to the App_GlobalResources directory and type in the strings.Everything just works;you don't have to think about the compilation and deployment aspect at all.When you are ready to deploy,you have several options.The simplest choice is to copy your files to a live server and let everything be compiled on-demand(as it was in your test environment).The second option is to use the aspnet_compiler.exe utility and precompile the application into a binary release,which leaves you nothing but a collection of assemblies,static content,and configuration files to push to the server. The third option is to again use aspnet_compiler.exe,but to create an updateable binary deployment where your.as*x files remain intact(and modifiable)and all of your code files are compiled into binary assemblies.6.C#LanguageIntroduction to the C#Language and Framework C#is an elegant and type-safe object-oriented language that enables developers to build a wide range of secure and robust applications that run on Framework.You can use C#to createtraditional Windows client applications,XML Web services,distributed components, client-server applications,database applications,and much,much more.Microsoft Visual C#2005provides an advanced code editor,convenient user interface designers,integrated debugger,and many other tools to facilitate rapid application development based on version2.0of the C#language and Framework.C#syntax is highly expressive,yet with less than90keywords,it is also simple and easy to learn.The curly-brace syntax of C#will be instantly recognizable to anyone familiar with C,C++or Java.Developers who know any of these languages are typically able to begin working productively in C#within a very short time.C# syntax simplifies many of the complexities of C++while providing powerful features such as nullable value types,enumerations,delegates,anonymous methods and direct memory access,which are not found in Java.C#also supports generic methods and types,which provide increased type safety and performance,and iterators,which enable implementers of collection classes to define custom iteration behaviors that are simple to use by client code.As an object-oriented language,C#supports the concepts of encapsulation, inheritance and polymorphism.All variables and methods,including the Main method, the application's entry point,are encapsulated within class definitions.A class may inherit directly from one parent class,but it may implement any number of interfaces. Methods that override virtual methods in a parent class require the override keyword as a way to avoid accidental redefinition.In C#,a struct is like a lightweight class;it is a stack-allocated type that can implement interfaces but does not support inheritance.In addition to these basic object-oriented principles,C#facilitates the development of software components through several innovative language constructs, including:∙Encapsulated method signatures called delegates,which enable type-safe event notifications.∙Properties,which serve as accessors for private member variables.∙Attributes,which provide declarative metadata about types at run time.∙Inline XML documentation comments.If you need to interact with other Windows software such as COM objects or native Win32DLLs,you can do this in C#through a process called"Interop."Interop enables C#programs to do just about anything that a native C++application can do. C#even supports pointers and the concept of"unsafe"code for those cases in which direct memory access is absolutely critical.The C#build process is simple compared to C and C++and more flexible than in Java.There are no separate header files,and no requirement that methods and types be declared in a particular order.A C#source file may define any number of classes, structs,interfaces,and events.C#programs run on Framework,an integral component of Windows that includes a virtual execution system called the common language runtime(CLR) and a unified set of class libraries.The CLR is Microsoft's commercial implementation of the common language infrastructure(CLI),an international standard that is the basis for creating execution and development environments in which languages and libraries work together seamlessly.Source code written in C#is compiled into an intermediate language(IL)that conforms to the CLI specification.The IL code,along with resources such as bitmaps and strings,is stored on disk in an executable file called an assembly,typically with an extension of.exe or.dll.An assembly contains a manifest that provides information on the assembly's types,version,culture,and security requirements.When the C#program is executed,the assembly is loaded into the CLR,which might take various actions based on the information in the manifest.Then,if the security requirements are met,the CLR performs just in time(JIT)compilation to convert the IL code into native machine instructions.The CLR also provides other services related to automatic garbage collection,exception handling,and resource management.Code that is executed by the CLR is sometimes referred to as"managed code,"in contrast to"unmanaged code"which is compiled into native machine language that targets a specific system.The following diagram illustrates thecompile-time and run time relationships of C#source code files,the base class libraries,assemblies,and the CLR.Language interoperability is a key feature of Framework.Because the IL code produced by the C#compiler conforms to the Common Type Specification (CTS),IL code generated from C#can interact with code that was generated from versions of Visual Basic,Visual C++,Visual J#,or any of more than20 other CTS-compliant languages.A single assembly may contain multiple modules written in languages,and the types can reference each other just as if they were written in the same language.In addition to the run time services, Framework also includes an extensive library of over4000classes organized into names paces that provide a wide variety of useful functionality for everything from file input and output to string manipulation to XML parsing,to Windows Forms controls.The typical C# application uses Framework class library extensively to handle common "plumbing"chores.。

附件1：外文资料翻译译文 ASP.NET 概述 ASP.NET 是一个统一的 Web 开发模型，它包括您使用尽可能少的代码生成企业级 Web 应用程序所必需的各种服务。ASP.NET 作为 .NET Framework 的一部分提供。当您编写 ASP.NET 应用程序的代码时，可以访问 .NET Framework 中的类。您可以使用与公共语言运行库 (CLR) 兼容的任何语言来编写应用程序的代码，这些语言包括 Microsoft Visual Basic、C#、JScript .NET 和 J#。使用这些语言，可以开发利用公共语言运行库、类型安全、继承等方面的优点的 ASP.NET 应用程序。

ASP.NET 包括：  页和控件框架  ASP.NET 编译器  安全基础结构  状态管理功能  应用程序配置  运行状况监视和性能功能  调试支持  XML Web services 框架  可扩展的宿主环境和应用程序生命周期管理  可扩展的设计器环境 ASP.NET 页和控件框架是一种编程框架，它在 Web 服务器上运行，可以动态地生成和呈现 ASP.NET 网页。可以从任何浏览器或客户端设备请求 ASP.NET 网页，ASP.NET 会向请求浏览器呈现标记（例如 HTML）。通常，您可以对多个浏览器使用相同的页，因为 ASP.NET 会为发出请求的浏览器呈现适当的标记。但是，您可以针对诸如 Microsoft Internet Explorer 6 的特定浏览器设计 ASP.NET 网页，并利用该浏览器的功能。ASP.NET 支持基于 Web 的设备（如移动电话、手持型计算机和个人数字助理 (PDA)）的移动控件。

ASP.NET 网页是完全面向对象的。在 ASP.NET 网页中，可以使用属性、方法和事件来处理 HTML 元素。ASP.NET 页框架为响应在服务器上运行的代码中的客户端事件提供统一的模型，从而使您不必考虑基于 Web 的应用程序中固有的客户端和服务器隔离的实现细节。该框架还会在页处理生命周期中自动维护页及该页上控件的状态。