Code Directory

Earlier in the chapter I mentioned that an explicit compilation isn't required anymore. But what about your business objects, your application layer, and your data layer? Well, that's why you have the new code directory.

The code directory looks like nothing more than an ordinary folder, but it's actually quite special. It lives inside of the application root. Any source code files such as *.vb or *.cs files, but also resource files and even Web Services Description Language (WSDL) files, are saved here. Every supported file is compiled dynamically and is available instantly after you save it.

Using the Code Directory

To experience the code directory in action, you must first create a new folder with the given name "code" by right-clicking the project and choosing New Folder from the context menu. 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 Listing 2-1, to the folder, attach the method Bar, and save the new file.

Listing 2-1: Adding the Foo Class to a Code Directory

 using System; /// <summary> /// Summary description for Foo /// </summary> public class Foo {    public void Bar()    {    } } 

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

Figure 2-18: 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, the 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 to add or remove files. Changes become effective on a global basis very easily.

Multilanguage and Multitype Support

With ASP.NET you're no longer limited to one language per web site. You can now mix different .NET languages whenever you want. Does it make sense to write one page in C#, a second in VB .NET, and a third in J#? I don't know, but at least it's possible!

Another option is to mix different languages using the code directory. The Foo class written in C# and shown in Listing 2-1 works fine with VB .NET pages. This includes full IntelliSense support. But be aware that debugging isn't fully supported in such a scenario, so you can't jump from your VB .NET page to the C# source code. This is currently a major strike against using different languages. However, this will presumably be fixed within the Beta version.

As I mentioned previously, you can store many different file types in the code directory. Besides the programming languages' source code files, the following types are supported:

• RESX

• RESOURCES

• WSDL

• XSD

This list can be individually extended by a provider model. Corresponding abstract base classes are available in the System.Web.Compilation namespace. Just let your custom provider inherit from a base class and then assign the desired file extensions to it in the machine.config or web.config file.

What Happened to the Bin Directory?

Not much, it's still alive. But I wouldn't mention it if there hadn't been some changes. Because web projects are no longer compiled explicitly, there is no single project dynamic link library (DLL) anymore besides the already mentioned precompilation DLL. But external components are referenced in the bin directory further on.

To include a DLL in VS .NET, you just have to copy the bin directory. As a result, the contained classes are automatically available, with IntelliSense support, of course.