Difference between System.Web.UI.WebControls.WebParts.WebPart and Microsoft.SharePoint.WebPartPages.WebPart?

Microsoft.SharePoint.WebPartPages.WebPart is provided in MOSS 2007 to provide backwards compatability with MOSS 2003 webparts.

 In MOSS 2007, it is recommended to use System.Web.UI.WebControls.WebParts.WebPart instead.

System.Web.UI.WebControls.WebParts.WebPart does not provides a feature to get or provide to to other webparts.

Client Object Model vs Server Object Model in SharePoint 2010

Client Object Model 

Client object model is a new feature available in SharePoint 2010. .Client object model provides a  way to do the programming for a SharePoint site using scripting language such as Java Script .

In  Client object model an xml request will be sent  and then server will return JSON which is changed to appropriate object model. 

Mainly 2 assemblies to be referred while working with the Client object model.

Microsoft.SharePoint.Client.dll

Microsoft.SharePoint.Client.Runtime.dll

Below is the code sample for a list object from SharePoint site using Client object model :

ClientContext context = new ClientContext("http://sp2010:2012");

 List list = context.Web.Lists.GetByTitle("Title");

context.Load(list);

context.ExecuteQuery();

So, what else a developer can do with Client object model. Client object model provide a way where you can access SharePoint data with scripting language such as Java Script.

You can write simple java script code to perform all those operation. You can use CAML query to access data from SharePoint site.

Using Client object model you can do below tasks:

Get list items, Add list items, Update list items and many more.

Client object model gives result in fast manner, but there is a limitation. The limitation is, we can not access Farm Object using Client object model.

For Client object model silverlight is also an option to program for a SharePoint site.

So if you want to access Farm object then use Server object model.

Server Object Model :

Server object model contains following classes : SPFarm, SPServer, SPSite, SPSiteCollection etc.

Below is the code Sample for Server Object Model:

This code is to get the list items from a SharePoint site:

          using (SPSite oSite = new SPSite(@"http://sp2010:33051"))

            {

                using (SPWeb oWeb = oSite.RootWeb)

                {

                    SPList oList = oWeb.Lists["List1"];  

                    Console.WriteLine("Items in: " + oList);

                    foreach (SPListItem oItem in oList.Items)

                    {

                        string firstname = oItem["Fname"].ToString();

                        Console.WriteLine(firstname);

                    }

                 }

            }

If you want more on Client object model or Server object model then please comment your query. Your comment will be highly appreciated.

Deployment of Sharepoint sandbox solution wsp

Manually Deployment of Sharepoint sandbox solution wsp 

One of the most interesting new feature of SharePoint 2010 is something called Sandboxed Solutions.

Think of it this way. In 2007 we have solution packages, WSP files that are packaged up with all kinds of goodness (Master Pages, InfoPath Forms, Web Parts, Custom Actions, etc.). Whenever we want to deploy these, we need to hunt down our IT guy and hand him over the package to run on the server and deploy, using the farm account. Only then can we activate the feature on our site or site collection. And then there’s the hassle of retracting, redeploying, etc. for upgrades.

But the Question is how to deploy Sharepoint sandbox solution 

here is the two different approach for this :)

Approach 1: 

Go to Site Actions->Site Settings and under Galleries

Click on Solutions

Click on image to zoom

On next window click to upload solution

Click on image to zoom

Now upload your solution wsp

Click on image to zoom

 

After uploading on next window you can activate it

Click on image to zoom

Now your solution is activated. You can use it.

If you want to delete or deactivate it click on the solution deactivate option will appear after deactivate you can delete it.

Click on image to zoom

 

Manually Deployment of Sharepoint sandbox solution wsp 

Approach 2: 

