Developing applications for your SharePoint environment is the best way to ensure efficiency and productivity, but you do have to apply certain controls.
Adapted from “Pro SharePoint 2010 Governance” (Apress, 2012)
In many respects, creating solutions for SharePoint environments is similar to any other type of application development. It’s important that you manage requirements, versions and upgrades in a way that provides a predictable, repeatable process. You’ll also typically create different types of components and modules for SharePoint applications.
You can break SharePoint solutions down into two primary component categories: content and functionality. Content refers to the pages, lists, documents, and other items users create and store in SharePoint. Functionality refers to the logic that manages or processes that information. When customizing a SharePoint site, it’s sometimes difficult to distinguish between content and functionality.
Traditionally, end users create the content. Developers and other IT staff are the ones who create and deploy the functionality. However, in the case of SharePoint, the business users should be the ones creating items containing business process logic, such as workflows or InfoPath forms.
Another way to distinguish content from logic would be to look at where each is stored. SharePoint stores its content as a series of content databases. Unfortunately, you’ll have to manage some items as application components stored in the content databases, so that’s not ideal either.
For the purposes of SharePoint governance, we’ll define an application as a set of components a centralized team develops, deploys and upgrades. This might include UI components, reusable content, software modules, workflow definitions and so on. One group will create, test and package these components and deploy them to the production farm once they’re ready for use.
Depending on established governance policies, it might also be acceptable for other groups within the organization to create these types of components. In that case, SharePoint does have controls to prevent independently created applications from creating problems for the farm as a whole.
The SharePoint platform supports a variety of tools for different types of customization. There are different tools with different suitable uses. There are also appropriate types of controls you should apply to limit the use of tools in a production environment.
SharePoint Designer is a Windows client application with which you can design rich, highly customized SharePoint solutions. SharePoint Designer 2010 is the latest version of the product previously known as FrontPage. It’s available in both 32-bit and 64-bit versions, depending on the OS on which it will be used and the version of Microsoft Office installed on the client computer.
SharePoint Designer is intended for use primarily by Web site designers. It lets them do detailed customization on pages, lists, libraries and other SharePoint artifacts. While there are features within SharePoint Designer that might be useful to developers and administrators, it is first and foremost a design tool.
SharePoint Designer is ideal for creating business process workflows, integrating with line-of-business databases and creating custom presentations of business information on the SharePoint Server platform. You should note that SharePoint Designer 2010 is only compatible with the SharePoint 2010 Foundation and Server products.
While SharePoint Designer (and previously FrontPage) was once offered as a traditional commercial product, as of March 2009, Microsoft no longer sells SharePoint Designer, but gives it away. You can download the 32-bit version and the 64-bit version for free from Microsoft.
SharePoint Designer 2010 can be a powerful tool for creating SharePoint 2010 solutions. Like any powerful tool, though, it can be dangerous in the wrong hands. SharePoint Designer may not be appropriate for use in a production environment. As such, there are multiple configuration options within SharePoint Server 2010 that let you control which actions your SharePoint Designer users can perform.
The first set of options can disable SharePoint Designer access or limit the changes it can make. You configure these settings using the SharePoint Central Administration Web site, under General Application Settings. From the General Application Settings page, select Configure SharePoint Designer Settings. This page displays the available options and their current settings.
You set these options on a per-Web-application basis. To set these options for a Web application other than the default, select the application using the dropdown control at the top of the form. Look for these SharePoint Designer Settings options under Site Collection Administration:
Allow SharePoint Designer to Be Used in This Web Application: This setting controls the ability of SharePoint Designer to attach to the Web application. If this option is unchecked, all other settings become irrelevant.
Allow Site Collection Administrators to Detach Pages from the Site Template: Enabling this option lets you run SharePoint Designer in Advanced mode instead of Normal mode. Running in Advanced mode lets a user ghost pages by modifying them from the content originally in the site definition stored on the server’s hard drive. The customized version of the page is stored in the SharePoint content database. Any changes made to the site definition files aren’t reflected in detached pages. This can create maintainability problems and should be used with care.
Allow Site Collection Administrators to Customize Master Pages and Layout Pages: Master and layout pages (along with themes) are the keys to branding sites within SharePoint. SharePoint Designer contains powerful tools for updating these files. Most organizations prefer to maintain tight control of their site branding. Disabling this option helps lock down the site’s appearance in a production environment.
Allow Site Collection Administrators to See the URL Structure of Their Web Site: SharePoint Designer lets you examine and rearrange pages and folders within a site. Because this can dramatically impact site users, you should limit this function in most environments.
Besides configuring SharePoint Designer access to a Web application or site collection, users connecting to the site must have the Use Remote Interfaces permission. This permission gives users access to several types of remote interfaces including SharePoint Designer, Web services and the Web Distributed Authoring and Versioning, or WebDAV, publishing interface.
The Use Remote Interfaces permission is part of all of the default permission levels except Limited Access and Restricted Read. Any user assigned any of the other permission levels can connect to the Web site with SharePoint Designer. However, SharePoint Designer still obeys all normal permissions enforced by SharePoint Server. If the user doesn’t have permission to read or change an item in the SharePoint site, they won’t be able to do so using SharePoint Designer.
Microsoft Visual Studio 2010 is also useful for creating SharePoint solutions. This is the Microsoft professional development environment. Developers can use Visual Studio to create new features, Web Parts, event receivers and other code components that run “under the covers” in SharePoint. Visual Studio is a powerful tool, and is not intended for use by non-developers.
Visual Studio 2010 contains a large number of templates for creating all manner of SharePoint artifacts and packaging them for deploying to SharePoint. These artifacts are typically compiled into a solution package, which is then deployed to the SharePoint server farm in either a “sandboxed” or “farm-level” deployment. A solution package is a single file that contains all of the executables and metadata necessary to install a working set of components into the server farm.
Visual Studio is the primary tool for developing custom functionality on the SharePoint platform. Because of the potential for causing instability in the server farm, you should only use Visual Studio to directly interact with development SharePoint servers. This lets you debug and update the solution as needed without affecting the production environment.
Once development and testing are complete, you can deploy the compiled solution package to the production farm using the Web interface, the STSADM command-line tool or the Windows PowerShell scripting language.
These tools can help you and the people in your business user community develop and deploy customized applications for your SharePoint environment. As long as you apply the appropriate controls and restrict access levels when required, you can customize your SharePoint environment safely and efficiently.
Corey Erkes is a manager consultant for Sogeti USA LLC in Omaha, Neb. Erkes has worked with a wide range of companies at different points in the lifecycles of their SharePoint implementations. He is also one of the founding members of the Omaha SharePoint Users Group.
©2012 Apress Inc. All rights reserved. Printed with permission from Apress. Copyright 2012. “Pro SharePoint 2012 Governance” by Steve Wright and Corey Erkes. For more information on this title and other similar books, please visit apress.com.