I often show people how to create custom site definitions with custom masterpages for their SharePoint sites. And, every time the dreaded application.master issue comes up.
SharePoint is a mix of database and server files (12 hive). The mixture of these shows the site. Basically, the database contains reference to piece together information from the 12 hive files to build a website.
However, there are some “static” pages in SharePoint for “helper” pages. These are called application pages or layout pages(because they show up under _layouts). You can always tell one of these pages because _layouts will be in your url.
Now, application pages cannot use the masterpage we create with our features or site definitions because they know nothing about the database. They have to use their own masterpage called application.master.
The application.master lives in the layouts folder with the rest of these files. Now, the issue is, there is one application.master for the entire server. So, if you have multiple web applications, customized different ways, they have to use the same application.master for the application (layout) pages.
Now, most of the application (layout) pages are for administrative functionality, however, there are a few the end users will see (for example: the search page).
So, how do we modify this application.master page.
Well, there are 2 approaches Microsoft recommends per their help article – http://support.microsoft.com/kb/944105:
1. Modify the application.master page – really Microsoft, you really want us to do this. You are the ones who say best practices are not to modify files from the 12 hive. Now, when you implement something that is not scalable you change your mind. I hate it when Microsoft does this. But, I still use this approach sometimes because it is so easy . So, what is the problem with this approach? First off, this modifies the application.master for your whole server – thus you can’t have mulitple web applications with different application master pages. Second, you are modifying 12 hive files and a SharePoint service pack could overwrite your changes (but this is unlikely).
2. Create a custom layouts folder – once again, really Microsoft. This seems like a horrible implementation to me. Another hack they are recommending to us. It gets you around the multiple web applications with different customization issues. However, it creates a maintenance nightmare.
Now, I do implement number 1 above if I don’t have much time and it won’t hurt my specific requirements. However, I don’t like either of the Microsoft recommendations and I think they should be ashamed this is what they recommend.
My suggestion is to use HTTPModules. I could explain the steps in this blog, but I would just be reiterating something I learned about in another blog. So, I will just give the link to the blog I learned how to do this in to give that author the credit: http://www.sharepointblogs.com/dwise/archive/2007/01/08/one-master-to-rule-them-all-two-actually.aspx
Maybe next version of SharePoint will make application.master configurations more scalable. But for now, creating httpmodules is our best option (at least it is the best option I have found so far).