SharePoint Development Practices and Techniques

Before you can start building a custom Microsoft SharePoint solution you will have to make sure you set up your development environment correctly. Because the hardware requirements for SharePoint 2013 are again a lot more demanding than they were for SharePoint 2010, setting up a new development environment might well mean that you have to acquire new hardware. There might be quite a bit of time between the moment that you order the hardware, whether from an external vendor or from an internal department, and when you can actually start using the hardware. This means that it’s important to start planning your SharePoint customizations early, so that waiting on the hardware will not interfere with your project planning.

When you have gotten the hardware, you will have to install your development environment. It is important to do this meticulously, to follow best practices and to make sure you document the entire configuration. Documentation is important if you have to create a second environment, or if you have to recreate your development environment.

When your SharePoint environment has been set up properly, you will need proper specifications so that you can start designing your solution. You will have to decide what type of solution will best suit your skills, the environment into which the solution will have to be deployed, and the functionality that you have to create. SharePoint 2013 introduces a new development approach, which means that you can now not only create farm solutions and sandboxes solution, but you can also create SharePoint apps. SharePoint 2013 also introduces a third application programming interface (API) by making Representational State Transfer (REST) APIs available that allow you to use simple HTTP requests and responses to perform CRUD (create, read, update, delete) operations on SharePoint data.

All these additions give you more options, but they also require you to make more choices, and it is important to make deliberate and well-informed choices to make sure that you end up with the best solution that you could possibly build for your specific situation and scenario. This chapter talks you through a lot of the choices and can help you make the right decisions.

Setting up a developer environment

Whenever you are looking at building a custom solution for any platform, one of the things you will have to determine is what environment you will use to build your custom solution. This is no different when you want to create a custom solution for SharePoint. Determining the best way to set up your development environment has always been difficult for SharePoint, and SharePoint 2013 adds even more complexity to it, with extended hardware requirements and two new types of servers.

Let’s start by looking at the different server roles that you can choose from.

• Domain controller

• Database server

• SharePoint server

  • Web server

  • Application server

• Office Web Apps server

• Windows Azure workflow server

Although it is possible to build a development environment by using a standalone server installation of SharePoint on a single server without a domain controller or separate computer that is running Microsoft SQL Server, for practical reasons you will at least need a domain controller, a database server, and a SharePoint server. For certain types of SharePoint apps you might not need a SharePoint development environment, because these apps can be hosted on a generic web server that doesn’t have SharePoint installed on it. However, you should test what your app looks like in a SharePoint environment before you add the app to the production environment, so you should always use some sort of test or development environment.

If your development environment is installed in an existing domain, you don’t have to build your own domain controller; you can simply use an existing one. If you are creating your own domain, you will have to create a domain controller as well. You can create a single server and use that as the domain controller, the database server, and the SharePoint server. Be aware, though, that some things don’t work on a domain controller and some things have to be configured differently. It is important to keep this in mind while developing and testing custom solutions on your development server.

In SharePoint 2010, Microsoft Office Web Apps came in a separate installation that had to be installed on at least one of the SharePoint servers in the farm. After installation, they could be configured as service applications. In SharePoint 2013, this is no longer the case. Office Web Apps is now its own product. Office Web Apps has to be installed in its own separate farm, and it cannot be installed on a server that also has SharePoint installed on it, because Office Web Apps will completely take over the Internet Information Services (IIS) on the server. You can install Office Web Apps on one or more servers and connect the Office Web Apps farm to the SharePoint farm. Having Office Web Apps installed in its own farm on one or more servers means that it is now more scalable. The Office Web Apps farm can be connected to one or more SharePoint farms. This means that one Office Web Apps farm can support the SharePoint servers of several developers.

With SharePoint 2010, you automatically got the SharePoint 2010 workflow host, which was based on Windows Workflow Foundation 3. Windows Workflow Foundation was a native part of SharePoint, but the way in which it was implemented meant that customers who were serious about using workflow in SharePoint almost always ran into issues with scalability. SharePoint 2013 uses a new workflow service, which is built on the Windows Workflow Foundation components of the Microsoft .NET Framework 4.5. The new workflow service is called Workflow Manager and, like Office Web Apps, is a separate installation that should be installed on separate servers. After you have created a Workflow Manager farm consisting of one or more servers, you can connect this farm to your SharePoint 2013 farm. As with Office Web Apps, creating a separate workflow farm means that your environment will be a lot easier to scale out and a lot more suitable for use in a serious workflow solution or a large enterprise. Your old SharePoint 2010 workflows will still work, because SharePoint 2013 automatically installs the SharePoint 2010 workflow engine.

