Last time, we saw that there are severe limitations in creating ASPX pages which inherit generic base classes. Many readers were probably wondering how ASP.Net MVC works around this limitation. In ASP.Net MVC views, people write pages like this all the time:
<%@ Page Language="C#" Inherits="ViewPage<IEnumerable<DataLayer.Product>>" %>
ASP.Net MVC includes its own workaround for these limitations. The Web.config file in the Views folder of an ASP.Net MVC project registers a PageParserFilter:
<pages validateRequest="false" pageParserFilterType="System.Web.Mvc.ViewTypeParserFilter, System.Web.Mvc, Version=220.127.116.11, Culture=neutral, PublicKeyToken=31BF3856AD364E35" ...> ... </pages>
PageParserFilter is one of ASP.Net’s lesser-known extensibility points. It can intercept different parts in the parsing process for an ASPX page and modify the page. The MVC framework’s ViewTypeParserFilter will check whether the page’s
inherits="" attribute contains
( or a
< characters; these characters can only appear in C# or VB.Net generic types, but not in the CLR’s native syntax.
inherits="" attribute contains these characters, it will save the attribute’s original value, then replace it with
ViewUserControl, as appropriate). This way, the rest of the built-in ASP.Net parser will see a normal type name that it knows how to parse. After the page finishes parsing, an internal ControlBuilder registered on MVC’s base types (
ViewUserControl) will replace the base type in the generated CodeDOM tree with the original value of the
The one problem with the hack is that it leaves the ASPX parsing engine unaware of the page’s actual base type. Therefore, if you make a page that inherits a generic base class with additional properties, you won’t be able to set those properties in the
<%@ Page declaration (since the ASPX parser won’t know about them). If you inherit a non-generic type, this mechanism will not kick in and page properties will work fine.