Daily .Net Feeds - ASP.Net 2.0 - Advanced - Day 12

Hi Everyone,

Welcome back!!!

As mentioned earlier, today we will discuss about the ASP.Net 2.0 reserved folders. There a number of reserved folders that you will see applicable to an ASP.Net 2.0 application. We will now try to understand what each of these is and what their respective purposes are. As there are many such folders, and each has its own associated concept, we will see a few today and the remaining tomorrow:

Folder name	File Types	Notes
Bin	.dll	Contains any prebuilt assemblies required by the application.
App_Browsers	.browser	Contains application-specific browser definition files that ASP.NET uses to identify individual browsers and determine their capabilities.
App_Code	.cs, .vb, .xsd, custom file types	Contains source class files to compile as part of the application. ASP.NET compiles the code in this folder when pages are requested. Code in the folder is referenced automatically in applications.
App_Data	.mdb, .mdf, .xml	Contains Microsoft Office Access and SQL Express files as well as XML files or other data stores.
App_GlobalResources	.resx	Contains resource files to be used programmatically in the localization of an application.
App_LocalResources	.resx	Contains page-scoped resource files.
App_Themes	.skin, .css, .xsl, auxiliary files	Contains a collection of files that define the appearance of ASP.NET pages and controls.
App_WebReferences	.wsdl	Contains WSDL files to generate proxy classes and other files associated with using Web services in your application.

The Bin Folder:

The Bin folder contains all deployable assemblies required by the application for controls, components, or other code that you want to reference. Any .dll files found in the directory will be automatically linked to the application. If unused or outdated files are left around, the risk is that you'll get "ambiguous reference" exceptions. In other words, if two distinct assemblies define the same class (same namespace and class name), the ASP.NET runtime can't resolve which one to use and raises an exception. This is a common error when, at development time, you rename a project or an assembly name. To avoid that, make sure that no unnecessary assembly is found or at least remove the following line from the <assemblies> section in the configuration file:

<add assembly="*" />

Of all the folders listed in above table, only Bin is recognized by ASP.NET 1.x applications also.

The App_Browsers Folder:

This folder contains .browser files. A .browser file describes characteristics and capabilities of a browser—be it a mobile device or a desktop browser. ASP.NET installs a bunch of .browser files in the Config\Browsers folder under the installation path. These files are shared by all applications. You place under the App_Browsers folder only the browser files specific to the current application. The content of the .browser file is compiled on the fly to provide up-to-date browser information to the ASP.NET runtime. Let's briefly address a scenario in which having a custom .browser file might be helpful. Imagine that your application uses a control that doesn't render effectively under a certain browser. You can write a .browser file to force ASP.NET to use a different adapter to render that control when the host page is served by the specified browser.

<browsers> <browser id="browserID"> <controlAdapters> <adapter controlType="Samples.CustomControl" adapterType="Samples.Adapters.CustomControlAdapter" /> </controlAdapters> </browser> </browsers>

Assuming that browserID matches one of the standard browsers recognized by ASP.NET, the .browser file just shown dictates that CustomControlAdapter be used to render CustomControl under the specified browser.

The App_Code Folder:

The App_Code subdirectory lives immediately underneath the Web application's root and stores all class files that should be dynamically compiled as part of the application. These class files get automatically linked to the application and don't require you to add any explicit directive or declaration in the page to create the dependency. Class files placed in the App_Code folder can contain any recognized ASP.NET component—custom controls, helper classes, build providers, business classes, custom providers, HTTP handlers, and so on.

Note: At development time, changes to the App_Code folder cause the whole application to be recompiled. For large projects, this can be undesirable and time-consuming. For this reason, I encourage you to modularize your code into distinct class libraries in which you group logically related sets of classes. Mostly helper classes specific to the application should make their way into the App_Code folder.

All class files dropped into the App_Code folder should use the same language. If you have class files written in two or more languages, you must create language-specific subdirectories to contain classes for each language you support. Once files have been grouped by language, you add an entry to the web.config file for each subdirectory:

<compilation> <codeSubDirectories> <add directoryName="VBFolder" /> </codeSubDirectories> </compilation>

It is important that the language-specific subdirectory is registered in the web.config file; otherwise, all files underneath App_Code will be compiled to a single assembly regardless of the folder they belong to. The preceding configuration script delineates a situation in which all, say, C# files are in the root App_Code, and a few Visual Basic .NET class files are moved into the VBFolder directory. If a directory mentioned in the <codeSubDirectories> section doesn't exist, you'll receive a compilation error. Files in the root App_Code folder are compiled to App_Code_xxx.dll assembly, where xxx is a randomly generated sequence of characters. Files in a given subdirectory will be compiled to a dynamically created assembly named App_SubCode_xxx_yyy.dll, where xxx indicates the name of the subdirectory and yyy is a random sequence of characters. The <codeSubDirectories> section is valid only if it is set in the web.config file in the application root.

A strongly named assembly can be created by dropping an assemblyinfo.cs file in the App_Code directory or any other subdirectory you might have. Obviously, you'll use an assemblyinfo.vb file if the folder contains Visual Basic .NET files. The assembly configuration file may refer to a .snk file to contain the key for the strong name.

Note 1: To sign an assembly with a strong name, you must first obtain a public/private key pair. You can get such a key pair by using the Strong Name tool (sn.exe), one of the SDK binaries you'll find in the installation path of the .NET Framework. Key pair files usually have a .snk extension. You save this file to an application folder and reference it in the assemblyinfo.cs file, as shown here:

[assembly: AssemblyKeyFileAttribute(@"yourKeyPair.snk")]

Note 2: Visual Basic .NET looks for the key file in the directory containing the Visual Studio Solution, whereas the C# compiler looks for the key file in the directory containing the binary. In light of this, adjust the path you use with the attribute, or place the key file in the proper folder.

On any subsequent rebuild, the names for assemblies change, and as soon as the old AppDomain requests cycle out, the old assemblies are removed. The App_Code folder can contain more than just class files. In particular, it can contain and automatically process XSD files representing a schema of data. When an XSD file is added to the folder, the compiler will parse it to a typed DataSet class, which will be added to the application scope. In ASP.NET 1.x, this work is accomplished by a Visual Studio .NET wizard and uses a command-line utility under the hood—xsd.exe.

Note: When you register a component (for example, a custom server control or a custom HTTP handler) with the web.config file, you are typically requested to specify the name of the assembly that contains the code. If the component is defined in the App_Code folder, which name should you indicate for the assembly? In this case, you just omit the assembly information and specify only the full class name. When no assembly is specified, the ASP.NET runtime attempts to load the class from any loaded assemblies, including the dynamically created assembly for the App_Code folder.

That's it for today. Thanks for joining!!! See you tomorrow. Tomorrow we will continue this discussion and will deal with the remaining ASP.Net 2.0 reserved folders – namely App_Data, App_GlobalResources, App_LocalResources, App_Themes, App_WebReferences. In the following days we will look at what are build providers and a sample custom build provider.

Thanks,

Sukesh Khare
Coordinator Daily .Net Feed Program

Comments

• Anonymous
  July 23, 2007
  The comment has been removed

• Anonymous
  July 25, 2007
  ich schaue mich mal um...

• Anonymous
  August 09, 2007
  The comment has been removed