ASP to MOSS

Prachi.taunk
Posted by in SharePoint category on for Intermediate level | Views : 9010 red flag
Rating: 5 out of 5  
 1 vote(s)

We already have a number of ASP .Net Web Applications consisting web forms, user controls, business layer, and data access layer, Many times a need arises to add this web application to a SharePoint site.
This article discusses different ways of integrating aspx pages of a web application to a SharePoint site.
Introduction

 We already have a number of ASP .Net Web Applications consisting web forms, user controls, business layer, and data access layer, Many times a need arises to add this web application to a SharePoint site.

This article discusses different/various ways of integrating aspx pages of a web application to a SharePoint site.

The main advantages of this approach are:

  1. Business users and end users need not go to a separate web application URL(All those pages can be seen within the SharePoint site itself.
  2. Once the integration is done, the SharePoint site’s security and access rules i.e. Authentication and Authorization (is) are in place without any additional work.
Solutions

 

1.   Custom built Web Parts

       A good use of web parts would be where you want to build a widget/mini-application that could be put on many/different web part pages across sites.

            With this option you need to build your UI using the Web Part framework, where your logic can be within other .Net assemblies or in a web service, just like in 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/to other Web Parts
  • Designed to be highly re-usable across many sites with minimal effort

Cons:

  • No drag and drop UI functionality for laying out your UI i.e. no design time surface
  • A framework that developers must learn to work within.
  • Developing many web parts is not feasible and also raises performance issues.


   2.   User Controls and the SmartPart

In this method the developer can develop/create a user control and drop it in the smart part. This method is similar to creating web parts but here the developer has the privilege of drag-drop functionality This approach has the limitations of custom built web parts

The application UI can be built using ASP.Net user controls or by converting the aspx and aspx.cs pages to user controls, and then use SmartPart to deliver these User Controls via a web part

      To get a detailed description on how to convert Web Forms Pages into ASP.NET User Controls click   here .

The Son of SmartPart is a Web Part that is able to "host" an ASP.Net 2.0 User Control.

Pros:

  • Simple development experience.
  • You get a design surface to build you UI
  • Deployment is reasonably straight forward
  • Can use Web Part connection framework if desired

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 (a .bat file can be used for easy deployment) during development.

 

  3.   _Layouts folder approach:

 

Using _layouts based application is the best approach when you want to extend every site with some functionality such as additional administrative pages.


A _layouts application is when you develop an ASP.Net Web Application and deploy it to the location c:\program files\common files\Microsoft shared\web server extensions\12\template\layout. This is a special directory that gets "virtualized" in each SharePoint site i.e. in each SharePoint site you will have a /_layouts path from the root of the web.

E.g.  http://servername/sites/sitename/_layouts.

This means that 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
  • 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:

  • Master Page integration is possible, but you need to make changes to each aspx page.
  • Deployment not managed via Solution deployment mechanism
  • The pages can be accessed from any site existing on that server farm.
  • The pages don’t inherit the security and access rules from SharePoint

 4.   ASPX pages added to SharePoint Site

This option allows you to add your ASP.Net application pages into your SharePoint Site.  It also provides for compiling all the code behind of 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. 

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

2. START -> File -> New Project -> ASP.NET Web Application - Name it "ASPtoSP"

3. Add reference to Microsoft. SharePoint

4. In the Solution Explorer create a folder "~masterurl" and add master page "default.Master" inside it

5. Replace code behind for the master page with:

using System;

using Microsoft.SharePoint;

namespace ASPtoSP._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

After adding all your files right click on the project in solution explorer and choose convert to web application project. This will create partial class for all your aspx pages i.e. designer.cs.

8. Replace source content with the following:

<%@ Page Language="C#" MasterPageFile="~masterurl/default.master" CodeBehind="SamplePage.aspx" Inherits="ASPtoSP.SamplePage" Title="Untitled Page" %>

<asp:Content ID="Content5" ContentPlaceHolderID="PlaceHolderMain" runat="server">

Testing Page...

<asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>

</asp:Content>

NOTE: we have to change the Inherits attribute to add the assembly name. For example, if the namespace is 'SampleSiteNamespace' and the assembly name that the page uses for code-behind is SampleWebSiteAssembly, then we set Inherits="SampleSiteNamespace.SampleWebSiteAssembly", and this assembly must be in the bin of the SharePoint site

Give the namespace as ASPtoSP to both aspx.cs and designer.cs file.

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

<SafeControl Assembly="ASPtoSP" Namespace="ASPtoSP" TypeName="*" />

14. Change the

<trust level="WSS_Minimal" originUrl="" /> line to <trust level="WSS_Medium" originUrl="" />

Add the following line under the <PageParserPath> section:

<PageParserPath VirtualPath="/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" />

 

Change MaxControls value from 200 to 800

For viewing the errors set

       debug=”on”

       callStack=”true”

       customErrors mode=”off”

15. Open your site in SharePoint Designer and drag and drop your SamplePage.aspx page into a folder in your site.

Or you can also deploy these pages to one of the SharePoint web application as a feature.

For this you need to write one feature.xml and module.xml and install using stsadm utility.

16. Browse to your page E.g.

http://moss.litwareinc.com/TestApp/TestPages.aspx

17. You should now have your aspx page running in SharePoint.

One great thing 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. 

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, can be deployed as a feature packaged in a solution package.

Cons:

  • Slightly different deployment of User Control files and assemblies ( a .bat file can be used for easy deployment) during development.

 5.     Using Page Viewer Web part:

We can use Page viewer Web part available out of box with SharePoint.

In this approach, the asp.net application runs independent of SharePoint, so we can’t/cannot get current logged in user for SharePoint.

 

The only way to get currently logged in user is to capture this user in web part and pass it as query string to asp.net page, and parse this query string in aspx pages.

 

The out of box Web part does not allow us to pass logged in user in query string, for this you need to create a wrapper for page viewer web part. The details can be found at following link.

 

http://weblogs.asp.net/mnissen/articles/147457.aspx

 

Pros:   

·         Easier development.

·         Web part can be deployed as a solution package.

·         No need to make any change in existing ASP.NET application.

 

             Cons:

·         The pages don’t inherit the security and access rules from SharePoint.

·         Asp.Net application runs independent of SharePoint, needs to be hosted on a web server.

Conclusion

The best approach to be used depends upon your requirements. In our experience the best way is to add aspx pages to sharepoint uasing asp.net web application. In this way it can be easily deployed and removed as and when required.

Page copy protected against web site content infringement by Copyscape

About the Author

Prachi.taunk
Full Name: Prachi Taunk
Member Level: Starter
Member Status: Member
Member Since: 6/8/2009 5:59:54 AM
Country:


Prachi is Microsoft Certified Technology Specialist (MCTS) for Microsoft Office SharePoint Server 2007 application development and Certified Sun Java Programmer (5.0). She started working on SharePoint from July 2007 and has 1 year 10 months of experience in working with SharePoint products (MOSS 2007 and WSS 3.0). Her experience includes: • Administration and development in Windows SharePoint Services 3.0 (WSS 3.0) and Microsoft Office SharePoint Server 2007 (MOSS 2007). • InfoPath 2007. • Workflows using SharePoint Designer. • Web part development using C#.Net. • XML, Web services. • Microsoft Virtual servers. • Conducted training on WSS 3.0 and MOSS 2007 for Banking and Financial Services SBU. • Portlet development in IBM Web Sphere portal. • Skelta BPM.Net 2009 (Business Process Management tool) and SharePoint accelerator 2007

Login to vote for this post.

Comments or Responses

Login to post response

Comment using Facebook(Author doesn't get notification)