众所周知，VS2005编写网站都是基于.NET2.0框架运行的。

微软在发布.NET2.0时，对ASP.NET网站的编程模型作出了一些调整。新增了MasterPage来帮助用户完成统一风格界面的创作。从编程角度来出发，则是更改了原来Page页和代码文件中的类继承模型，而是采用了Page页和代码文件同属于“部分类”，他们合起来形成一个完整的类，免去了在代码文件中维护控件对象与Page页中控件一致的烦恼。

.NET2.0中，发布网站也和.NET1.1的有所不同。.NET1.1是将所有Page类包装成程序集，页面文件仍然保持不变。当然.NET2.0也可以做到，不过在.NET2.0的预编译选项中，甚至将Page页面也封装到程序集中。尽管就整个网站看来，还有aspx后缀的文件存在，但是里面就只有一行说明文字了（如果你用的是中文版的VS，那么说明文字应该是“这是预编译工具生成的标记文件，不应被删除!”）这个文件仅仅是告诉IIS，文件系统中存在这个文件，不至于会产生“HTTP404”文件未找到的错误响应（如果你在IIS的应用程序影射中，将aspx的“确认文件存在”选上，就会导致这样的错误）。

相比之下，.NET2.0中的预编译把所有代码，包括HTML代码都包装起来了，整个网站可能会显得紧凑，有可能的话，你的网站只需要保留那个bin文件夹和一些必要的图片资源等就可以运行了。但是我更喜欢使用“允许更新”的预编译选项。这样的话，发布的网站仍然包含HTML代码，只是把与之关联的程序语言所写的类进行了编译，包装成程序集。这样的话，如果仅仅是HTML代码有修改，我可以很轻易地修改更新他们，而不至于整个站点重新发布一边。

好，讲了这么多似乎毫不相关的知识，现在开始进入正题。
不知道有没有人发现，如果使用了MasterPage，那么允许更新的预编译方式往往就不会成功。特别是，假如MasterPage中包含有程序逻辑（如属性，方法等），而你在使用MasterPage的Page页中需要编程修改或调用他们，这是你需要通过一个名字叫ASP的虚拟命名空间来找到他们。问题就在这里，使用这个虚拟名字空间，在生成网站，或者生成解决方案的时候并没有太大的问题，但是如果设置了“允许更新”的预编译来发布网站，他们就会报错。基本上是这样：在ASP名字空间中找不到某某类（是不是没有引用程序集？）。

这个问题让我们感觉非常棘手。因为在代码编辑器中，他们还是会被染成“浅蓝色”，这表明VS中，代码编辑器能够发现这个类是确实存在的。生成网站的时候会成功，并且也没有任何警告出现。发布网站是出现的这个错误提示，很多人都会去想找程序集引用近来，问题是这程序集应该就是网站本身生成的程序集。

起初发现这个问题，我试图重建了网站，把网站所带的引用重新整理一遍，设置把某些可能出错的地方注释掉，但问题依然存在。我不得不试图从网上找答案，但是不幸的是网络上人们似乎还没有发现这类问题，包括微软我也没有找到合理的解释。因此我换了一种方式发布，也就是把“允许更新的预编译”这个选项去掉，然后试图发布，结果就成功了。不过，发布的网站只剩下一堆空的aspx，一堆图片和一堆dll。想象一下，原来那样做网站维护工作就得改变思路。哪怕是一点点HTML布局上的改动，都得重新发布网站（如果使用固定名称的话，只需要替换对应名称的dll，但是免不了都要重新发布）。

究其原因，我想我还是不大明了。但是可以认为，.NET为其预编译后，改变了原本很好理解的运行模型。如果你用Reflector打开这些编译后的dll，你会发现和你原来所写的代码完全是两码事，他们变得非常难以理解，除非你完全知道.NET预编译模型的全部原理。

好了，尽管原因不甚明了，但是我们还是把问题解决了。至少现在我只知道能用这种方法来解决MasterPage应用的网站的发布。我将继续关注这类问题，期望会得到更好的解决。