Some Background on the VS 2003 Code-behind Model for ASP.NET Applications
ASP.NET Pages in a VS 2003 web project have two files associated with them -- one is a .aspx file that contains the html and declarative server control markup, and the other is a .vb "code-behind" file that contains the UI logic for the page:
Control markup declarations are defined within the .aspx file itself. For example:
And corresponding protected field declarations are added in the .vb code-behind class that match the name and type of controls defined within the .aspx file. For example:
ASP.NET does the work of wiring up a reference from this code-behind field declaration to point to the declared control in the .aspx file at runtime. Developers can then program directly against this control within their code-behind file.
VS 2003 automatically adds/updates these protected control field declarations, as well as adds tool-generated code to keep things in sync with the design-surface using a hidden region block inside the code-behind class file:
There are two common complaints/problems with this:
1) VS 2003 is adding/deleting code in the same file where the developer is authoring their own code -- and accidental conflicts/mistakes do end up happening (for example: some code that the developer writes can sometimes get modified or deleted by VS). The tool-generated hidden block above is also a little "messy" for some people's tastes.
2) The control-declarations are only updated when a developer using VS 2003 activates the WYSIWYG page designer. If a developer is only using the source-editor to customize the page, they will not get control updates, and will instead have to add these control declarations manually (which is a pain).
VS 2005 Code-behind Model for ASP.NET Applications
VS 2005 uses a code-behind model conceptually the same as VS 2003. Specifically, each .aspx page continues to inherit from a code-behind class that contains protected control field references for each control in the .aspx page:
What is different between VS 2003 and VS 2005 is that Visual Studio no longer injects its tool-specific wire-up code in the developer's code-behind file. Instead, it takes advantage of a new language feature in C# and VB called "partial types" (or partial classes) to split the code-behind implementation across two files. One of these partial class files is the developer-owned code-behind file that contains developer-written event-handlers and code for the page. The other partial class file is then a tool-generated/maintained file that contains the protected control field declarations and the other design-time code that Visual Studio requires. The benefit of splitting them out into two separate files at design-time is that it ensures that the code that VS creates and maintains never interferes (or deletes) code that a developer writes. At compile-time, these files are compiled together and generate a single code-behind class.
With the VS 2005 Web Application project model, the design-time partial class is generated and persisted on disk by VS 2005. This new design-time partial-class file has the filename naming pattern: PageName.aspx.designer.vb. If you click "Show All Files" in your solution explorer, you can see this file listed under the associated Page.aspx file along with the developer-owned code-behind file:
You can open up the code-behind file for your page by right-clicking on the .aspx file and choosing the "View Code" context menu item:
You'll then see the code-behind logic of the page -- which contains all of the code and event handlers that a developer writes (and no tool-generated "code-spit" content -- which means it stays very clean):
You can open up the code-gen designer file for your page by right-clicking on the .aspx file and choosing the "View Code Gen" context menu item:
You'll then see the design-time code of the page -- which contains the field declarations for controls within the .aspx page:
Because the _Default class is marked as "partial" in both of the above two files, the compiler will merge them into a single generated class at compile-time. This means that any variable, method or field generated in the default.aspx.designer.vb file can be used from the default.aspx.vb code-behind file (just as if it was declared in the code-behind file itself). For example, within the Page_Load event handler we could easily add the below code that uses the "Label1" and "Calendar1" control:
This will compile clean and run just fine -- because the "Label1" and "Calendar1" field references have been defined within the default.aspx.designer.vb file.
When you do a build inside a VS 2005 Web Application project, all pages, user-controls, master pages (and their associated code-behind files+design-time generated files), along with all other standalone classes within the project are compiled into a single assembly. This is the same behavior as with VS 2003.
Source http://webproject.scottgu.com/VisualBasic
Reviews:
Post a Comment