Friday, April 4, 2014

Developing and deploying onto a multi-server farm in SharePoint 2010

Our main SharePoint 2010 farm consists of four servers and one database server.  We originally set up a disaster-recovery environment that was built in the same way, but this has since become our development/testing environment.  One of the servers has Visual Studio 2013 installed, and this is where I do all of my SharePoint 2010 development.

Almost everyone recommends developing on a single-server development farm, and one of the reasons is because Visual Studio can't confidently deploy the development onto the SharePoint site/site collection/web application.  It will often spring up an error:

Error occurred in deployment step 'Activate Features': Feature with Id 'f8214413-dcb6-428e-9252-032ca228ba03' is not installed in this farm, and cannot be added to this scope.

This is basically occurring because, well, I'm not sure.  I know it doesn't happen on a single-server development environment (or at least, not for the same reason).  But I didn't have a choice; I have to develop on this multi-server farm.

So, my solution.  Since I'm able to use PowerShell successfully to update the SPSolution, I figured I'd just take the wsp file created after building in Visual Studio, and run Update-SPSolution instead.  However, the wsp file is not always updated after Building a solution, only when Deploying.  And since Deploying fails (and often happens to retract the solution and delete web parts), I needed to figure out a way of creating the wsp file without attempting an actual deploy.

What I did was:

  1. Right-click on the project in Visual Studio, and select Properties.
  2. On the left-hand side, select SharePoint to bring up the deployment options.
  3. Click "New..." to create a new Deployment Configuration.
  4. Call it whatever you want, and simply add "Run Pre-Deployment Command" and "Run Post-Deployment Command" into the right-hand box labelled "Selected Deployment Steps".
  5. Click OK, and then change the Active Deployment Configuration to the one you just created.
Now, when you right-click your project and select Deploy, it will create a wsp file and then stop.  You can then run the following command to update your existing SPSolution:

Update-SPSolution -Identity projectname.wsp -LiteralPath "C:\Path To Visual Studio 2013\Projects\SolutionName\ProjectName\bin\Debug\projectname.wsp" -GACDeployment 

You can get the LiteralPath from the output in Visual Studio:

Successfully created package at: C:\Path To Visual Studio 2013\Projects\SolutionName\ProjectName\bin\Debug\projectname.wsp


Sure, you can't Debug in this way, but at least you can continue with your development on a multi-server farm.

No comments:

Post a Comment