ASP.NET WHIDBEY China New Code Compile Features
G. Andrew Duthiegraymad Enterprises, Inc. October 2003 Abstract: Learn how to use ASP.NET Whidbey to easily use code. The Code directory automatically compiles the code for your site, and the pre-compiled will make the deployment work easier. Download the source code of this article. (Note that in the sample file, the programmer's comment is in English. In this paper, it is translated into Chinese to facilitate the reader understanding.) Directory Introduction New modular code model / code directory interest calculator precompiled support Pred-compiled deployment pre-compilation IntelliSense is everywhere! Summary Introduction The new version of the new version of Microsoft® ASP.NET introduces a large number of new features and improvements, and its code is ASP.NET Whidbey, which is named according to the code of the new Microsoft® Visual Studio® .NET. Some of these features use the foundation Microsoft® .NET Framework version (ASP.NET Whidbey is new features based on this release). In these functions, one of the most useful features is related to code compilation. This article describes the main changes to the ASP.NET Whidbey compilation model, which is the impact of writing ASP.NET applications, and how to use these changes. Improved features and new compilation functions can be divided into the following four basic aspects:
Improvement of modular code model. New Code directory. Added support for pre-compiling ASP.NET applications. Microsoft® IntelliSense® Enhancements. The new modular code model By default, the site developed using Visual Studio .NET 2002 or 2003 uses a function called "modular code" to program a visual element (HTML tag, control, etc.) from the UI Logic is separated. When the developer creates a new web form (such as foo.aspx), Visual Studio automatically creates a related codeBeHind class file, the front part of the file name is the same as the web form, the back is .vb or .cs (depend The language used in the project). Class files will be associated with the web form via the CodeBehind and Inherits properties of the @ Page instruction. Class files contain event processing code (including code for binding event handlers to the corresponding event), and the separation declaration of each control (added to the .aspx file through the Visual Studio Web Form). After compiling (generated) Web application project, all CodeBehind classes will be compiled into a .NET program set, which will place it into the / bin directory of the web application. The web form page itself is compiled during runtime and each web form is inherited from the CodeBehind class related to it. For more information on the modular code model in Visual Studio .NET 2003 and ASP.NET 1.1, see MSDN Library Articles Web Forms Code Model. Although the initial modular code model is in theory (who does not want to separate the UI element to the programming logic phase?), There are still some shortcomings:
Need to be regenerated. In Visual Studio .NET, the CodeBehind class is not automatically compiled, so any changes to the CodeBehind class need to regenerate the entire project to apply these changes. (Note that you can specify dynamic compilation of the modular code file via the SRC property of the @ page instruction, but by default Visual Studio .NET does not do this.) Share development issues. Because all CodeBehind classes in the project have compiled into a program set, it is difficult to let multiple developers develop a project at the same time without encountering bottlenecks. The code is easily destroyed. Controls are exist simultaneously by declaring (in the .aspx page) and programming (in the CodeBehind class), if the two sets of controls are not properly synchronized, the code is easily destroyed. The complexity is increased, and the single file support is missing. In Visual Studio .NET, many functions for increasing productivity (including IntelliSense statements are completed) require modular code. Unfortunately, these features typically add a large number of relatively complex code in the CodeBehind class, which produces a problem that code is easily destroyed because the code that changes Visual Studio .NET is easy to destroy the page. After understanding these disadvantages, it is responsible for developing ASP.NET and Visual Studio .Net Whidbey group decided to reconsider the modular code model. The new modular code model uses the new features known as the local class (known as local types in C #) Microsoft® Visual Basic® .NET and C #. The local class allows you to define different parts of a class in multiple files. When compiling, these parts are combined together by the compiler. ASP.NET Whidbey uses the new CompileWith and ClassName properties in the @ Page instruction to identify the CodeBehind partial class that is integrated with the .aspx page. By using local classes, some other changes can be made, the ASP.NET team can implement the following: No need to write control declarations and event binding code in the CodeBehind class (bind events through the declaration in the control declaration). Allow runtime to dynamically compile the web form page and the CodeBehind class, no need to regenerate the entire project for a subtle changes. Reduce the phenomenon of file contention in sharing development. The same IDE experience can be obtained for developers using modular code files and like single file development (all code and tags are included in .aspx files). Different views of the modular code model before and after the modular code model are given. The following code is just the default code created by Visual Studio when using a modular code to add a new web form (in Visual Studio .NET WHIDBey as a code-separated web form), the default code created by Visual Studio: Visual Studio .NET 2002/2003 Webform1.aspx: <% @ page language = "vb" autoeventwireup = "false"
Codebehind = "Webform1.aspx.vb" inherits = "TestWebApp_121602.webform1"%>
Content = "http://schemas.microsoft.com/intellisense/ie5">
hEAD>