|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
Shared Code Folders in ASP.NET Web Sites
Updated: May 2011
If your Web site application includes code that you want to share between pages, you can keep the code in one of two special folders underneath the root of your Web application, the Bin folder and the App_Code folder. When you create these folders and store particular types of files in them, ASP.NET handles the files in special ways. For information about how these folders work in Web application projects, see App_Code folder doesn't work with Web Application Projects on Vishal Joshi's blog.
You can store compiled assemblies in the Bin folder, and other code anywhere in the Web application (such as code for pages) automatically references it. A typical example is that you have the compiled code for a custom class. You can copy the compiled assembly to the Bin folder of your Web application and the class is then available to all pages.
Assemblies in the Bin folder do not need to be registered. The presence of a .dll file in the Bin folder is sufficient for ASP.NET to recognize it. If you change the .dll and write a new version of it to the Bin folder, ASP.NET detects the update and uses the new version of the .dll for new page requests from then on.
The Bin folder is used for managed-code assemblies, not for native-code (unmanaged-code) assemblies. For more information, see Loading C++ Assemblies in ASP.Net.
In ASP.NET 2.0 and later versions, you can put strong-named (signed) assemblies in the Bin folder. For information about why you should not do this in ASP.NET 1.0 or ASP.NET 1.1, see the KnowledgeBase article "Access Denied" Error Messages on the Microsoft support Web site.
Security with the Bin Folder
Putting compiled assemblies into the Bin folder can represent a security risk. If you wrote the code yourself and compiled it, then you know what the code does. However, you should treat compiled code in the Bin folder as you would treat any executable code. Be wary of compiled code until you have tested it and are confident that you understand what it does.
Note these security aspects of putting compiled code into the Bin folder:
Assemblies in Bin folder are scoped to the current application. Therefore, they cannot access resources or invoke code outside the current Web application.
At run time, the access levels of an assembly are established by the trust level specified on the local computer. For more information, see ASP.NET Trust Levels and Policy Files.
If you are working in a designer such as Visual Studio, code in the Bin folder runs in a different context than at run time. For example, the code might be running with full trust.
You can store source code in the App_Code folder, and it will be automatically compiled at run time. The resulting assembly is accessible to any other code in the Web application. The App_Code folder therefore works much like the Bin folder, except that you can store source code in it instead of compiled code. The App_Code folder and its special status in an ASP.NET Web application makes it possible to create custom classes and other source-code-only files and use them in your Web application without having to compile them independently.
The App_Code folder can contain source code files written as traditional class files — that is, files with a .vb extension, .cs extension, and so on. However, it can also include files that are not explicitly in a specific programming language. Examples include .wsdl (Web service description language) files and XML schema (.xsd) files. ASP.NET can compile these files into assemblies.
The App_Code folder can contain as many files and subfolders as you need. You can organize your source code in any way that you find convenient, and ASP.NET will still compile all of the code into a single assembly that is accessible to other code anywhere in the Web application.
User controls are not allowed in the App_Code folder. This includes both single-file user controls and user controls that use the code-behind model. Putting a user control .in the App_Code directory causes the user control's code to be compiled out of its required sequence and therefore is not allowed. Note that user controls do not need to be in the App_Code folder; they are already available to pages anywhere in the application.
Inferring the Programming Language of the App_Code Folder
The App_Code folder is not explicitly marked as containing files written in any one programming language. Instead, the ASP.NET infers which compiler to invoke for the App_Code folder based on the files it contains. If the App_Code folder contains .vb files, ASP.NET uses the Visual Basic compiler; if it contains .cs files, ASP.NET uses the C# compiler, and so on.
If the App_Code folder contains only files where the programming language is ambiguous, such as a .wsdl file, ASP.NET uses the default compiler for Web applications, as established in the compilation element of the Web application or machine configuration file.
Multiple Programming Languages in the App_Code Folder
Because the source code in the App_Code folder is compiled into a single assembly, all the files in the App_Code folder must be in the same programming language. For example, the App_Code folder cannot include source code in both Visual Basic and C#.
However, you can configure your Web application to treat subfolders of the App_Code folder as separate compilable units. Each folder can then contain source code in a different programming language. The configuration is specified by creating a codeSubDirectories element in the compilation element of the Web.config file and adding a reference to the subfolder. The following example illustrates how you would configure subfolders named VBCode and CSCode to compile into separate assemblies:
<compilation debug="false"> <codeSubDirectories> <add directoryName="VBCode" /> <add directoryName="CSCode" /> </codeSubDirectories> </compilation>
The references to the VBCode and CSCode subfolders do not need to include any information about what programming language is contained in the subfolder. As with the App_Code folder itself, ASP.NET infers the compiler to use based on the files in the subfolder.
Security with the App_Code Folder
Security issues with code in the App_Code folder are essentially the same as those with code in the Bin folder—the code is compiled into an assembly at runtime. A mitigating factor is that you can read the source code for files in the App_Code folder. However, if you do not fully understand the code, it can still represent a security risk. Therefore, treat source code in the App_Code folder as you would treat compiled code from the same source.