I have done many a search on this issue with mixed results and ensuing ambiguity. The time has come to nail it down for good. If I'm developing the equivalent of a complex ASP.NET application, and I want to run it on top of SharePoint 2010, is it best to develop each page as a web part or an ASPX application page? The pages are many and varied, but each one interacts with a SQL 2008 R2 backend via custom WCF services.

I have yet to see a definitive and authoritative answer to this question. I'm looking for an official guideline from Microsoft or similar. I found this When to use application pages (aspx) versus web parts? on this site, but I'm looking to dig deeper with specific references. Here's a breakdown of what I have found so far:

The following non-official post would clearly favor application pages for my case. However, it was posted back in the MOSS 2007 days, when SharePoint development was more of a challenge. http://grounding.co.za/blogs/brett/archive/2008/07/13/sharepoint-the-role-of-a-web-part-vs-using-application-pages.aspx

Microsoft, in comparing application pages to site pages, states, “An application page is the best type of page to create if you want the page to contain custom code.” http://msdn.microsoft.com/en-us/library/ee231581.aspx

So far, so good. But what threw me off was this other seemingly contradictory link, also from MS: "We currently recommend that third-party developers develop custom Web Parts, which can be added to site pages, to handle their solution's functionality whenever possible, rather than develop custom application pages.” (http://msdn.microsoft.com/en-us/library/gg552610.aspx)

I'm biased toward application pages because that's what our team has been using all along and has had no problems. Everything from the development experience to debugging and deployment support has been top notch. But internal forces are pushing for us to make the switch to web parts, so I'm looking for justification.

  • Converted this to community wiki. – SPDoctor Dec 19 '11 at 18:32

My general rule of thumb on application page versus web part is re-usabilty...i.e. do I need to surface the capability in more than one location within a site.

If I'm only going to surface a single instance of the functionality then surfacing that capability via an application page is the way to go because they are much easier to build, deploy, and maintain versus a web part...IMO anyway. The other challenge you have with web parts is they can be used in ways they were not intended to be used...i.e. you, as a developer, can't control what an admin does with the web part. It could be used in a context, with other web parts, that causes it or the other parts on the page not to work. An application page however has a singular purpose/function that can not easily be co-opted for another purpose/function.

That being said, if I have a current (...or perceive a future) requirement to leverage the functionality in multiple locations then it probably makes more sense to go the web part route, but that's not a hard and fast rule either. A recent example for me was a contact widget that the customer wanted displayed on multiple locations on the site. At first it seemed like a no-brainer for a little web part, but after digging into the requirements some more some on the team did not want to give up the real estate to surface it on all the necessary pages, so I ended up implementing it in an application page, dropping a button on the necessary site page, and popping up the contact form in a dialog.

Like most things SharePoint it's one of those "it depends" questions, but I think it's safe and probably prudent to start from a "I'm going to build an application page" position and see if there is an obvious rationale for moving away from that. The inverse of that doesn't make much sense to me.

  • Thanks, good info. So far I'm seeing no obvious rationale for moving to web parts for our mainline app. The pages will only occur once per site, and we don't necessarily want the user fiddling with that constraint. – anon Aug 12 '11 at 22:00

One important thing is the performance aspect! Application pages are compiled when first accessed whereas site pages are not compiled.

Another important aspect is that Site Pages does only support controls marked as SafeControls and inline code is not possible (without fiddling with security).


I suppose the attraction of application pages is that they are much closer to being a "normal" aspx page. You say you are building what is, in effect, an aspx application on top of SharePoint. If this is a custom application that you do not anticipate re-using, and it doesn't need to be modular or modifiable by users, then maybe application pages are the best solution for you. Application pages can also be very efficient at runtime.

In general, and particularly for third party application developers (and I think this is probably the group that Microsoft's second quoted recommendation is aimed at), then web parts and site pages are the way to go for many reasons. Here's a few: composition, re-use, end-user configureable, potential use in the sandbox, no touching the filesystem.

  • Good point now that I think about it in that Microsoft's second quotation seems to be aimed more at ISVs. I think we're going to stick with application pages for now. – anon Aug 12 '11 at 21:56

I see mostly disadvantages with custom application pages when using these as content pages:

  • Are accessible from all applications and sites in the farm (that may not be intended)
  • Are not in the 'security context' of a site - you have to implement access control to these pages yourself (eventhough this is not a big deal)
  • Are very unflexible
  • Cannot be 'customized' out-of-the-box by users/administrators

I usually tend to create Visual WebParts using a Model View Presenter (MVP) pattern. This gives you a good code structure, better testability and enables you to use the WebPart in multiple places. Also you can expose a couple of options that users and/or administrators can set on the web part to change its behaviour. When building visual web part you have all the advantages that you have when creating custom application pages as there is full designer support.

An alternative for greater flexibility is to create user controls (ASCX) and place these i web parts and/or custom application pages.

  • 4
    All four of your bullet points make Application Pages great for many use-cases. Configuration pages, for one example. Also, they have no "Security Context", but it's easy to set up in the codebehind/codebeside for the page, and they do have an SPContext object, populated in the same way it would be in a Control on a page. – James Love Aug 10 '11 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.