Application and Page Frameworks

In order to see the Finnish text, add the following Page directive:

uiculture=”fi-FI”

After this is in place, run the page. You see the Finnish language output shown in Figure 3-13.

Figure 3-13

Compilation

You already saw how Visual Studio 2005 compiles pieces of your application as you work with them (for instance, by placing a class in the \Code folder). The rest of the application, such as the .aspx pages themselves can be compiled just as in ASP.NET 1.0/1.1 by referencing the pages in the browser.

When an ASP.NET page is referenced in the browser for the first time, the request is passed to the ASP.NET parser that creates the class file in the language of the page. After the class file has been created, the class file is compiled into a DLL and then written to the disk of the Web server. This is detailed in Figure 3-14.

On the next request, great things happen. Instead of going through the entire process again for the second and respective requests, the request simply causes an instantiation of the already-created DLL, which sends out a response to the requester. This is illustrated in Figure 3-15.

Because of the mechanics of this process, if you made changes to your .aspx code-behind pages, you found it necessary to recompile your application. This can be quite a pain if you have a larger site and don’t want your end users to experience the extreme lag that occurs when an .aspx page is referenced for the first time after compilation. Many developers, consequently, began to develop their own tools that would automatically go out and hit every single page within their application to remove this firsttime lag hit from the end user’s browsing experience.

69

Chapter 3

ASP.NET 2.0 introduces the technology to precompile your entire application with a single command that you can issue directly in the browser. This type of compilation is referred to as in-place precompilation. In order to precompile your entire ASP.NET application, pull up one of the pages in the browser and replace the page name with precompile.axd. So, if you are working with the Web server that is built into Visual Studio 2005, your request is structured in the following format:

70

Application and Page Frameworks

http://[host]:[port]/[Application Name]/precompile.axd

If you are using IIS as the Web server, your request is structured in the following format:

http://[host]/[Application Name]/precompile.axd

If it is successful, you get a message that states the precompilation was successful. The other great thing about this precompilation capability is that you can also use it to find any errors on any of the ASP.NET pages in your application. Because it hits each and every page, if one of the pages contains an error that won’t be triggered until runtime, you get notification of the error immediately as you invoke precompile.axd.

The next precompilation option is commonly referred to as precompilation for deployment. This is an outstanding new addition to ASP.NET that enables you to compile your application down to some DLLs, which can then be deployed to customers, partners, or elsewhere for your own use. Not only are minimal steps required to do this, but after your application is compiled, you only have to move around the DLL and some placeholder files for the site to work. This means that your Web site code is completely removed and placed in the DLL when deployed.

To precompile your application for deployment, you must use the aspnet_compiler.exe tool that now comes with ASP.NET 2.0. You navigate to the tool using the Command window. Open the Command window and navigate to C:\Windows\Microsoft.NET\Framework\v2.0.xxxxx\. When you are there, you can work with the aspnet_compiler tool.

Before you do, however, create a folder in your root drive called, for example, Wrox. This folder is the one you ask the compiler to output to. When it is in place, you can return to the compiler tool and give it the following command:

aspnet_compiler -v [Application Name] –p [Physical Location] [Target]

So, if you had an application called INETA located at C:\Websites\INETA, you would use the following commands:

aspnet_compiler –v /INETA –p C:\Websites\INETA C:\Wrox

Press Return and the compiler either tells you that it has a problem with one of the command parameters, or that it was successful (shown in Figure 3-16). If it was successful, you can see the output that was placed in the target directory.

Figure 3-16

71

Chapter 3

In the example just shown, -v is a command for the virtual path of the application — which is provided by using /INETA. The next command is –p, which is pointing to the physical path of the application. In this case, it is C:\Websites\INETA. Finally, the last bit, C:\Wrox, is the location of the compiler output. The following table describes the possible commands for the aspnet_compiler.exe tool.

After compiling the application, you can go to C:\Wrox to see the output. Here you see all the files and the file structure that was in the original application. But if you look at the contents of one of the files, notice that the file is simply a placeholder. In the actual file you find the comment:

This is a marker file generated by the precompilation tool, and should not be deleted!

In fact, you find a Code.dll file in the bin folder where all the page code is located. Because it is in a DLL file, is provides great code obfuscation as well. From here on, all you do is move these files to another server using FTP or Windows Explorer and you can run the entire Web application from these files. When you have an update to the application, you simply provide a new set of compiled files. A sample output is displayed in Figure 3-17.

Figure 3-17

72

Application and Page Frameworks

Note that this compilation process doesn’t compile every type of Web file. In fact, it compiles only the ASP.NET-specific file types and leaves out of the compilation process files such as

HTML files

XML files

XSD files

Web.Config files

Text files

You can’t do much to get around this, except in the case of the HTML files and the text files. For these file types, just change the file extension to .aspx and they are then compiled into the Code.dll like all the other ASP.NET files.

Summar y

This chapter covered a lot of ground. I discussed some of the issues concerning ASP.NET applications as a whole and the choices you have when building and deploying these new applications. With the help of Visual Studio 2005, you now have options about which Web server to use when building your application and whether to work locally or remotely through the new built-in FTP capabilities.

ASP.NET 2.0 and Visual Studio 2005 make it easy to build your pages using an inline coding model or to select a new and better code-behind model that is simpler to use and easier to deploy. You also took a look at the new cross-posting capabilities and the new fixed folders that ASP.NET 2.0 has incorporated to make your life easier. These folders make their resources available dynamically with no work on your part. Finally, you saw some of the outstanding new compilation options that you have at your disposal.

As you worked through some of the examples, you may have been thinking, “WOW!” But wait . . .

there’s plenty more to come!

73