As for Application pages, you will find that they are not
usually directly part of your Site. Often, standard users will not even see the
majority of these files. As stated above, these are generally used as
administrative pages. As such, it is common for only administrators to work
with these pages. Like Site pages, Application pages generally use a master
page to enforce a consistent look and feel, but in this case they will mostly
use the ~/_layouts/application.master page.
Which brings up a common question… can you make Site and
Application pages look exactly the same? Of course the answer is yes and no.
Quoting roughly from the MSDN TechNet, you can create custom application pages
to add user interface components to a custom solution, based on Microsoft
Windows SharePoint Services 3.0. But unlike Site pages (for example, the
default.aspx page), a custom application page is deployed once per Web server
and cannot (easily) be customized on a site-by-site basis. So, in many cases,
it is likely that your Application pages will look like all other Application
pages. They may be made to look like a sites Site pages by using the same
Master page, but they then may not look like others Sites. This becomes the problem
in trying to make your Application pages look the same to all Sites, as long as
the sites look different. It is a common complaint of SharePoint by
non-developers who say "we go through the effort to
make a whole new look and feel, but certain pages, like error pages, still look
like SharePoint, no matter what we do." Now, with that said, you can programmatically change the Master page used in the
Application pages to match your Site and Site pages, but there is likely to be
a lot of work on your part… in fact there would be a lot of Application page
code manipulation. This is what would be needed to make the Application pages
of a site make that look like that site, rather than the generic, basic blue
you always get in most SharePoint websites. Once you realize the amount of
adaptation, then testing required, you would likely do well to ask your manager
if he or she really wants to pay for all of this work.
Now before I continue, I want to warn you that the word
"layout" is about to be used several times. There is no link between
these words in the context of this writing. I recommend for the time being that
you simply look at them in different meanings and not think too deep into it.
Now we will look at some differences about Application
pages. First off, they are based in the virtual directories in relation to each
site. This is what makes them available to every Site because they are common
to each SharePoint website, and because they affect the layout of the
Application pages versus the look and feel of each site, as described in the
Site pages section previously. If you open the IIS controls for the site you
are working on, you will see that there are many virtual directories, most of
them with an underscore. The two illustrations below are common examples of
what you will find when viewing the WSS site settings. The first illustration
is intended to display the layout of a SharePoint site while the second layout
illustration is intended to display the location of where these virtual
directories point to.
Notice especially the _layouts virtual directory. I wrote a
previous article on building an empty Feature, specifically for the purpose of
describing one way to create an empty Feature (http://aspalliance.com/1640_Developing_and_Deploying_a_SharePoint_Feature__Part_1.all).
That article discusses how to layout your project for the specific purpose of
emulating the structure of a SharePoint project to make the deploy process move
along smoothly. In this case you would do the same, including a mock LAYOUTS
directory in your solution that will line up with the layouts directory used in
the real SharePoint environment. When you create your own application pages,
this is where the pages will be put, so they deploy to the properly
corresponding location in your Site. Then you should make your own specific
subdirectory, based on your project name or such, to ensure that your pages do
not collide with existing pages.
More about Application Pages
With the information stated above, you can see why the
application pages will tend to take on a look and feel of their own and why it
is so hard to make the Application pages match multiple Sites when those sites
use different looks. Now, that said, there are several positive aspects to
Application pages. First is that they are file based. Second, they allow
in-line scripting where Site pages do not. Finally, they are, by default,
compiled into individual DLLs and loaded into memory. In all, it is a fact that
they are more powerful and run faster than Site pages.
So why not make a site that runs on all Application pages?
Well, it probably could be done, but there are drawbacks to this idea, some
which even challenge the idea of using SharePoint in the first place.
Application pages do not allow user customization. So, for example, you will
not be able to use Share Point Designer, or at least not in the way it was
intended to be used to connect to a SharePoint site and manipulate Site pages.
Furthermore, it will be more difficult to take advantage of web-parts and
The development and deployment of Application pages is a
fairly manual process, as you will later see. You may ask, what if I have a site
that will not need Site page features and is going to primarily be a
non-user-adjustable site? The initial answer is two-fold. Yes, you can do this,
but then, are you really in need of SharePoint? Why not just use ASP.NET alone
and avoid SharePoint all together?
That being said, I can make a few examples of where an all
Application page site would be useful. The first example is to ask if this is
an initial use of SharePoint in your environment. I have asked instructors and
others with far more skills in SharePoint than myself a similar question
because I can foresee, and have run into, the idea of converting an existing
site to SharePoint, while still facing concern or outright hostility from
others. For example, you may be in a place that does not yet use SharePoint. So
your argument may be that you can or would convert an existing site to an
Applications page based SharePoint site, and then slowly "reach out"
into SharePoint and pull in functionality. The pages from the original site
will of course need to be modified, but it seems to me that this could be one
way to make the argument to use SharePoint. Another all-Applications page
argument may be that a particular Site does not need a lot of user interaction
or web-part usage. Perhaps it will even hook other SharePoint sites and the
idea of "speaking SharePoint object model" as well as ASP.NET is
useful. No doubt it can be done, but you need to decide if this is what you
But again, in the favor of one of the above mentioned ideas,
using Application pages to get started, rather than just straight ASP.NET, you
may want to consider the ability to deploy functionality as Features, thus
pushing your skills along with the needs that just happen to creep in (smile).
Another argument to toss around is that with an all Applications page-based
site you will not need to build web-parts yet. Along with that, to build a Site
page driven Site, you almost must build a master page with user sections and
web-part containers. The effort level is higher to satisfy users who may not
even need to be included yet. After that, development debugging can be more
difficult, at least in part due to the fact that your Site Pages are, by
default, held in the content database.