Introduction

In the previous article, you learned to create and edit web sites with Visual Studio 2005, with the focus very much on user interface improvements in VS2005. In this article we will explore the changes that have been made for compilation, debugging and web site structure in ASP.NET 2.0 which reflect in the VS 2005 IDE.

System Requirements

This article is based on Beta2 version of VS 2005. VS 2005 Beta 2 is currently available to MSDN Subscribers as well as for ordering from Microsoft’s website. The version of the .NET framework is v2.0.50215.

Code Separation and Code-Behind

One of the most touted changes in ASP.NET must surely be the new code-beside model of code separation. In previous versions of VS the ASP.NET code separation model involved declaring a codebehind file for each .aspx page (unless you used in-line coding). The .aspx page inherited from the class defined in the code behind file.

Code-behind was innovative, but from both an object-based and a usability viewpoint it was far from perfect. The designed .aspx page was derived from a class that was generated in parts by the development environment. You had to declare controls in both files, and manual changes often resulted in problems

In ASP.NET 2.0, besides providing support for the older model for backward compatibility, a new model has been introduced. Instead of using the class derivation as it was up to now, the design file and the source code file are created as partial classes that will be merged by the compiler while compilation. In other words, in the code-beside model the ASPX page and the C# or VB code in the code file form a part of the same class. This is made possible using the new partial classes concept that has been added to C# and VB. With partical classes, the definition of a class can reside in 2 or more physically separate files. The great thing is that is approach means that there’s no automatically generated source code at all. Both files work hand in hand, and you can assign events directly in the server control tags. This reduces the clutter in files, simplifies programming of controls on the ASPX page and “ as explained later in the article – helps to catch more errors at compile-time.

TIP. There seems to be some confusion about the terminology of the new model. In early betas it was usually referred to in the community as code-beside. On the other hand most current Microsoft documentation refers to it as code-behind, the same name as the old model. To avoid confusion we’ll refer to the new partial-class-based model as code-beside.

To add a new-style code-beside page, right-click the project in Solution Explorer and choose Add New Item. Then select Web Form and check the Place code in separate file checkbox in the following dialog box and click Add . Now the project contains two new files, one with the design and one with the source code. The two files are nothing new, but the source code file doesn’t include any directives generated by the IDE. VS 2005 has just built an empty partial class.

Figure 1 and Figure 2 show an example a page using the new model. The page contains a Label control and a Button control. Clicking the Button control will assign new text to the Label control.

Figure 1. ASPX file with code-beside file
This figure has been reduced in size to fit in the text. To view the full image Click here

Figure 2. Code-Beside file with no cluttered code

TIP: You can use code-beside pages and single file pages within one project without any problems. VS 2005 handles the files in an appropriate manner automatically, and it takes care that you get the right information while debugging.

Debugging

In VS 2005 a web site can started in debug mode by pressing F5 (this is similar to the previous versions of VS .NET),

Any application stored at the local IIS level will use IIS to serve the web application, while any project on the local file system is launched using VS’s new integrated web server (Figure 3), which looks somewhat like the familiar Cassini server. You can right-click on the ASP.NET Development Server icon in the system tray and select Show Details to view details of the local web server as shown in Figure 3.

Figure 3. You no longer need IIS to run your project.

How Code-Beside Helps Debugging

In previous versions of ASP.NET, for which the code for a page was generally written in separate code-behind file, the ASPX pages would inherit the class defined in the code behind file. Earlier versions of VS would compile all the code-behind classes in a project into a single large dll library. On the first request for any particular page the ASP.NET runtime would also compile the ASPX pages into a separate assembly in its temporary directory. Any errors during compilation of the ASPX file would only get detected at runtime, and then only if you visited that particular page.

In ASP.NET 2.0 the new code-beside model has significant benefits for debugging: The reason is that the VS 2005 compiler has been updated to take advantage of this change and now VS 2005 has the code in both the ASPX and CodeBeside files compiled when you build your web site. Any error in the ASPX file is thus detected by the IDE, with no need to wait until a page is browsed to. This helps the developer to fix more errors (many of them which might otherwise have cropped up at runtime) in the IDE before deploying the site.

Creating a Web.Config for Debugging

The first time you attempt to debug a project, you may see a dialog like the one in Figure 4. Hopefully this dialog should be fairly self-explanatory.

Figure 4. The dialog to add a new Web.config

