There are various approaches to intergrating ASP.NET web application pages into SharePoint.
IFRAME Approach
By far the easiest way to integrate any web application into SharePoint is using an IFRAME which can be added to a SharePoint Page via a Content Editor Web Part.
| Pros | Cons |
|---|---|
| Extremely fast | No SharePoint Context |
| Web Application doesn't even have to be part of SharePoint IIS | Not easy to have the same look & feel |
| Can not use out-of-the-box security of SharePoint |
SharePoint Application Pages Approach
This approach deploys a standard ASP.NET Web Application into a subfolder of the _layouts directory in the SharePoint Web Application within IIS.
| Pros | Cons |
|---|---|
| Full access to SharePoint Context | Requires deployment to individual IIS Web Applications |
| Almost exactly the same as ASP.NET Web Development | Can't use Master Page of Site in context as it will use Application.master |
- Deploying ASP.NET Web Applications in the Windows SharePoint Services 3.0 _layouts Folder by MSDN
- Creating an ASP.NET Application in the "_layouts" Directory using the Visual Studio 2005 Plug-In "Web Application Project"
- Integrating ASP.NET 2.0 Web Pages into SharePoint 2007
User Control Approach
This approach converts each ASP.NET Page into an ASP.NET User Control (USCX) and then deploys a SharePoint Page Layout relating to each control and then a SharePoint Page in the Pages library.
| Pros | Cons |
|---|---|
| Full access to SharePoint Context | Added complexities of having Page Layouts, User Controls and Page Instances for one page |
| Can develop outside of SharePoint first (if not using SharePoint Context) |
- [public:Integrating ASP.NET Web Application pages into SharePoint using User Control and Page Layout approach]
ASP.NET Web Part Approach
If you were lucky enough to write your ASP.NET Web Application using ASP.NET Web Parts you can simply import these into SharePoint.
| Pros | Cons |
|---|---|
| Can be added to SharePoint Web Part Zones in Pages | No drag and drop design surface in Visual Studio |
| Leverage connected web part framework | |
| Reusing same architectural approach as existing app |
Comments (7)
Feb 17, 2009
Phi Lieu says:
Jeremy, For the application page approach, I think the cons "Requires deploymen...Jeremy,
For the application page approach, I think the cons "Requires deployment to individual IIS Web Applications" is not true. Application pages are visible (available) for all site collections / sites.
Phi
Sep 25, 2009
Anonymous says:
I'm curious why you left out site pages? You can use the default.master on a sit...I'm curious why you left out site pages? You can use the default.master on a site page.
Sep 25, 2009
Thomas Resing says:
Didn't notice I wasn't logged in. By the way, this is great stuff. I don't see a...Didn't notice I wasn't logged in. By the way, this is great stuff. I don't see anywhere else that is covering integrating asp.net this well and I wonder why not.
Sep 27, 2009
Jeremy Thake says:
yep, its pages like this that really do make @SPDevWiki awesome! please spread t...yep, its pages like this that really do make @SPDevWiki awesome! please spread the word at user groups etc. about this resource
Sep 27, 2009
Gilles Lauwers says:
Phil lieu is totally right, you don't need any extra deployments. The applicatio...Phil lieu is totally right, you don't need any extra deployments. The application pages are hosted in the _layouts folder will run under Sharepoint Context and so on the Sharepoint Web App.
Jan 06, 2010
Tim Dallmann says:
But isn't it true that with multiple web front end servers, you'll need to deplo...But isn't it true that with multiple web front end servers, you'll need to deploy to each one. With a solution/feature deployment, SP will manage the deployment to all the servers in the farm.
Jan 07, 2010
Jeremy Thake says:
Tim you are correct, a solution package will deploy to each SharePoint Root (Hiv...Tim you are correct, a solution package will deploy to each SharePoint Root (Hive) within the SharePoint Farm. The TEMPLATE\LAYOUTS\ directory will exist on each SharePoint role server in the farm and therefore will require that file.