The Problem: Let’s say we have an ASP .Net Web Application with many web forms, user controls, business layer, and data access layer. It works fine as a web application. What we are looking for integrating the files within this web application into the SharePoint site and totally get rid of the web application. This has couple of advantages:
Business users and end users need not go to a separate web application (URL). Users can see all those pages within SharePoint site.
Once the integration is done, we have the SharePoint site’s security and access rules i.e. Authentication and Authorization is in place without any additional work.
Simple development experience as compared to developing with web parts.
In a nutshell this option allows us to build an ASP.Net application outside of SharePoint, build it, test it & then add it to SharePoint. Now, the problem is what are the ways to deploy the ASP .Net application pages into SharePoint and which one is should we go with. After doing some research and work I found that there are many ways in which we can do this. Below is a brief discussion of the sam.
Solutions:
The SharePoint designer approach: This approach can be used if there are few aspx pages with little functionality.
Using web parts. This can be used in conjunction with SharePoint designer. But once again, developing many web parts is not feasible and also raises performance issues.
_Layouts folder approach: This is the simplest of all. Just deploy the web application pages under the _layouts folder of SharePoint and the pages can be accessed from any SharePoint site. Cons: The pages don’t inherit the security and access rules from SharePoint. The pages can be accessed from any site existing on that server farm. Master Page integration is not possible. MSDN Article explains with a sample.
User controls using Smart Part: In this approach, the developer can develop web parts using the third party Smart Part control. In this way the developer can have the drag – drop functionality as he/she can develop it as a user control and drop it in the smart part. This method is similar to web parts but the developer has the privilege of drag-drop functionality but it still carries the negatives mentioned for the web parts approach.
Using features and WSP package: Following some steps as recommended by Andrew Connell (MOSS MVP). Here is the blog. I believe this is the standard approach users are using in the SharePoint developer community.
Using VSeWSS (Visual Studio extensions for WSS): This is yet another and latest solution. Microsoft recently released the VSeWSS 1.1 RTM. Using this, we can deploy all the asp .net pages into SharePoint by setting up a new project in Visual Studio. VSeWSS creates a solution package using features. Setup the project and hit ‘Deploy’ and it is done.
Business users and end users need not go to a separate web application (URL). Users can see all those pages within SharePoint site.
Once the integration is done, we have the SharePoint site’s security and access rules i.e. Authentication and Authorization is in place without any additional work.
Simple development experience as compared to developing with web parts.
In a nutshell this option allows us to build an ASP.Net application outside of SharePoint, build it, test it & then add it to SharePoint. Now, the problem is what are the ways to deploy the ASP .Net application pages into SharePoint and which one is should we go with. After doing some research and work I found that there are many ways in which we can do this. Below is a brief discussion of the sam.
Solutions:
The SharePoint designer approach: This approach can be used if there are few aspx pages with little functionality.
Using web parts. This can be used in conjunction with SharePoint designer. But once again, developing many web parts is not feasible and also raises performance issues.
_Layouts folder approach: This is the simplest of all. Just deploy the web application pages under the _layouts folder of SharePoint and the pages can be accessed from any SharePoint site. Cons: The pages don’t inherit the security and access rules from SharePoint. The pages can be accessed from any site existing on that server farm. Master Page integration is not possible. MSDN Article explains with a sample.
User controls using Smart Part: In this approach, the developer can develop web parts using the third party Smart Part control. In this way the developer can have the drag – drop functionality as he/she can develop it as a user control and drop it in the smart part. This method is similar to web parts but the developer has the privilege of drag-drop functionality but it still carries the negatives mentioned for the web parts approach.
Using features and WSP package: Following some steps as recommended by Andrew Connell (MOSS MVP). Here is the blog. I believe this is the standard approach users are using in the SharePoint developer community.
Using VSeWSS (Visual Studio extensions for WSS): This is yet another and latest solution. Microsoft recently released the VSeWSS 1.1 RTM. Using this, we can deploy all the asp .net pages into SharePoint by setting up a new project in Visual Studio. VSeWSS creates a solution package using features. Setup the project and hit ‘Deploy’ and it is done.