The issue here is that, as you may be aware, ASP.NET 2.0 does not use project files. Hence the default information for whether a project should be compiled and run in debug mode – which used to be in the project file in VS.NET 2003 “ now needs to go somewhere else, and the obvious place is the web.config file. The ASP.NET compiler relies on the settings specified by the compilation tag to compile the site in Debug or Release mode, so when you start a project by pressing F5 , the IDE generates a web.config file automatically after a confirmation if one doesn’t already exist. This web.config file will contain a new compilation tag.

The Object Inspector

The object inspector is a new addition to the overall debugging experience in Visual Studio 2005. It’s shown in Figure 5, and is available while building any kind of application in VS 2005, though in this article we are focusing on web projects. The object inspector lets you quickly look at the values of the core properties on an object displayed as an expanded tooltip. This can be further drilled down to view properties of the base classes.

Figure 5. Object Inspector in action
This figure has been reduced in size to fit in the text. To view the full image Click here

Debug Visualizers

Another addition made to enhance the debugging experience in VS 2005 is that of Debug Visualizers . During normal debugging we can look at all the nitty gritty details of every object “ but many of the properties are internal to the object and may not make much sense while debugging. Debugging Visualizers have been introduced to display information about a particular type of object in a formatted way that makes more sense to the end user (or the developer), rather than showing him just a bunch of unhelpful internal values. As an example suppose you are trying to generate HTML through code; in this situation it can be hard to visualize how the generated markup would look on the browser. A debug visualizer would help you in these cases by formatting the markup as HTML. In Figure 5, the three options of Text Visualizer, XML Visualizer and HTML Visualizer are displayed for the Text property of a Textbox control that contains an HTML string. On selecting the HTML Visualizer the IDE shows a dialog as seen in Figure 6. The same dialog can also be invoked from other debugging windows like the Autos or the Watch window.

Figure 6. Debug Vizualizers “ A new way to visualize objects while debugging

The actual markup shown in figure 4 “ the simple string, Welcome , is probably not the kind of string that you’d particuarly want to view as HTML, but imagine if the string contained multiple HTML tags, perhaps a complete table definition.

The App_Code Directory

In the previous version of ASP.NET, on the first request to each page, that page would be compiled by the ASP.NET runtime. This auto-compile concept has been extended so that code files such as business logic, components etc are also auto-compiled by the ASP.NET 2.0 runtime. In order for this to function the runtime uses a new App_Code directory inside the virtual directory that contains your application.

The App_Code directory looks like nothing more than an ordinary folder, but it’s actually quite special. Any source code files for business logic etc. classes such as .vb or .cs files can be saved here (though not the code-beside files) and they will be recompiled automatically when replaced. Every supported file is compiled dynamically and is available instantly after you save it. And before you start worrying about security, IIS won’t let users download files from the App_Code directory. Placing your business logic classes here is an alternative to creating a separate dll project. In practice the usual point is that you will use the App_Code directory on your development machine to gain automatic compilation, but when you deploy to the production server you could swap to a pre-compiled mode (as discussed below) so source code is not installed on the production server.

Using the App_Code Directory

To use the App_Code directory , right-click the project and from the context menu select Add Folder -> App_Code . The folder shows its special meaning at once. The second step is to add a C# source code file, such as the Foo.cs file in the following code to the folder, attach the method Bar() , and save the new file.

using System;

/// <summary>

/// Summary description for Foo

/// </summary>

public class Foo

{
   public string Bar()
   {
   }

}

You can use the class in your project without compilation. Even the IntelliSense window knows the class, as shown in Figure 7. In addition, full debugging support is available for the file. This means that you’re able to step into every single method.

Figure 7. Any known file types placed within the code directory are dynamically compiled.

TIP: For better structuring of your source code, it’s advisable to spread the classes in subdirectories of the code folder, especially if you work with large projects. The files in subfolders will be dynamically compiled as well.

In comparison with the previous approach of creating separate projects to hold your business logic, the App_Code directory offers enhanced possibilities of teamwork, which is a significant advantage. In this new model, a team member no longer has to check out a project file from an associated library project to add or remove files. Changes become effective on a global basis very easily also all code relevant to the Web Site is stored in the same place rather than be scattered in multiple projects and directories. On the other hand, using the App_Code directory is not compulsory “ many teams may prefer the older componentized approach of keeping business logic in separately compiled projects.

What Happened to the Bin Directory?

