With this option you build all your UI using the Web Part framework. Logic etc... can be off in other .Net assemblies or a web service etc... just as you would with any other .Net Application.
Pros:
Built using ASP.Net Web Part framework
Deployed via Web Part install package or the new Feature/Solution Deployment mechanism
SharePoint application provides hosting framework for "putting" these Web Parts on Web Part pages
Communications framework for talking with other Web Parts
Designed to be highly re-usable across many sites with little effort
Cons:
No drag and drop UI for laying out your UI i.e. no design time surface
A framework that developers must learn to work within
Summary: A good use of web parts would be where you want to build a widget/mini-application that you can put on many web part pages across many sites.
Option 2: _layouts application
An _layouts application is when you develop an ASP.Net Web Application and deploy it to the c:\program files\common files\microsoft shared\web server extensions\12\template\layouts (what a mouthful!) directory. This is a special directory that gets "virtualized" in each sharepoint site i.e. in each sharepoint site you will have an /_layouts path from the root of the web. E.g. http://servername/sites/sitename/_layouts.
This means you can make your application available under each SharePoint site e.g. http://servername/sites/sitename/_layouts/MyApp/SomePage.aspx
In fact this is how all the SharePoint administration pages are delivered in each site.
Pros:
Great way to make your functionality available in every site
Easy to develop. It is just like developing a regular ASP.Net web site
Context sensitive access to the SharePoint object model. Great for doing work on the site that the user happens to be working in at the time.
Cons:
Deployment not managed via Solution deployment mechanism
Cant use the ASP.Net master page of the site context as the _layouts application is a separate ASP.Net application
Summary: It is best to use an _layouts based application when you want to extend every site with some functionality such as additional administration pages.
Option 3: User Controls and the Son of SmartPart
The last option is to build your applications UI in ASP.Net User Controls as you would with any other ASP.Net Web Application and then use the Son of SmartPart to deliver those User Controls via a web part.
The Son of SmartPart is a Web Part that is able to "host" an ASP.Net 2.0 User Control :) For more info on this see: http://www.smartpart.info/default.aspx(if you are wondering who its father is ... that is the SmartPart funnily enough ... and is a Web Part for hosting ASP.Net 1.1 User Controls)
Pros:
Simple development experience.
You get a design surface to build you UI
Deployment reasonably straight forward
Can use Web Part connection framework if desired
Might be possible to develop these outside of SharePoint first (depending on if they have dependencies to SharePoint).
Cons:
Deployment not managed via Solution deployment mechanism Out of the Box (you could build a solution to deploy the Son of Smart Part)
Slightly different deployment of User Control files and assemblies (but nothing a .bat file can't fix) during development.
Summary: I think this is a great option when you want to build a rich browser based UI that you only want to use in one (or a couple) of sites. I don't think this is a good option if you want to build a mini-application that you want to include on many sites. A better option in that case might be a Web Part.
Option 4: ASPX pages added to SharePoint Site
This option actually was suggested in the comments by a reader. I thought it was so good i tried it out ... and it works great! So here it is.
This option allows you to add your ASP.Net application pages into your SharePoint Site. It also provides for compiling all using the code behind your pages into a DLL.
In a nutshell this option allows you to build your ASP.Net application outside of SharePoint, build it, test it & then add it to SharePoint. Its great!
Here is how to do it:
1. Install the Visual Studio 2005 Web Application Projects extension. This gives you the 'old style' web projects in Visual Studio ... so you can compile down to a single DLL etc...
2. START - File - New Project - ASP.NET Web Application - Name it "ItDoesWork"
3. Add reference to Microsoft.Sharepoint
Leave only Microsoft.SharePoint, System, and System.Web
4. In the Solution Explorer create folder "~masterurl" and add masterpage "default.master" inside
5. Replace code behind for the masterpage with:
using System;using Microsoft.SharePoint;namespace ItDoesWork._masterurl{
public partial class _default : System.Web.UI.MasterPage{
protected void Page_Load(object sender, EventArgs e){}
}
}
6. In the designer, rename ContentPlaceHolder's ID to "PlaceHolderMain"
7. Delete Default.aspx, and add new page - SamplePage.aspx
8. Replace source content with the following:
<%@ Page Language="C#" MasterPageFile="~masterurl/default.master" CodeBehind="SamplePage.aspx.cs" Inherits="ItDoesWork.SamplePage" Title="Untitled Page" meta:webpartpageexpansion="full" meta:progid="SharePoint.WebPartPage.Document" %>
Testing Page...
9. Replace code behind for the page with:
using System;using Microsoft.SharePoint;
namespace ItDoesWork{
public partial class SamplePage : System.Web.UI.Page{
protected void Page_Load(object sender, EventArgs e){
Label1.Text = SPContext.Current.Site.Url;
}
}
}
10. Project properties - Build - Output path:
Point it to \BIN folder of our SharePoint Web application. E.g.
C:\Inetpub\wwwroot\wss\VirtualDirectories\moss.litwareinc.com80\bin
You can also manually copy your projects DLL into the \BIN folder each time.
11. Compile your project.
12. Open the web.config file for the SharePoint Web Applicaiton E.g.
C:\Inetpub\wwwroot\wss\VirtualDirectories\moss.litwareinc.com80\web.config
13. Add the following line to the SafeControls section (change to suit your assembly and namespace etc...)
14. Change the
15. Open your site in SharePoint Designer and drag and drop your SamplePage.aspx page into a folder in your site.
16. Browse to your page E.g.
http://moss.litwareinc.com/TestApp/TestPages.aspx
17. Jackpot! (Hopefully) You should now have your aspx page running in SharePoint.
One of the great things about this option is that you could build your applicaiton outside of SharePoint with any old MasterPage, then deploy to SharePoint and swap out the masterpage string for the correct one. Thus being able to develop and debug outside of SharePoint and then deploy and test inside SharePoint.
I can see this option being a favorite for most ASP.Net developers who are used to the integrated/seemless code, build & debug experience.
A note on debugging: If you want to debug your code once it is running inside SharePoint then all you need to do is attach the Visual Studio debugger to the correct w3wp.exe process (Debug -> Attach to process), set your break points and then hit your page in a browser.
Pros:
Simple development experience. Develop outside SharePoint first if desired.
You get a design surface to build you UI
Deployment reasonably straight forward
Cons:
Deployment not managed via Solution deployment mechanism Out of the Box. ( but this might be possible i have not tried it yet)
Slightly different deployment of User Control files and assemblies (but nothing a .bat file can't fix) during development.
I really like this option ... coming from an ASP.Net point of view i feel it is a simple option.
正在測試Option 4，會將結果再報告出來。
參考資料
http://blogs.msdn.com/cjohnson/archive/2006/09/05/740498.aspx
