Partager via

Shared Code Folders in ASP.NET Web Site Projects

  • Article

If your Web site project 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: compiled code (.dll files) go in the Bin folder and source code goes in the App_Code folder. When you create these folders and store particular types of files in them, ASP.NET handles 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.

Bin Folder

You can store compiled assemblies (.dll files) 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.

Note

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.

Note

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.

  • When you run a project in Visual Studio, code in the Bin folder runs in a different context than at run time. The Visual Studio Development Server runs under your logged-in identity. If you logged in as an administrator, the code will run with administrator permissions. When you deploy your site, however, the code typically does not run with administrator permissions. Therefore you should test your project with a IIS server before deploying it, to make sure that security errors do not occur in production.

App_Code Folder

In a Web site project, 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.

Note

User controls (ascx files) are not allowed in the App_Code folder. This includes 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. (In any event, 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 application Web.config file or the machine-level Web.config file. Compilers are named build providers and a build provider is specified for each file extension in an extension element.

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.

See Also

Concepts

ASP.NET Web Project Folder Structure

Other Resources

ASP.NET Web Projects

Web Application Projects versus Web Site Projects in Visual Studio