To summarize, if you want to have all SharePoint 2013 functionality available to you in your development environment, you will need at least three servers:

• A domain controller/database server/SharePoint server
• An Office Web Apps server
• A Workflow Manager server

You can, of course, have many more: you could split out your domain controller, database server, and SharePoint server; you could have separate SharePoint web and application servers; and you can have as many Office Web Apps and Workflow Manager servers as you want. How many servers you use will mostly depend on the size of the solution that you are building, the type of functionality that you need, and—let’s face it—your budget.

Deciding between virtual and physical

An important decision that you have to make when you start to think about your development environment is whether you will be using virtual or physical servers. You could choose to install a supported server operating system (we’ll get into more detail on that soon) directly on your computer, either by connecting to an existing domain or turning the computer into a domain controller and installing SQL Server and SharePoint on it. You can no longer install SharePoint on a client operating system such as Windows 7 or Windows 8 as you could with SharePoint 2010. However, unlike Windows 7, Windows 8 does support Hyper-V, which means that you can create your virtual machines in Hyper-V on your Windows 8 computer. The Windows 8 version of Hyper-V is officially called Client Hyper-V.

As long as you only work on a single project, and you only need a single server (so you don’t need Workflow Manager or Office Web Apps), you can run your development environment directly on your computer. However, creating your development environment by using virtual servers is a far more flexible solution. You can either host the virtual servers on your own computer or on a server somewhere in the network, or even in the cloud. With today’s hardware requirements (especially the memory) and considering the fact that you might need more than one server, running your development environment on your computer won’t be a feasible solution for most people, so in a lot of cases development servers are hosted in a network somewhere. If you are using your development environment on a daily basis, it is recommended that you make sure that your servers are hosted somewhere relatively close to you to minimize latency issues and frustrations.

Running the development environment on a virtual server has a few advantages:

• Using virtual servers as a development environment means that you can use a different virtual server for each project you’re working on. When a developer works on more than one project, it is better not to have the configuration and custom solutions from these projects in a single environment. Settings or solutions from one project might influence the behavior of the solutions from the second project, which means that you have no way of knowing what is causing problems and you can’t determine how the solution will behave in the production environment.

• Another advantage of working with virtual servers is the fact that it’s easy to create snapshots and to go back to them. By using snapshots, the developer can run tests and, depending on the outcome of a test, decide to go back to a snapshot of a previous situation. He can then make some changes to the solution and run the same tests again.

  Also, when project work goes on for a long time, environments sometimes get messy from testing different solutions and settings, and going back to a snapshot is a very easy way to clean that up. Using snapshots also means that you can go back to a previous state if a solution that you deployed or a script that you ran messed up your environment.

• Using virtual servers to create development environments also makes it easier to set up a new development environment when a new developer is added to the project. Later on in this chapter we will talk in more detail about having a team of developers work on a single project.

• In most cases, using virtual servers is also a lot cheaper than using physical servers. If you have a large physical server, you can run several virtual servers on it. This means you can save on hardware costs. Also, if you don’t need all your servers at the same time, they can share the resources, and if you need a new server, you can very quickly set it up, instead of having to order hardware and wait till it arrives.

Understanding hardware and software requirements

As with every SharePoint version, SharePoint 2013 has its own hardware requirements. Table 2-1 shows an overview of the hardware requirements for SharePoint 2013. As you can see, the amount of memory needed to run a SharePoint Server development environment has again increased significantly. There are a couple of things to note:

• Single server means that both SharePoint and its databases are running on the same server.
• A single server development installation of SharePoint Server 2013 is listed as requiring 24 gigabytes (GB) of RAM. However, the amount of RAM it really needs heavily depends on what services you are running in the environment. For instance, if you are actively using search, you probably need 24 GB, or at least something close to that. However, if you are only using web applications and some of the lighter service applications, you can get away with having a lot less memory.
• The storage on the system drive has to be at least 80 GB. It is very important to note that this does not include the storage that is needed to store the databases that contain the content from your SharePoint environment, and it doesn’t include the storage that is needed to store, for instance, the SharePoint logs. Make sure that you have enough storage on your system; storage is cheap, and it’s very annoying to have to go into your development server every day to try and free up some storage so that at least your server will keep running.

Table 2-1 Hardware requirements for SharePoint 2013

SharePoint 2013 also comes with its own software requirements. For a SharePoint 2013 server, the following software is required:

