SharePoint Development Practices and Techniques

Choosing a development approach

At least as important as knowing how to create a solution is knowing when to create a solution and what type of solution to create. Even though this is a book about custom development, the best approach when using SharePoint is to use out-of-the-box functionality. Customizations are the number-one cause of problems with SharePoint environments. Knowing this, you have to make sure that when you create a custom solution, the same functionality couldn’t be achieved by using out-of-the-box functionality. If you do have to create a custom solution, you have to make sure that you create the right type of solution and that you build the solution in a way that uses the least amount of resources from the SharePoint server.

When you open up Visual Studio, the first thing you have to decide is what type of project you want to create. With the new SharePoint 2013 app model added into the mix, you can now choose between a SharePoint 2013 farm solution, a SharePoint 2013 sandboxed solution, and a SharePoint 2013 app. There isn’t one right project type; the best type depends on what kind of customizations you want to build and to what type of environment you want to deploy the customizations.

The best option is always the project type that puts the least amount of load on the SharePoint server. However, the solution also has to be maintainable and upgradable. The solution should not be overly complex, so that it can be maintained by others. The solution design should follow best practices to ensure that it can be upgraded to a next version of SharePoint. Of course, you also have to make sure that the solution can be deployed to the environment that you are creating the customizations for. To summarize, when you create SharePoint customizations, the following things have to be taken into account:

• Put the least possible load on the SharePoint server.
• Keep the customizations as simple as possible.
• Make sure you follow best practices, so the solutions don’t block the SharePoint environment from being upgraded.
• Ensure that the solution can be deployed to the target environment.

Because a SharePoint app can’t deploy server-side code to the SharePoint server, that will always be the project type that puts the least amount of load on the SharePoint server. Sandboxed solutions can deploy server-side code to the SharePoint server; however, a sandboxed solution can only use a limited amount of server resources before it is shut down. A farm solution can technically use all the resources that are available on the server, and because of that, a farm solution can bring down an entire SharePoint farm. This is not just a theoretical scenario; it actually happens on a regular basis to both small and really large SharePoint environments.

It is likely that the version of the customizations that you are building is not the last version. Either the customizations will be a huge hit and users will ask for more functionality, or they aren’t what users were expecting and they need modifications to fit the user’s needs. To make the solution easy to maintain, make it as simple as possible. This means that even though your first choice should be to build a SharePoint app, because that would consume the least amount of SharePoint server resources, you shouldn’t do it at all costs. If creating an app would create a solution that is significantly more complex, the best solution is probably to build a sandboxed or farm solution.

If the SharePoint environment is successful, it’s very likely that at some point the environment will have to be upgraded to the next version of SharePoint. Some SharePoint customizations can block the upgrade of a SharePoint environment. For instance, if a solution makes unsupported changes to the database or to SharePoint files on the file system, it won’t be possible to upgrade the environment. Also, when certain customizations such as site definitions are involved, it will be significantly more difficult to move the contents of the SharePoint farm to a cloud-hosted environment. Because Microsoft has positioned the SharePoint app model as the SharePoint customization type of the future, and because almost all parts of the SharePoint app live outside of SharePoint, creating apps is your safest bet when you want to guarantee that your environment can upgrade without being hindered by the customizations.

Using farm solutions means that the solution will have to be upgraded when the SharePoint farm gets upgraded. Sandboxed solutions live in the content database and can only affect the site collection that they are deployed in. This means that the impact they can have on an upgrade to a new version of SharePoint is a lot smaller than for farm solutions. However, sandboxed solutions are deprecated in SharePoint 2013. This means that although both sandboxed solutions that were created for SharePoint 2010 and new sandboxed solutions created for SharePoint 2013 are still fully supported, Microsoft is planning to remove support for sandboxed solutions at some point in the future. This doesn’t necessarily have to be in the next release; it could be in the release after that, or an even later release. Investing in large-scale sandboxed solutions is probably not a good idea, though.

If your environment is a cloud-hosted environment such as Office 365, you might not have much of a choice, because you won’t be allowed to deploy full trust solutions, and not all customizations can be created by using apps. In those cases, you will probably still want to create new sandboxed solutions. The advice would then be to try and create the solutions in such a way that you can remove the sandboxed solution without the entire site breaking down. When Microsoft then at some point removes the support for sandboxed solutions, at least your existing content is still accessible.

When you are upgrading from SharePoint 2010 to SharePoint 2013, you can choose how you want to upgrade you custom solutions:

• You can deploy your SharePoint 2010 solutions as is. Microsoft has designed SharePoint 2013 to make sure that your solutions keep working. This means that the entire solution should work when a site is in SharePoint 2010 mode. When a site is in SharePoint 2013 mode, most of the solution should work, but some things might not work. Things that don’t work are mostly related to functionality that is no longer available in SharePoint. For instance, custom solutions that use the SharePoint 2010 Web Analytics features will not work in a SharePoint 2013 environment, because the Web Analytics Service Application and all related functionality has been removed. In most cases, you will not just deploy your existing solutions as is. The only case in which it makes sense to not make any changes and just deploy an existing SharePoint 2010 solution as is to a SharePoint 2013 environment is when the solution is only there to keep existing SharePoint 2010 sites working in SharePoint 2010 mode in the SharePoint 2013 environment. In all other cases, you will at least want to recompile your solution.
• The second way to move SharePoint 2010 solutions to a SharePoint 2013 environment is to open the SharePoint 2010 solution in Visual Studio 2012. The solution can then be recompiled against the SharePoint 2013 DLLs. While you are doing this, you can decide to make some minor changes to the solution. You should definitely remove any references to functionality that no longer exists in SharePoint 2013, such as the Web Analytics functionality. Another example of something that will definitely not work in a SharePoint 2013 mode are SharePoint 2010 visual designs. Any master pages and style sheets that were created for SharePoint 2010 will not work in sites that are in SharePoint 2013 mode. Normally SharePoint will just not use the SharePoint 2010 designs in SharePoint 2013 mode sites. However, if you had a stapling feature in SharePoint 2010 that stapled a custom design to sites in the environment, especially if it stapled the design to all sites in the environment by stapling it to the GLOBAL site definition, you will want to remove the stapling feature before moving the solution to SharePoint 2013. Stapling a SharePoint 2010 design to the GLOBAL site definition and deploying it to SharePoint 2013 can make it impossible to create any fully functional sites, either by using out-of-the-box site definitions or custom web templates.
• The third approach that can be taken when moving solutions from SharePoint 2010 to SharePoint 2013 is to rebuild the solution to use the new SharePoint 2013 functionality where possible. Rebuilding the solution could mean replacing custom features with new out-of-the-box functionality. In a lot of cases, the aim should be to minimize the amount of customizations in an environment, which means that cutting customizations in favor of new out-of-the-box functionality is a very valid change to invest in. Do keep in mind, though, that in order to be able to upgrade existing sites you might need to have certain SharePoint 2010 customizations deployed in your environment, even if you don’t want to actively use them anymore in your SharePoint 2013 environment. There are also cases in which a customization can’t be replaced by out-of-the-box functionality but could be replaced by SharePoint apps, by an application that runs external to SharePoint and that uses the SharePoint Web Services or the vastly improved SharePoint Client Object Model. This should only be done if replacing the functionality by using a SharePoint app or an external solution doesn’t make the solution significantly more complex. If that is not the case, rebuilding functionality as a SharePoint app or as an external service will give you practice and experience in using the new development options, and it will make sure that your solution is easier to deploy in hosted environments. Assuming that the SharePoint app model is here to stay, it will also make sure that your solution becomes more future proof.