I have a MasterPage (Site1) and a content page (WebForm4), if I define the mastertype directive like this:

<%@ Page Language="C#" MasterPageFile="~/Site1.Master" AutoEventWireup="true" CodeBehind="WebForm4.aspx.cs" Inherits="WebApplication1.WebForm4" Title="Untitled Page" %>
<%@ MasterType TypeName="Site1" %>
<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">
</asp:Content>

I build the solution, everything seems OK. When I try to see it I get:

"Parser Error Message: Could not load type 'Site1'

It makes sense :), and its obviously fixed by doing:
<%@ MasterType TypeName="Namespace.Site1" %> (WebApplication1 in this case)

I think the compiler should prompt an error just like when you specify a non-existing/invalid mastertype.

That behavior is actually by design (although non-ideal). 

The reason that isn't being flagged at VS compile time is because with VS 2005 Web Application Projects only the code-behind and class files are getting compiled -- not the .aspx markup themselves (this is just like with VS 2003 web projects).  Because the Site1 type is defined within the same namespace as the pages, this technically compiles clean from the code-behind perspective (if you had named it Site2 you would have had a compile error). It is only at runtime when the page executes that it ends up that a fully qualified typename is needed.

One option to get better build-time validation is to hook up a web deployment project to the web application project.  This will perform a deep validation of all markup and .aspx content, and will flag a compiler error if something like the above isn't valid.  The reason we don't do this by default with VS 2005 WAP builds is because the perf impact would significantly impact usability.

Hope this helps,

Scott

Ah, I see. :)

Thanks for the reply.

Another solution is to use the VirtualPath property instead of the TypeName property for defining your MasterType. 

--
Danny