Detailed description of ASP. NET retaining folders

1. Bin folder
The Bin folder contains the deployable assembly required by the application for controls, components, or any other code to be referenced. Any. dll files in this directory are automatically linked to the application. If unnecessary or expired files are left in the folder, the "ambiguous reference" exception may occur. In other words, if two different assemblies define the same class (the same namespace and name), the ASP. NET Runtime Library cannot decide which assembly should be used, thus throwing an exception. This is a common error during development when we rename a project or assembly. To avoid this error, do not retain unnecessary assembly in this folder, or delete the following code lines from the <assemblies> section of the configuration file at least:
<Add assembly = "*"/>
Only Bin in all folders listed in table 1.10 can be recognized by ASP. NET 1. x applications. This folder is mandatory.
2. App_Browser folder
This optional folder contains the. browser file .. The browser file describes the features and functions of browsers (whether mobile devices or desktop browsers. ASP. NET has installed a large number of. Browser files in the Config \ browser folder under the installation path, which are shared by all applications. We just put the Browser file exclusive to the current application in the App_Browser folder .. The content of the browser file is instantly and dynamically compiled to provide the latest browser information to the ASP. NET Runtime Library.
Let's briefly talk about scenarios where a custom. browser file may be helpful. Imagine that the application uses a control that cannot be effectively rendered in a browser. When the host page is displayed in the specified browser, you can write a. browser file to force ASP. NET to generate the control using a different adapter.
<Browsers>
<Browser id = "browserID">
<ControlAdapters>
<Adapter controlType = "Samples. CustomControl"
AdapterType = "Samples. Adapters. CustomControlAdapter"/>
</ControlAdapters>
</Browser>
</Browsers>
If browserID matches one of the standard browsers recognized by ASP. NET, The. browser file shown above indicates that CustomControlAdapter is used to render CustomControl in the specified browser.
3. App_Code folder
The App_Code folder is located in the root directory of the Web application. It stores all class files that should be dynamically compiled as part of the application. These class files are automatically linked to the application without adding any explicit commands or declarations on the page to create dependencies. The class files placed in the App_Code folder can contain any identifiable ASP. NET component-custom controls, helper classes, build providers, business classes, custom providers, and HTTP processing programs.
Note that during development, changes to the App_Code folder will cause the entire application to be re-compiled. This may be undesirable and time-consuming for large projects. To this end, we encourage you to modularize the code into different class libraries and organize the code according to the logically related class sets. Most of the helper classes dedicated to applications should be placed in the App_Code folder.
All class files stored in the App_Code folder should use the same language. If a class file is written in two or more languages, you must create subdirectories in a specific language to contain classes written in each language. Once these class files are organized by language, you must add a setting for each subdirectory in the web. config file:
<Compilation>
<CodeSubDirectories>
<Add directoryName = "VBFolder"/>
</CodeSubDirectories>
</Compilation>
It is important that subdirectories in specific languages should be registered in the web. config file. Otherwise, all files in the App_Code folder will be compiled into a separate assembly no matter which folder they belong. The preceding configuration script describes the situation where all C # files are stored in the root directory of the App_Code folder, and several Visual Basic. NET files are moved to the VBFolder directory. If the directory mentioned in the <codeSubDirectories> section does not exist, a compilation error is reported.
Files in the App_Code root folder are compiled into the App_Code_xxx.dll assembly, where xxx is a random character sequence. The file in a given subdirectory will be compiled into a dynamically created Assembly named App_SubCode_xxx_yyy.dll. xxx indicates the subdirectory name, And yyy indicates a random character sequence. The <codeSubDirectories> section is valid only when the web. config file in the application root directory is set.
Place an assemblyinfo. cs file in the App_Code directory or any other sub-directories to create a strongly-named assembly. Obviously, if the folder contains the Visual Basic. NET file, the assemblyinfo. vb file will be used. The assembly configuration file can reference A. snk file to save the key with a strong name.
Note: To set a strong name for an assembly, you must first obtain a public/private key pair. You can obtain such a key pair by using the Strong name (Strong name1_tool (sn.exe. The strong name tool is one of the SDK binary files that we can find in the. NET Framework installation path. A key pair file usually has a. snk extension. You can save the file to an application folder and reference it in the assemblyinfo. cs file, as shown below:
[Assembly: AssemblyKeyFileAttribute (@ "yourKeyPair. snk")]
Note that Visual Basic. NET is used to find the key file in the directory containing Visual Studio Solution, while the C # compiler searches for the key file in the directory containing the binary file. Therefore, we can use this attribute to adjust the path we are using or place the key file in a suitable folder.
In any subsequent re-generation, the Assembly name will change. At the same time, when the old AppDomain request ends, the old assembly will be deleted.
The App_Code Folder does not only contain class files. In particular, it can contain and can automatically process XSD files representing the data architecture. When you add an XSD file to this folder, the compiler parses it into a DataSet class with a type and adds it to the application scope. In ASP. NET 1. x, this job is directed by Visual Studio .netand completed by a command line program (xsd.exe.
Note: When registering a component (for example, a custom server control or a custom HTTP handler) using the web. config file, you must specify the Assembly name that contains the code. If the component is defined in the App_Code folder, what name should be used to indicate the assembly? In this case, you only need to ignore the assembly information and specify the complete class name. If no collation set is specified, the ASP. NET runtime attempts to load the class from any mounted assembly, including the Assembly dynamically created for the App_Code folder.
4. App_Data folder
The App_Data folder should contain the local data storage of the application. It usually contains data storage in the form of files (such as Microsoft Access or Microsoft SQL Server Express database, XML files, text files, and any other files supported by the application. The content of this folder cannot be processed by ASP. NET. This folder is the default location for ASP. NET providers to store their own data.
Note: by default, ASP. NET accounts are granted full access to folders. If you happen to change your ASP. NET account, make sure that the new account is granted read/write access to the folder.