SharePoint 2010 Management Shell (PowerShell is the most interactive approach in Sharepoint 2010) (for more about PowerShell read my another article Sharepoint Administration MGMT

 

Using PowerShell deploying sandbox solution

You can find Sharepoint 2010 Management Shell under Start-Microsoft Sharepoint 2010 Products

Click on image to zoom

On Management Shell window write command to add the solution to your site collection

Command :

Add-SPUserSolution –LiteralPath "C:\Deployment\MySharePointSolutionPackage.wsp" –Site http://webapplication/sitecollection

-LiteralPath : Path of Wsp file

-Site : Site collection url

Click on image to zoom

Hit enter it will add the solution to your site collection

You can see the added solution “testproject1” 

Site Actions->Site Settings and under Galleries-Solution

You can find your solution but it’s not activated

Click on image to zoom

To activate Solution 

On Management Shell window write command to Install the solution to your site collection

Command :

Install-SPUserSolution –Identity MySharePointSolutionPackage.wsp –Site http://webapplication/sitecollection

-identity : Name of the wsp file  

Hit enter it will show the status Activated

Click on image to zoom

 

Now you can see you webpart status is activated.

Click on image to zoom

--
Related Article : Creating a sandboxed solution

Creating a sandboxed solution

Creating a sandboxed solution

Sharepoint 2010 sandboxed solution are very useful for sharepoint development the main feature of sharepoint sandboxed solutions offer a way to build SharePoint Web Parts and deploy them to a site without needing administrative intervention---that is, yes you can deploy a Web Part to a SharePoint site. but you have should be a site collection administrator.

Here is the steps given for creating Sharepoint sandboxed solution

Open Visual Studio 2010 and start by creating a “Empty SharePoint Project”.

Click on image to zoom

In the next window enter your SharePoint Site URL and check if the option “Deploy as a sandboxed solution” is checked.

Click on image to zoom

Check the properties window sandbox solution is set as true 

Click on image to zoom

Now add new item to the solution

Click on image to zoom

Add a new Web Part item to the project

Click on image to zoom

Write your code in .cs file 

Click on image to zoom

 

Now you can create wsp file of your solution by simply clicking on package

Click on image to zoom

 

Or you can directly build and deploy sandbox solution to your site 

Click on image to zoom

 

The solution will now be available in the Solutions Gallery in your site (Site Actions->Site Settings and under Galleries)

Click on image to zoom

 

You can find all the user solutions there

Click on image to zoom

Now adding the webpart to your site collection:

Click the Edit icon at the top of the page to put the page in Edit mode:

Click on image to zoom

 

Click the Insert tab in the Ribbon

Click on image to zoom

 

Click the Web Part ribbon button to insert the web part.

Under Categories select Custom, and under Web Parts select your webpart. Click Add to add the web part to the page.

Click on image to zoom

 

Click the Save button to save the changes you made to the page.

Click on image to zoom

--

Capabilities and elements are available in sharepoint sandboxed solutions

The following capabilities and elements are available in sandboxed solutions:

• ·         List definitions
• ·         List instances
• ·         Onet.xml
• ·         WebTemplate Feature element instead of Webtemp.xml
• ·         Content Types/Fields
• ·         Navigation
• ·         Module/files
• ·         Feature callouts
• ·         Web Parts derived from WebPart
• ·         Event receivers

o   SPItemEventReceiver

o   SPListEventReceiver

o   SPWebEventReceiver

• ·         Custom Actions
• ·         Workflows

The following capabilities and elements are not available in sandboxed solutions:

• ·         Custom Action groups
• ·         HideCustomAction element
• ·         Content Type Binding
• ·         Web Application-scoped Features
• ·         Farm-scoped Features
• ·         Custom property Toolpart class
• ·         Programmatic workflow
• ·         Event receivers

o   SPLimitedWebPartManager

• ·         Timer jobs
• ·         Visual WebParts
• ·         Sharepoint mapped folders(e.g. “_layouts” and “images”)

Benefits of Sharepoint sandboxed solutions

Use and benefits of sandboxed solutions

There are two common scenarios where it is appropriate to use sandboxed solutions:

• When an organization wants to run code for employees on a production SharePoint Server site, and that code has not been rigorously reviewed and tested.
• When a hoster wants to let the owners of hosted SharePoint Server sites upload and run custom code.

The main benefits of using sandboxed solutions are as follows:

• Sandboxed solutions can be added to a production SharePoint Server environment without the risk of affecting processes outside the sandbox.
• Site collection administrators can deploy sandboxed solutions. This frees farm administrators from this task.
• Scalability and flexibility are increased because sandboxes run in a separate process that can be restricted by quotas, and their effect on the farm can be monitored.
• A solution does not have to be modified or recompiled if it is moved from a sandbox to running directly on the farm.

Comparison of sandboxed and farm solutions

Aspect	Farm	Sandbox
Deployment process	Add the solution, and then deploy it to the farm.	Upload the solution to a site collection, and then activate it in the site collection.
Who can deploy	Farm administrator.	If the solution contains an assembly, only a site collection administrator can deploy it. If the solution does not contain an assembly, a user who has the Full Control permission level at the root of the site collection can deploy it.
Data access	Unrestricted.	The solution can only access content from the site collection in which it was deployed.
Process the solution runs in	Unrestricted IIS worker process or whichever process the solution is deployed into.	Separate worker process that has restricted permissions.
Code access security	The solution developer can set the code access security policy when packaging the solution.	Restricted.
Monitoring	Not monitored.	Monitored, and limited by quotas set by the farm administrator.
Load balancing	Varies, based on the kind of solution.	Configurable separately from non-sandboxed solutions.
Solution functionality	Unrestricted.	Restricted, as described in What sandboxed solutions cannot do, earlier in this article.