With the new App_Code directory, you may be wondering what’s happened to your old friend, the bin directory, where the compiled dll ‘s for the website used to go. The answer is not much, it’s still alive. But I wouldn’t mention it if there hadn’t been some changes. In particular, web sites are no longer by default compiled explicitly into a dll by VS 2005. Instead, Web Sites are dynamically compiled by the runtime and the resultant Dll stored to its temporary directory.

To include an external Dll in VS 2005, you just have to copy the dll the Bin directory. As a result, the contained classes are automatically available, with IntelliSense support, of course.

Multilanguage Support

With ASP.NET 2.0 there is greatly improved support for using multiple programming languages per web site. You can now mix different .NET languages whenever you want. In my view it’s a great win for large teams with different skillsets who need to work on a single project. The way it works is that you simply mix different languages using the App_Code directory. The Foo class written in C# and shown earlier works fine with VB .NET pages. This includes full IntelliSense support and debugging support.

Precompilation

As noted above, usually an ASP.NET page, including all dependent source code files, is automatically compiled on the first request. This once-compiled version is used until the page or one of its dependencies changes. Besides this approach, version 2.0 offers precompilation . In this approach, all the pages and all related files are compiled explicitly and at once so no more compilation is required when the application is first requested. This speeds up serving the first page.

There are two different kinds of precompiling: in-place precompilation and precompilation for deployment . The following sections describe these precompilation types in detail.

In-Place Precompilation

You execute in-place precompilation by using the aspnet_compiler tool provided by the .NET SDK from the <windir>Microsoft.NETFramework<FrameworkVersion> directory. This has two advantages:

• The first request of each page gets accelerated because it’s completely compiled already.


• You can detect and fix all compilation errors at once.

Precompilation does more for you than previous versions of VS .NET did. The ASPX files are converted to classes and stored as DLLs in the Bin directory together with any code-beside files as well as files in the App_Code directory.

After the first in-place precompilation, any changes are included incrementally. This kind of compilation makes sense even if there are only small changes.

Precompilation for Deployment

The other type of precompilation is targeted for a different purpose. It allows you to distribute an entire compiled web site compiled as DLLs. In contrast to previous versions of VS. NET, the compiled version includes ASPX pages, ASCX files, and so on with the design, because they’ve been converted to classes and compiled too.

You can copy the result of this compilation to your server by using XCopy or you can ship it to your customers. After that, it isn’t possible for the customer to change the application or any of the pages.

To achieve this in VS.NET 2005, select Publish Web Site from the Build Menu. This will present you with a dialog (Figure 8) asking where you want to publishing your application. Once you select the path the application will be built, precompiled and deployed. You also have the option to enable your site to be updatable if you expect to be changing the layout in the ASPX files at a later point.

Figure 8. The publish web site dialog.

Have a look at the result of the compilation and you’ll see that it has almost the same structure as your web site. Here you can recognize your ASPX files among other things. But they’re used as markers for IIS, and they contain just a message and no design (provided you unchecked Allow this precompiled site to be updatable option while publishing ). Files with the extension .compile in the Bin directory are important; they’re necessary to establish the allocation between pages and the generated assemblies.

To transfer the web site to a server, copy the whole folder. Please don’t delete any of the files-they’re all required for execution.

Deploying Web Sites

Deployment is much easier with the help of the previously described precompilation. Using the same Publish Web Site dialog you can select to deploy to local IIS, FTP location or a site with FrontPage extensions enabled. You won’t need any other tools for deployment except your IDE.

Customizing the IDE

Having heard a lot from developers on how they like to have their settings preserved and how they like to be in control of the IDE. The new version of VS has a highly configurable development environment. In particular, you can configure the formatting of text editors to fit your individual needs. Figure 7 shows a part of the Options dialog box. It allows you, for example, to specify in detail if a line break is inserted before an angle bracket in C#, how parameters should be arranged, and much more.

Figure 9. You can customize virtually any editor behavior.

Many of these options were of course present in VS.NET 2003, but there are many more options in VS2005. Also, for your convenience, you can save your complete settings as an XML file and copy it to a different system. This way, it’s possible to enforce companywide coding guidelines. Just select Import/Export Settings from the Tools menu. Figure 10 shows the Export Settings dialog box.

Figure 10. In the Import/Export Settings dialog box you back up, share, and reset your individual IDE settings.

Conclusion

This article covered enhancements made to VS 2005 to support the new compilation and code models in ASP.NET 2.0. We have seen that the VS 2005 IDE offers a number of interesting improvements, such as better integration of teamwork-related features, and it simplifies the creation of simple and even complex web sites.