Asp.net| Compile precompiled support
One of the advantages of ASP.net Web forms is that after you add dynamic compilation, you can easily change the. aspx page, and the page will update dynamically when you save the changes without recompiling (as long as you don't use modular code). However, dynamic compilation is not appropriate for every application, and when you first access an application, dynamic compilation causes the browser's initial performance to degrade. Also, many times you may want to deploy an application that has no source code. If you experience this, you'll be more than happy to learn that asp.net Whidbey has the ability to support precompiled Web sites. asp.net Whidbey supports two precompilation modes: in-place precompilation and deployment precompilation.
In-situ precompilation
In-place precompilation allows you to manually batch-compile all pages in a Web site. This is what happens when a user clicks a page for the first time in your application (except in the latter case mentioned above), and the user simply sits down to wait for the batch compilation to complete. There are two main reasons to use in-place precompilation: First, it avoids the performance degradation of the batch compilation when the page is first requested, and secondly, it allows you to discover compilation errors "before" the user.
In-situ precompilation is also easy to implement by simply browsing to the root of the Web site and adding a specific handler name Precompile.axd (a user familiar with the ASP.net trace feature will find the name similar to the Trace.axd handler):
Http://localhost/mywebsitename/precompile.axd
Where Mywebsitename is the name of your Web site. Once the site is precompiled, requests for pages within the site should be completed without any compile latency.
Deploying precompilation
The second precompilation mode allows you to create an executable version of the entire Web site that does not require any source code (including HTML and other static files) to deploy this version. Therefore, deployment precompilation prevents others from randomly accessing intellectual property information that is represented by code. The generated assemblies and Stub file sets can be deployed to the production server through XCOPY, FTP, Windows Explorer, and so on. To precompile a site for deployment, ASP.net Whidbey provides a command-line utility named Aspnet_compiler.exe. To invoke the ASP.net preprocessor on the file system Web site, you need to open a command window to browse to the installation location of the. NET Framework ( \microsoft.net\framework\< version >), and then enter the following command:
aspnet_compiler/v/<websitename>-P <source> <destination>
which For the name of the Web site (that is, the name entered in the browser), And is a two file system path that points to the location where you want to compile the site and where the compiled version should be exported. As an example of our Web site, the commands you enter are as follows (note that the following is a command):
aspnet_compiler/v/compilation-p c:\WebSites\Compilation c:\WebSites\Compilation_Compiled
If you want to view all available options for the ASP.net preprocessor, simply enter the following command:
Aspnet_compiler/?
Note that some command-line options require that the WEB site must be a valid Microsoft®internet information Service (IIS) application to function correctly. If you browse to the target directory in Microsoft®windows Explorer, you will see that the precompiled Web site will generate a site containing the bin directory containing assemblies and descriptive files, as well as a large number of Stub files with the same name as the original page. But does not contain code (including HTML and executable code). If you browse this site, the output is the same as the output from the original site. Note that you cannot use in-place precompilation on a site that has been precompiled for deployment because it has been precompiled.
IntelliSense is everywhere!
For Visual Studio. NET 2002 and 2003, one of the most vexing issues (I believe many developers agree) is inconsistent with IntelliSense and other features used to improve productivity. Do you want to drag controls from the toolbox to the page in HTML view? I can't do that. In fact, the Toolbox's Web forms panel is not visible in HTML view at all! Do you want to write inline code on the. aspx page instead of using modular code? You can do this, but you must discard IntelliSense, drag-and-drop functionality, and more. Finally, as I mentioned in my recent article in MSDN asp.net Developer Center, the design-time support for customizing controls in Visual Studio. NET 2002 or 2003 needs to span layers of barriers, including a somewhat coarse but effective XSL Modify.
Happily, the unification of the compilation model was implemented in ASP.net Whidbey, and all these problems were solved. In Visual Studio. NET Whidbey, you can write inline code or use a new modular code model, as well as control drag-and-drop, IntelliSense-statement completion, and all of the functionality that you would like to use to increase productivity that you would otherwise be unable to use because of coding limitations. In addition, the design-time support for custom server controls and Web controls has been greatly improved, including adding IntelliSense statements to the custom controls in the Source view (HTML view in the equivalent view in Visual Studio. NET Whidbey).
Summary
Changes to the compilation model in ASP.net Whidbey, as well as improvements to the corresponding features in Visual Studio. NET Whidbey, are undoubtedly a huge leap forward, not only to provide developers with the required flexibility, but also to enable them to take full advantage of the IDE Provides the ability to increase productivity. The dramatically simplified modular code model makes the feature more useful and straightforward, and the new full support for inline code is clearly welcomed by developers who want all the code to be in an. aspx file. It is believed that the \code directory will greatly increase productivity, especially for developers who are engaged in fast-growing small and medium projects, as well as for developers who are unable to complete their work because of the complexity of the compilation process. It also provides a more straightforward and straightforward way to access business logic components, resource files, WSDL files, and other resources: by automatically compiling, embedding, or creating proxies for these resources and automatically referencing them, you can access these resources with little code.
The precompilation feature allows developers to easily improve the initial performance of their site and, if necessary, add protection to important intellectual property information by providing full-featured WEB applications that do not contain source code or HTML. Finally, a set of all functional Visual Studio. NET Whidbey will undoubtedly give developers extraordinary experience, not only from the embedded code model and the modular code model to obtain full IntelliSense support, but also to see all the views of a given page, Development work will no longer be limited to a certain style by tool limitations.
