Desarrollo de para aplicaciones para MOSS
Chris Johnson, ha creado un excelente post sobre las distintas formas de incluir aplicaciones desarrolladas en ASP.NET dentro de MOSS, pueden leerlo en la siguiente dirección http://blogs.msdn.com/cjohnson/archive/2006/09/05/740498.aspx
I have been fortunate enough to have been involved deeply with one of our early Office TAP customer's projects. TAP customers are given access to early builds and betas, along with support from Microsoft, to build a project on. The idea here is that they will be in a position to deploy early on the latest technology and at the same time have a positive impact on Microsoft delivering a quality product to market. TAP customers are key to us taking feedback as we build the product.
In the particular project I am involved with we are building quite an elaborate solution that is built using many of the new features in the 2007 Microsoft Office System. This ranges from the InfoPath embedded in a Win Forms control and on to Microsoft Office SharePoint Server 2007.
Here is a brief list of some of the things we are doing:
- Building a .Net Win Forms application and embedding InfoPath to do rich offline forms capture in a custom application
- Custom Visual Studio based Workflows build on Windows Workflow foundation
- Custom Site Definitions, List Definitions, Timer Jobs deployed as Features via the Solution deployment framework
- ...
But what I really wanted to concentrate on in this post was talking about what options we considered for building some custom UI that is delivered inside MOSS and the pros and cons of each.
The options we looked at were:
- Custom built Web Parts
- A "_layouts" application (see below for what this is)
- App built using User Controls & Son of SmartPart
The particular component of the application that I want to look at is the UI presentation "engine" i.e. what mechanisms deliver the UI.
Option 1: Custom built Web Parts
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 -- ADDED 15-March-2007 UPDATED 16-November 2007
(Thanks to Michal Gwozdek for emailing me an updated set of steps that work for him)
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" %>
<asp:Content ID="Content5" ContentPlaceHolderID="PlaceHolderMain" runat="server">
Testing Page...
<asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>
</asp:Content>
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...)
<SafeControl Assembly="ItDoesWork" Namespace="ItDoesWork" TypeName="*" />
14. Change the <trust level="WSS_Minimal" originUrl="" /> line to <trust level="WSS_Medium" originUrl="" />
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.
In the project that I mentioned at the beginning of the post the following was true:
- We wanted to surface application UI in one place in SharePoint
- There was only ever going to be one instance of the application i.e. surfaced via one SharePoint site
- Lots of different screens in the UI
Can you guess what option we decided on?
Well, it basically boiled down to either building the UI in Web Parts or using the Smart Part method.
In the end it was built using User Controls and the Smart Part because the developers would be more productive building User Controls (they didn't have any prior SharePoint development experience) and we didn't need to re-use any of the application in multiple sites.
So in the end we ended up with a document library to house Web Part pages for each of the UI "Screens". In each of the web part pages we are using the Son of Smart Part to deliver our User Control that delivers that portion of the application.
I am really keen to hear what other options people are using to develop their applications that are delivered inside SharePoint. Feel free to leave comments ...
-Chris.
Updated: Changed title to include WSS v3 as Patrick rightly points out this is equally as applicable in WSS v3 also.
Posted: Tuesday, September 05, 2006 5:08 PM by chjohn
Comments