• The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or Datacenter or the 64-bit edition of Windows Server 2012 Standard or Datacenter

• Hotfix: The SharePoint parsing process crashes in Windows Server 2008 R2 (KB 2554876)

• Hotfix: FIX: IIS 7.5 configurations are not updated when you use the ServerManager class to commit configuration changes (KB 2708075)

• Hotfix: WCF: process may crash with “System.Net.Sockets.SocketException: An invalid argument was supplied” when under high load (KB 2726478)

• The prerequisites installed by the Microsoft SharePoint Products Preparation Tool

• Hotfix: ASP.NET (SharePoint) race condition in .NET 4.5 RTM:

  • Windows Server 2008 R2 SP1 (KB 2759112)

  • Windows Server 2012 (KB 2765317)

For a database server in a SharePoint 2013 farm, the following software is required:

• The 64-bit edition of Microsoft SQL Server 2012, or the 64-bit edition of SQL Server 2008 R2 Service Pack 1

• The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or Datacenter or the 64-bit edition of Windows Server 2012 Standard or Datacenter

• Hotfix: The SharePoint parsing process crashes in Windows Server 2008 R2 (KB 2554876)

• Hotfix: FIX: IIS 7.5 configurations are not updated when you use the ServerManager class to commit configuration changes (KB 2708075)

• Hotfix: ASP.NET (SharePoint) race condition in .NET 4.5 RTM:

  • Windows Server 2008 R2 SP1 (KB 2759112)

  • Windows Server 2012 (KB 2765317)

• .NET Framework version 4.5

When setting up your development environment, you should always aim to make sure that it’s as much like the production environment as possible.

Delivering high-quality solutions

To deliver high-quality solutions it is best for the development environment to be as much like the production environment as possible. Theoretically this is true for all aspects of the environment: hardware, software, configuration, and data. In most cases, however, the hardware of a development environment cannot be the same as the hardware of a production environment. This is fine, as long as you are aware of the differences and what the impact of them might be on your test results.

So that accurate tests can be performed in a development environment, the software should be the same as the software in the production environment. You should use the same version of Windows Server and SharePoint and a similar version of SQL Server. If the production environment has SharePoint Server installed, make sure the development environment doesn’t have SharePoint Foundation installed. If the production server has a Windows service pack installed on it, make sure you install the same service pack in the development environment. It also works the other way around; if the service pack will not be installed in the production environment, do no install it in the development environment either. If one of the environments gets a SharePoint service pack or cumulative update installed on it, make sure all environments get that same service pack or cumulative update installed on them.

The way in which you configure your development server should also be as much like the production environment as possible. The best thing is to try and get access to the build guide for the production environment and use that to set up your development environment.

Examples of settings that are important when configuring your development environment are:

• Using the default SQL instance or different instances

• The authentication type:

  • NT LAN Manager (NTLM)

  • Kerberos

  • Windows claims

  • Security Assertion Markup Language (SAML) claims

• Using host headers on your web application, or Host Header Site Collections

• HTTP or HTTPS

• The number of web applications

• The way in which the farm, application pool, and services accounts are configured and the level of permissions they have. Make sure you have the same number of managed accounts in your development environment as in the production environment.

In order to get accurate test results, it is also very helpful to have representative sample data and test users. The data will help you perform the same type of actions that a user would. If you are able to load enough sample data into your development environment, it will also help you test the scalability of your solution, at least to a certain extent. Most custom solutions perform very well with only a couple of documents, users, or sites, but when there are tens of thousands it might be a completely different story. Even if you can’t test on the scale of your production environment, you should always keep in mind what numbers your solution will have to cope with after it’s in production. It is always a good idea to at least make sure that you test whether your application will keep working past the list view threshold. The list view threshold is a web application setting that can be adjusted in Central Administration that tells SharePoint how many items can be requested from the database in a single query. The default list view threshold is 5,000.

As a developer, you will usually log in with an account that has administrative permissions. It’s the only way in which you can properly develop custom full trust solutions. Do make sure that you are not logged on as the SharePoint farm account. When you are testing your solution, it is very important to not only test it using your administrative account, but also with accounts that have Read, Contribute, and Site Owner permissions. A lot of custom SharePoint solutions will work fine when run by an administrator, but need more work when a reader or contributor of a site should be able to work with them as well. For instance, the List view threshold (the throttling feature that specifies the maximum number of list or library items that a database operation, such as a query, can process at the same time) will not be applied if you are logging onto your SharePoint environment as a local administrator, which means that you cannot test the behavior of large lists properly.