How to deploy custom webpart from one SharePoint 2010 Server to another SharePoint 2010 Server

Recently, I was working on a suite of web parts in test server. Everything was proceeding fantastically until I needed to deploy my farm solution (containing many web parts) from my test server to another SharePoint development serve. Visual Studio 2010 provides outstanding functionality for creating Web Parts for SharePoint, and can deploy them locally (provided that SharePoint is installed locally), but it cannot deploy them to a different remote server.

So, upon searching, I stumbled across many bits and pieces of information regarding how to deploy SharePoint farm solutions, but alas, I could not find a single article which contained all of the necessary steps to get a web part to appear in SharePoint. After several frustrating hours I was able to discover the procedure, and now, I am here to pass it along to you. So without further ado…

1. Copy the WSP file to your SharePoint server (WSP to be deployed) Eg: Paste it in c:\backup\

2. Open the SharePoint 2010 Management Shell

3. stsadm –o addsolution -filename {WSP file name}

Eg: stsadm -o addsolution -filename c:\backup\Newsss.wsp

                 

4. stsadm –o deploysolution –name {WSP file name} –url http://{the name of your SharePoint server} –immediate –allowGacDeployment –allowCasPolicies

Eg: stsadm -o deploysolution -name Newsss.wsp -url http://gvasp2010test:81/ -immediate -allowGacDeployment –allowCasPolicies

                

5. stsadm –o activatefeature – name {name of feature} –url http://{the name of your SharePoint server}

Eg: stsadm -o activatefeature -name Newsss_Feature1 -url http://gvasp2010test:81/

6. Go in to SharePoint and your web parts should appear.

One thing which was poorly documented and tricky to figure out was the activation of the feature. Please notice the name parameter of step 5 says name of feature, not name of solution. This is important as if you do not enter the correct name, the web part will not be activated and will be unavailable. The feature name (if unchanged in Visual Studio) usually follows the naming convention of:

{solution name}_Feature1

I hope this helps you on your way to developing compelling web parts for SharePoint 2010.

Happy SharePointing……… 

Error occurred in deployment step 'Retract Solution': Cannot start service SPUserCodeV4 on computer

This week I was creating my first SharePoint 2010 Sandboxed solution using Visual Studio 2010.  I have successfully built and deployed other SharePoint projects on the server but I always used Farm based solution due to the requirements.

When I built the Sandboxed solution the project would build and package without any errors but when I tried to deploy it to the SharePoint site the following error occurred:

Error    1    Error occurred in deployment step ‘Activate Features’: Cannot start service SPUserCodeV4 on computer ‘SERVERNAME’ 0    0    SP2010Test

The error can be easily resolved by starting the Microsoft SharePoint Foundation Sandboxed Code Service which can be accessed through the Central Administration site in SharePoint.   Open the Central Administration site and go to System Settings and click on Manage Service on server:

Check to see if Microsoft SharePoint Foundation Sandboxed Code Service  is running, it should be stopped :

Start the service and try deploying the Sandboxed solution. 

SharePoint - Elevated Privileges

When developing using the SharePoint object model, certain operations has to be run with elevated privileges. For instance, setting information into the property bag of a site needs to be done with elevated privileges. This post shows how this is done, and also includes a helper method for making it easier and shorter to do this.

There is a method called SPSecurity.RunWithElevatedPrivileges in the object model that takes a delegate as argument. The delegate is then run with more permissions. An important note regarding this: You must not use old references to SPWeb or SPSite instances inside your delegate, since they are “contaminated” with lower permissions. What you have to do is to create new SPSite and SPWeb instances using the Ids of the sites and webs you already have a reference to, like this

SPSecurity.RunWithElevatedPrivileges(delegate() 
{ 
    using (SPSite site = new SPSite(SPContext.Current.Site.ID)) 
    { 
        using (SPWeb elevatedWeb = site.OpenWeb(webId)) 
        { 
            //Your code here 
        } 
    } 
});

If you need to do these kind of operations in several locations, this is a lot of repeating code to include. A colleague of mine made a small helper method that does the setup for elevated privileges for you. Here’s the short code snippet:

private delegate void CodeToRunElevated(SPWeb elevatedWeb);
private static void RunElevated(Guid webId, CodeToRunElevated secureCode)
{
    SPSecurity.RunWithElevatedPrivileges(delegate()
    {
        using (SPSite site = new SPSite(SPContext.Current.Site.ID))
        {
            using (SPWeb elevatedWeb = site.OpenWeb(webId))
            {
               secureCode(elevatedWeb);
            }
        }
    });
}
To invoke this, you call on the method with the Id of your web as one argument, and a delegate taking an SPWeb as the other. When the method is invoked, the SPWeb argument will be “uncontaminated” and pushed to elevated privileges. This example sets the name, title, and description of a site.

RunElevated(web.ID, delegate(SPWeb elevatedWeb)
{
    elevatedWeb.Name = siteTitle;
    elevatedWeb.Title = siteTitle;
    elevatedWeb.Description = siteDescription;
    elevatedWeb.Update();
});