SharePoint 2010 Farm solutions and Sandbox solutions

Hi all,

Recently I found article about building sandbox solutions. I have jotted down few points in this blog post.

	Farm Solution	Sandbox Solution
Deploying solution	Farm solution is typically added by farm administrators via Central Administration >> System Settings >> Farm Management >>   Manage Farm Solutions in a Web Solution Package (.wsp).	Sandbox solution is added by site owners or site collection administrators & uploaded to the “Solution Gallery” for a specific site collection again in .wsp format. Farm administrators though view via Central Administration >> System Settings >> Farm Management >>   Manage User solutions.
Object Model	Farm solution has full access to the SharePoint object model.	Sandbox solution has restricted SharePoint object model.
	Farm solutions have complete of SharePoint object model that includes >>developing programmatically workflows, >> custom web parts, >> Programmatically develop site definitions, >> Full access to content database, >> Custom application pages & master pages with delegate controls etc.	Sandbox has quite a few restrictions such as following functionality is PROHIBITED: >> Control (Delegate Controls) >> Access to read/write on the FILE SYTEM >> Programmatically developing  workflows, SharePoint.WebControls >> Programmatically developing applications pages >>Write to disk >> No Code behind >> No custom web services >> Talking to other farms Check out restrictions on code on MSDN
Debugging	Farm solution has complete control over the content such as features, workflows, site definition at the farm level. For debugging purposes developers user w3wp.exe or owstimer.exe.	Sandbox solution has a separate worker process called SPUCWorkerProcess.exe for debugging purposes.
Governance	Farm solution is not governed any security. However, developer could develop their own security model. Furthermore, farm administrators have visibility of solution health & resources needs in the context of sandbox solutions	Sandbox solution is governed by using a point system & if developers’ code exceed the specified point per day the solution would be blocked. Default point for sandbox solution is 300 points & it’s configurable by farm administrators.
Monitoring	Farms solutions are not monitored.	Site collection administrators are responsible for monitoring the sandbox solutions which are based on restrictions by the company’s governance & farm administrator.

However, its possible to building useful sandbox solutions such as:

• Useful when working on the SharePoint 2010 Client object model (Micorsoft.SharePoint.Client) using JavaScript & Silverlight
• WebParts 
• InfoPath  

     Visual Studio 2010 SharePoint Power Tools facilitates developers to build Sandbox compatible & Sandbox compilation.

Cheers,
--aaroh

References: Farm solution VS Sandbox solution

Examining the differences between "Site Defintion" and "Site Template"

Hi all,

The concepts of "Site Definitions" and "Site Templates" are slightly confusing. I have jotted down the basic differences between the two. 

The concept is quite similar to the "Application pages" and "Site Pages" whereas 

 i) Application pages: are on the file system, complex to develop, only developers can create etc. 

ii) Site pages: are on the database, simple to develop, end users can do using Web UI etc. 

For more information on the "Application pages" and "Site Pages", please refer to my blog.  

Site Definitions	Site Templates
1) Requires administration access to the server	Installable  from the Web UI by site owners
2) Supports feature stapling	Additional features must be activated in gallery
3) Files on the file system	Files on the database.
4) Can provision multiple webs	Single web only
5) Relatively complex	Relatively simple

Cheers, 

--Aroh

Examining the differences between "Application Pages" and "Site Pages"

Hi all,

There are lot of differences between "Application Pages" and "Site Pages". To really understand these concepts, we have to examine the WSS 3.0 integration with ASP.NET. So, let's get started.

-----------------------------------------------------------------------------

Q. What are the WSS 3.0 design goals and why we needed WSS in the first place?

A. When WSS 3.0 was not the market, ASP.NET developers had to contentiously create web-sites and they have to be monitored, updated and deleted. Apparently, it takes weeks (if not months) to develop full-fledged sites.

WSS 3.0 has a high-level design goals and are on top of the ASP.NET framework. The basic design goals are:

a) Requires sites to be created contentiously created, updated and deleted.

b) Site provisioning engine:

The act of the provisioning (a fancy word for creating) that allow site administrators to quickly create pages, lists, document libraries etc.

The bigger picture of WSS architecture are

