Powershell in sharepoint 2010

In 2007 we had stsadm to perform administrative task , though in 2010 they have official deprecated and removed support for several commands in stsadm it can be used in several occasions .However stsadm has been now replaced with Powershell , that i'm sure we will be using more in the coming days.

Powershell scripts are more faster , unlike stsadm they help us in accessing file system and registry . Handling powershell scripts are relatively easier , yet another advantage of using powershell is unlike stsadm you need not restart services after your wsp deployments. Though i'm a great fan of stsadm i like using powershell because of my above observations.

Some of the commands i have executed with powershell :

1.Install Solution
Add-SPSolution C:\krishna\MySolution.wsp

2.Deploy Solution
Install-SPSolution –Identity MySolution.wsp –WebApplication http://mysites
-GACDeployment||–CASPolicies

We can use -AllWebApplications , if not to limit our deployment to a single application.

3. Retract Solution
Uninstall-SPSolution –Identity MySolution.wsp –WebApplication http://mysites

4.Remove Solution
Remove-SPSolution –Identity MySolution.wsp

Use -SPUserSolution to perform any of the above said activities on the sandbox solutions for the respective site collections.

5.Activate Feature
Enable-SPFeature –Identity FeatureName–url http://mysites

6.Deactivate Feature
Disable-SPFeature –Identity FeatureName–url http://mysites

Differences between Sharepoint 2007 and Sharepoint 2010

The differences between the 2 versions is purely based on my observations .

Sharepoint 2007	Sharepoint 2010
Uses 12 Hive as the repository for the sharepoint resources .	Uses 14 Hive as the repository for the sharepoint resources
Deployment is comparatively cumbersome.	Deployment is easier , as it is done with VS 2010.
Has only Global solution store, like farm level solutions.	Has sandbox and farm level solutions ,that makes 2010 more scalable.
Shared service providers[SSP] provides wide features of MOSS 2007.	SSP is replaced by Service application, thus making the environment more scalable.
Doesn’t have site/web creation events.	Incorporated with site/web creation feature
Look and feel - Tabs,Menus	Look and feel - Ribbons , like Office 2010.
Backup/restore wasn’t granular. However it could have been done extending APIs.	Backup/restore is more granular , that can be achieved out of the box itself.
BDC wasn’t editable.	BDC is renamed to BCS with 2 way data binding.

Client Object Model

Overview :
One of the most promising feature of Sharepoint 2010 is Client object model . Though it still supports object model on server side , client side will play an important role in sharepoint development in coming days .

In 2007 we would either go for server object model to execute code within server where sharepoint is hosted or web services from remote desktops to get rid of a license . However there has been performance issue consuming web services . Hence microsoft came up with a new concept called "Client Object model" where we can consume sharepoint object within remote servers .

Why to use Client Object model ?
Fewer web service calls improves performance.
It can be called from ,NET Code, javascript(ECMAScript) or silverlight.
Reduces network congestion, as there is fewer round trips b/w client and servers.
Gets rid of licensing issues.

How it works :
When we call API's from the client side / silverlight applications, these API's are bundled in to XML by the object model and sent as a request to server for processing . The server after processing sends backs the response[result] as a JSON object , the object model picks up this and converts it to .NET object exposing it to the user. It can be seen that there is a fewer round trips as the entire operation is bundled and executed at once.

Namespaces :
Microsoft.SharePoint.Client and Microsoft.SharePoint.Client.Runtime are two prominent namespaces used for consuming object model on the client side using C#.

How to use :
All objects now in client model doesn't begin with SP , i.e : it is Web for SPWeb, List for SPList .The SP concept has been removed in this model. However there are couple of methods that has to be used .
The object whose properties will be accessed in the code has to be first loaded and executed so that they will be ready to access , we will be getting NotInitializedException otherwise.

Load(object whose value properties will be accessed)
ExecuteQuery()

Implmentation ?
using sp = Microsoft.SharePoint.Client;
using (sp.ClientContext objContext = new sp.ClientContext("url"))
{
sp.Web web = objContext.Web;
//Load and execute List to access its properties
objContext.Load(web.Lists);
objContext.ExecuteQuery();
foreach (sp.List oList in web.Lists)
{
//do something to access OList properties
}

Hope you will be now able to build the application on you own .

Sandbox solution and farm level solution

Sharepoint 2010 has introduced a new concept called sandbox . Solutions can be built on this format so that they reside at site collection level independent of sharepoint farm.
On the other side you can also build soutions at farm level , as it used to be in 2007. Lets now see the differences in these approaches .

Sandbox :It is a place where we can deploy our solution i .e : Site Collection.Solutions in sandbox will have partial trust level with restrictions for accessing resources on servers, database,calling unmanaged code.It can be monitored,managed by site collection administrator.Since it is indepenedent of farm, the solutions will not have any impact at the farm level.

Farm level :Solutions are deployed at the farm level.Solutions execute with full trust. Unlike sandbox these solutions doesn't have any resrictions.Farm level admin can manage these solutions .

Upgrading workflow in sharepoint

I had a problem with upgrading a workflow in sharepoint having the old workflow instances working on the existing items and the new instance applicable only to the items added hence. I also had to make few changes to the infopath form to have the new form functional.

Challenge :
The challenge here was to make the new changes working [ new infopath form and new workflow assembly] having the old workflow assembly and items still working. Installing new workflow assembly would overwrite the existing one . Hence wasn't a feasible solution.

Resolution :
1. Deploy the new form[infopath] as a content type.
2.Upgrade the logic/code in workflow as needed ,create a new version of this workflow & deploy the assembly to GAC.
3.Set the exisiting workflow to "No new instances" .
4. Attach the modified workflow to the content type [ new infopath form deployed in step 1].

In Detail :
1. Deploy the infopath form as a content type
Deploying the browser form as a content type helps us to reuse forms across site collection and also attach workflows to the content types.
Read this for versioning in infopath.
2. Upgrade workflow , create new version and deploy the assembly to GAC.
Best way of doing this is to change the workflow.xml file so that the new workflow will have a different GUID & update the assembly version . Upgrading the exisiting assembly will break the exisiting instances . Since there is no versioning concept in features, deploy this solution as a new feature .
3.Set workflow for "No New Instances"
Go to Workflow setting > Remove workflow and check "No New Instances" againsts the existing workflow . This will make sure that new items will not be effected with the old workflow instance and will be associated only with the exisiting items in a list/library.
4. Attach workflow to content type
Associate the new workflow [deployed as a feature] with the upgraged form that is deployed in step 1.
To do this go to
Site settings
> Site Content type
> Click on content type to which thw workflow has to be attached.
> Workflow setting , associate workflow here .

Once we have this set up ready it can be noticied that while the old instances still keep working , the new one is applicable only to the items added to the library here after.