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
Technorati Tags:
moSS,
wsS
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
Cuando se desarrolla para SharePoint es necesario tener instalador WSS 3.0 junto con Visual Studio para que el código compile, normalmente se utilizaba un Servidor para el desarrollo sin embargo ahora el Bamboo Team ha publicado la forma de instalarlo en Windows Vista sin necesidad de tener un servidor, más información en
http://community.bamboosolutions.com/blogs/bambooteamblog/archive/2008/05/21/how-to-install-windows-sharepoint-services-3-0-sp1-on-vista-x64-x86.aspx
Bamboo Solutions is the leading provider of Web Parts and Solution Accelerators for Microsoft SharePoint. The mission of this blog is to connect us with customers and colleagues and foster discussion around the news and issues that affect us all.
How to install Windows SharePoint Services 3.0 SP1 on Vista x64/x86 
If you are a developer for SharePoint your best friend has been Virtual PC or VMWare. It’s time to introduce a new friend, Bamboo Nation's SharePointOnVista J
We have put together an installer that allows you to install WSS3.0 SP1 on Vista, both x86 and x64. This will allow you to develop on your workstation with all the power of a non virtualized environment. You still need VPC and VMWare so don’t feel sorry.
There’s been much discussion about SharePoint being a "bad" development platform. This will remove the objection that you NEED to develop on a Server OS. I think we all as SharePoint developers have built our “virtualization skills” to a comfortable level now so it’s time to give us a break ;)
So please download the setup helper and try it out. I really want to hear from you about problems you encountered so we can fix them. Please leave your comments here or we can discuss in this forum. It would be nice to hear about successful installations too J
UPDATE: If you run Windows Vista Home Premium IIS only supports Basic Authentication. Therefore you MUST manually enable Basic Authentication in the IIS management console.
Current limitations:
-
You must select the Advanced option during install.
-
If you want to run on SQLExpress, manually install it first. Get it here.
-
You have to manually enable IIS7 with the proper options (explained).
-
Your workstation has to be part of a domain. UPDATE: This is not required.
Here’s how you install it.
First download the installation helper and the correct version of WSS with SP1.
Windows SharePoint Services 3.0 with Service Pack 1
Windows SharePoint Services 3.0 x64 with Service Pack 1
Go here to download our Setup Helper file
Now run the setup helper (WssVista.msi)
You will see an UAC prompt select Continue to proceed with the installation.
Once the install has completed you will find the SetupLauncher.exe in the install location you selected. If you didn’t change the default option you will see it under the directory ..\Program Files\WssOnVista\Setup
Configuring IIS7
Before we go any further we need to make sure IIS7 is installed with all required options .
Go to Control Panel and click Programs.
Under Program and Features click Turn Windows features on or off.
Under Windows Features select Web Management Tools and World Wide Web Services. Enable at least the following options and choose OK.
Wait until Windows has configured all options.
Installing Windows SharePoint Services 3.0 SP1 on Vista.
After completing the above steps it’s time for the interesting part. Locate SetupLauncher.exe and start it. You will once again see an UAC prompt, select Continue.
After the SetupLauncher run, select the WSS installation file Sharepoint.exe, or the MOSS installation file, and click OK. First, the package will be extracted.
After the files have been extracted the WSS setup program will be started.
The current version only supports the advanced installation option so select that one.
Select Web Front End when asked about Server Type. The database will be created later.
Sit back and relax while SharePoint is being installed, you are running Vista remember ;)
Hopefully you will see the following screen at the end of the installation. If you would get an error during the installation step try to run a Repair.
Leave the checkbox checked and click Close to run the Configuration Wizard.
At the second screen select the option to create a new server farm.
Specify your database server (e.g. MYLAPTOP\SQLEXPRESS) and account information.
Let the Configuration Wizard do it's work.
And you should end up with this screen, congratulations!
The final result is WSS running on Vista, Enjoy!
/Jonas
Note: Remember that this is a "beta" product tool from Bamboo. Do not use it for any production work, as well as the usual "backup your system before install this program". Obviously, running WSS v3 or MOSS on Vista is not a supported environment by MS. Additional discussion about this tool can be found in this forum.
UPDATE: If you run Vista Home Premium you have to enable Basic Authentication in IIS, if you don't you will only see a blank page.
Here's how to do it:
Open up IIS management console and Enable Basic Authentication. You have to do this for ALL Web Applications you are creating.
Only published comments... May 21 2008, 03:02 PM by Jonas Nilsson
Technorati Tags:
SharePoint,
MOSS,
WSS