i) Manageability

ii) Scalability

--------------------------------------------------------------

Site pages:

Concept of SPVirtualPathProvider and Page Ghosting: 

>> Strength of WSS over ASP.NET

Its the ability to provision and customize pages within a site WITHOUT to make changes to the local file system.

>> How its done??

Its possible to store customized version of .ASPX and .MASTER files inside the "content database" (SQL Server) and retrieving them on demand when they are needed to process on incoming page requests.

For e.g.

i) We modify the "default.aspx" page using SharePoint designer and save it.

ii) Behind the scenes, WSS will save to this page into "content database" (not in the file-system).

iii)WSS team created a virtual path "SPVirtualPathProvider" that is integrated with every web application.

Its able to retrieve an ASP.NET page from the content database along with ASP.NET run time for parsing.

Typically, web-sites and pages are stored on the disk. Contrary to SharePoint which capitalizes the concept of  "SPVirtualPathProvider"and stores in the content database. Therefore, "Site Pages" get the information from the content database and allows the Site scale out thousands of pages. 

The basic reason:

Site pages are generally templates with only a fairly small amount of different data each. This data is stored in the database, to be used in specifically located "place-holders" on the user pages.Moreover, if we have thousands of pages using database technologies, is generally much faster to extract the required changes via stored procedures, rather than disk-i/o.

Page ghosting: 

Definition (Ted Pattison):

"Page ghosting describes the act of processing a request for an uncustomized "page instance" by using a "page template" loaded into memory from the file system of the front-end Web server."

In short, a page is considered ghosted its NOT customized. 

There are couple of benefits of page ghosting:

i)  It eliminates the need to transfer the contents of a page definition file from the SQL Server computer with the content database to the front-end Web server computer.

ii) Ghosting does not mean that it has the same data as the next page, but it does have the same layout, to use the same un-customized template.

Therefore it makes is possible to process the home-pages for hundreds different sites by using a single page template.

iii) Its an optimization technique and supports page customization. 

Recap:
>> Site pages are that support user customization.

>> Examples of "Site Pages" are associated with lists and document libraries  default.aspx (home page), NewForm.aspx, EditForm.aspx, DispForm.aspx etc.

>> Users can customize and there is NO need to developer.

>> Customized versions (from users) stored in content database and NOT in file-system. The saving and retrieving of content from the database is provided using "SPVirutalPathProvider" class.

>> "Site pages" could exist either in customized(unghosted) or uncustomized(ghosted) state and they are stored in content database.



GHOSTED (uncustomized):
An un-customized Site Page that can be stored as a template and combined with data from the content database is called ghosted. (template + data)

UN-GHOSTED (customized):
Whole page must be stored in the database, it is called un-ghosted.(Whole page)

>> Site Pages DO NOT support in-line code .i.e. . This security feature prevents a user from injecting code into page which may maliciously, or unintentionally, bring down a server, snoop data, etc. 

>> Provides scalability but impact performance and Security as compared to application pages.   However when page is customized, SPVirtualPathProvider retrieves the customized version of the page from the content database and passes it to ASP.NET parser. Now these pages aren’t compiled into assembly. They are processed by ASP.NET parser in no-compile mode.

Application Pages: 

 Developing application pages for SharePoint can be challenging. pplication pages are .aspx pages that reside in the _layouts folder on each web front-end server, and can be accessed from any site within SharePoint by using the /_layouts virtual folder (for example http://Server/SiteCollection/Site/_layouts/MyPage.aspx). The pages are usually used for administration pages to this end, and in some cases this is the only option.

More details about Application pages:

>> "Application pages" DO NOT support user customization.


>> Application pages generally use a master page to enforce a consistent look and feel, but in this case they will mostly use the ~/_layouts/application.master page.

>> They have to developed by a SharePoint developer.


>> They are file based and stores on "layouts" under 12 hive.

 >> By default, compiled into individual DLLs and loaded into memory. In all, it is a fact that they are more powerful and run faster than Site pages.Thereby give better performance and security.

This post gives a detailed comparison between "Site Pages" and "Application Pages".
Developing an application page is not super easy and in next post, I will walk though to develop an application page.

Cheers
--Aroh