When using the code-behind method of developing ASP.NET pages, you usually have a Page directive at the top of the .aspx page that looks something like:

<%@ Page language="c#" Inherits="Project1.index" %>

As long as you have successfully precompiled the project that this .aspx file is in, you can simply deploy the associated assembly file(s) to the /bin directory of the ASP.NET application and do away with (not deploy) the aspx.cs (code-behind) file. The reason for this? When the .aspx page is JIT-compiled for the first time, all of the assemblies in the /bin directory of the application are implicitly referenced, and it will be able to get the type information from there, without needing the code-behind file.

This means that whenever a change to the code-behind file is made, we must recompile and redeploy the assembly. This is a bit of a pain, but we do get some nice things with this method, such as being able to catch compile-time errors and have control over which version of the framework is used for compilation.

What does this have to do with the src attribute of the Page directive (which is missing from the above code snippet)? Well, instead of deploying the assembly file to the /bin directory, you can include the src attribute in the Page directive like so:

<%@ Page language="c#" src="index.aspx.cs" Inherits="Project1.index" %>

Now you will have to make sure to deploy the .cs files for those pages for which you will use this technique, otherwise they will either revert to the assembly for type information (if it is there) or it will blow up. Now, why would you want to use this technique? Couple of reasons: the problem of changing the code-behind and needing to recompile and redeploy the assembly are gone, and when these compile, they will use the most recent version of the framework on the web server instead of the one used to compile the assembly, if you were using that method.