这显然是一个非常明智而且很早就应该实现的做法，因为已经在HTML中声明为runat="server"的控件，就应该算是声明过，还要在code-behind中同步的用C#代码再声明一个同名控件显然是违反了《程序员修炼之道》中所谓的DRY(Don't Repeat Yourself)原则。
原本ASP.NET 1.x的编译模型是编译站点时先编译code-behind部分，然后得到code-behind部分的Page派生类，等到运行时再编译aspx部分此事得到code-behind部分的派生类（也就是Page的二级派生类），而一旦aspx和code-behind出现控件声明的不同步那么这个继承关系将出现问题。
ASP.NET 2.0的做法就是把aspx和code-behind都看作Page派生类的partial class，并且合成编译，而aspx中所有的控件声明都将在编译时自动转换为C#声明，这样的好处是只有一层Page派生类而且不用同步什么东西，所有东西都是仅声明一次。不过有一个问题就是，到底aspx中的声明是转换为C#的partial class再编译还是能够直接编译呢？转换为C#编译是很直接的思路，ASP.NET 2.0 的内部变化也是说原本由VS.NET 2002/2003做的声明同步工作现在交给ASP.NET Runtime了，但是这样就有一个问题，如果要开发一种新的ASP.NET语言（例如Delphi for ASP.NET 2.0），那么也就必须建立aspx到该语言的翻译，这是十分麻烦的事情。但是如果aspx和code-behind分开编译的话，这好像超出了partial class的能力范围，根据C# 2.0的规范，partial class的所有部分必须是同时编译的，不可以是增量编译的，也不可以是跨语言编译的，而aspx和code-behind都直接编译的话就需要双语言编译，也就需要增量编译。
ASP.NET 2.0还有一个很好的地方，就是部署编译，你能够把整个网站都编译了（包括aspx和code-behind）然后发布，发布目标的aspx将是一个仅引用后台类的控文件，这样性能最好而且也不用担心代码泄漏（特别是编译后的dll再混淆一下的话）。不过因为aspx部分也编译了，所以这样发布的网站发布之后就不能改动。而ASP.NET 2.0还提供另一个极端，就是完全运行时编译。以前ASP.NET 1.x如果是code-behind的话，code-behind部分就必须在VS.NET里面先编译，不过现在ASP.NET 2.0能够自动监测code-behind部分是否有改动过（甚至是/App_Code目录下的其他非UI逻辑的code），如果有就运行时编译，这对于调试来说是挺方便的，不需要每次调时前先在VS.NET里面按Ctrl+Shift+B编译。