Original: http://www.microsoft.com/china/msdn/archives/library/dnaspp/html/codecompilation.asp
ASP.NET WHIDBEY China New Code Compile Features
G. Andrew Duthiegraymad Enterprises, Inc.
October 2003
Summary: Learn how to use the 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 annotation is used in English. In this article, it is translated into Chinese to facilitate the reader's understanding.)
table of Contents
Introduction New Modular Code Model / Code Directory Interaction Calculator Precompiled Support In Bit Precompiled Deployment Precipure IntelliSense is everywhere! summary
Introduction
The new version of Microsoft® ASP.NET will introduce a lot of new features and improvements, which is named by ASP.NET Whidbey, named by 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.
New modular code model
By default, the site developed using Visual Studio .NET 2002 or 2003 uses a function called "modular code" to separate the visual elements (HTML tags, controls, etc.) from the programming logic associated with the UI. 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 the local class, some other changes are performed, the ASP.NET team can achieve the following:
There is no need to write control declarations and event binding code in the CodeBehind class (bind events 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 (known as the code-separated web form in Visual Studio .NET Whidbey), by 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"%>
Webform1.aspx.vb:
Public Class Webform1
Inherits System.Web.ui.page
#Region "The code" of the web form designer "
'This call is required for the web form designer. _
Private subinitializeComponent ()
End Sub
'Note: The following placeholders are declared
The 'Web Form Designer is required.
'Do not delete or change its location.
Private DesignerPlaceHolderDeclaration as System.Object
Private sub page_init (byval sender as system.object, _
Byval e as system.eventargs) Handles mybase.init
'Codegen: This method call is required for the web form designer.
'Do not modify it using the code editor.
InitializeComponent ()
End Sub
#End region
Private sub page_load (byval sender as system.Object, _
BYVAL E as system.eventargs) Handles mybase.load
'Place the user code used to initialize this page
End Sub
END CLASS
Visual Studio .Net Whidbey
DEFAULT.ASPX:
<% @ page language = "VB" compilewith = "default.aspx.vb"
ClassName = "asp.default_aspx"%>
Default.aspx.vb:
Imports Microsoft.visualBasic
Namespace ASP
Expands Class Default_ASPX
END CLASS
End Namespace
From the above example, you can clearly see that the code generated by Visual Studio .Net Whidbey is more clear and easy to read. This goal does not need to sacrifice drag and drop function or IntelliSense.
/ Code directory
Another very cool and practical new feature in ASP.NET Whidbey is to increase / code directory. / Code directory is similar to the / bin directory, is a special directory for ASP.NET, but it is different from / bin directory: / bin directory is used to store the precompiled assembly used by the application, and / code directory Used to store class files to be dynamically compiled during runtime. This allows you to store the business logic components, data access components, and classes of other components in a location in the application and use these classes from any page. Because these classes are dynamically compiled during runtime, they are automatically referenced by the application containing / code directory, so they do not need to generate items before deploying projects, nor does it need to be explicitly adding class references. You can make changes to the components in peace of mind and then deploy using simple XCOPY or drag and drop operations. In addition to simplifying components deployment and reference, / code directory also greatly simplifies the creation and access process of resource files (.resx) used in the localization process, and automatically generates and compiles the Agent class for WSDL files (.wsdl). process.
In order to better explain the implementation of the above operation, let us first see a few examples. In the first example, we will see how to create a simple business component and how to access it from the web form page.
Interest calculator
First, we open Visual Studio .Net Whidbey, create a new Web site called Compilation. After creating a Web site, the IDE should be similar to Figure 1.
Figure 1: Visual Studio .Net Whidbey Web Site
Then, we add the / code folder to the Web site, add the method to right-click the item, then select New Folder. This folder must be named CODE, but the name is not case sensitive. After adding a folder, we can add a new class file: Right-click the / code folder, click Add New Item ... (add new item ...), then in the Add New Item dialog Select the Class (Class) item in the Templates pane. Name the class CalculateINTEREST.VB. Then add the code used to calculate interest (add it to the Class and End Class statements): Public Function Calcbalance (Byval Prencpl As INTEGER, _
Byval rate as double, _
Byval year as integer, _
BYVAL Period As Integer AS String
DIM Basenum as double = (1 rate / period)
Calcbalance = _
Format (PrNCPL * System.math.Pow (Basenum, _
(Years * period), "#, ###, ## 0.00"). Tostring
END FUNCTION
After creating component classes, we need to modify the DEFAULT.ASPX page to provide a field for entering data, requiring the CalcBalance method of the component. For the sake of simplicity, the complete list of Default.aspx displays the following (please note that default.aspx uses a single file code model).
DEFAULT.ASPX:
<% @ page language = "vb"%>
