Conduct Team-Based Development of Windows SharePoint Services and SharePoint Portal Server Applications

Article
03/25/2009

Larry Kuhn
Microsoft Corporation

November 2005

Applies to:
Microsoft Windows SharePoint Services
Microsoft Office SharePoint Portal Server 2003

Summary: Learn to conduct team-based development of Microsoft Windows SharePoint Services and Microsoft Office SharePoint Portal Server 2003–based applications. These applications can include customized Web Part Pages, Web Parts, supporting Web applications, and Web services. (13 printed pages)

Introduction to the Team Development Environment
Windows SharePoint Services or SharePoint Portal Server Development Environment
Semi-isolated and Non-isolated Development Models
Isolated Development Model
Configure Visual SourceSafe Integration
Manage Key Files for Web Part Assemblies
Promote Components to the Next Environment
Promote Changes to Existing SharePoint Sites
Refresh Development Environments from Production
Conclusion
Additional Resources

Introduction to the Team Development Environment

In Microsoft Windows SharePoint Services and Microsoft Office SharePoint Portal Server 2003 application development, the team development environment consists of the workstation and server computers you need to support the software development process.

Note The team development environment baseline is fully defined in Team Development with Visual Studio .NET and Visual SourceSafe. This article focuses on additions and adjustments to the baseline definition.

However, the way you develop Windows SharePoint Services or SharePoint Portal Server 2003 applications differs from the way you develop typical Microsoft ASP.NET applications, as follows:

In most cases, the custom Web pages you add to a SharePoint site to create an application are stored within the Windows SharePoint Services content database rather than on the file system of the Web server. You can use a site definition package to create and deploy custom Web pages that reside on the file system of the Web server, but that technique is beyond the scope of this article.
Windows SharePoint Services or SharePoint Portal Server applications might use custom Web Parts. You develop and manage custom Web Parts independently from the base SharePoint application that uses them.
Windows SharePoint Services or SharePoint Portal Server applications might use (or link to) traditional ASP.NET applications, which you develop and manage independently from the base SharePoint application that uses them.

Note The information in this article applies to both Windows SharePoint Services and SharePoint Portal Server 2003 applications. Unless we explicitly state otherwise, for brevity, we use SharePoint applications to indicate that the information applies to both Windows SharePoint Services and SharePoint Portal Server 2003 applications you develop.

Site Development

The process of developing the Windows SharePoint Services site portion of a SharePoint application resembles configuration more than development. Your primary tool for Windows SharePoint Services site development is Microsoft Office FrontPage 2003. You use the browser-based user interface to create a new SharePoint site that is based on a site template that most closely matches the final structure you want for the site you are building.

After you create the Windows SharePoint Services site in the Developer Sandbox environment, you then use FrontPage 2003 to customize it to suit your needs. For more information on hardware environments for development, see Windows SharePoint Services or SharePoint Portal Server Development Environment.

Web Part Development

The process you use to develop a Web Part is similar to how you would develop any custom ASP.NET Web control. You build and manage Web Parts in a Microsoft Visual Studio .NET 2003 project, and manage the source code for them in Microsoft Visual SourceSafe. Your solution also contains a deployment project that packages the Web Part assembly and installs it on target servers running Windows SharePoint Services or SharePoint Portal Server 2003 in the Test environment.

Windows SharePoint Services or SharePoint Portal Server Development Environment

You use various hardware environments to support the development of SharePoint applications. These hardware environments include the following:

Developer Sandbox
Assembly Test/Integration
Fix
Production

These hardware environments are patterned after the typical hardware environment configurations used to support the development of ASP.NET applications. You can notice some differences, however, in the specific recommendations we give for developing SharePoint applications.

Typically, the Developer Sandbox environment follows an isolated development model, and is essentially a developer workstation configured with the required application software and development tools. Because you can install Windows SharePoint Services onto only servers running Microsoft Windows Server 2003, and because developer workstation hardware might be insufficient to support this software configuration, you might not find it practical to plan to use only developer workstations to achieve a Developer Sandbox environment.

Figure 1 shows the logical flow of software components through these environments. The numbered arrows in the diagram indicate the logical promotion of developer work products from one environment to the next. The unnumbered arrows indicate the physical movement of developer work products from one environment to the next. Work products are always collected from source code control by the build server and then deployed from the build server to the appropriate target environment. The Developer Sandbox environment is the only exception to this rule, because it allows direct deployment of work products in development from the developer's workstation.

Figure 1. Logical and physical flow of software components through environments

1. Unit-tested changes are promoted from the Developer Sandbox to the Assembly Test environment.
2. A production release occurs when Integration-tested changes are promoted from the Assembly Test environment to both the Production environment and the Fix environment. This ensures that the Fix environment is kept in synch with the Production environment. You must ensure that no promotion randomly disrupts work in progress in the Fix environment.
3. Unit-tested emergency fixes are promoted from the Developer Sandbox to the Fix environment as needed.
4. Tested fixes are promoted from the Fix environment to the Production environment.

The following table explains the details of each server identified in Figure 1.

Table 1. SharePoint development environment details

Computer	Server Type	Purpose	Software	Comments
Developer Workstation	n/a	Coding and compiling	Microsoft Windows XP Visual Studio .NET 2003 Visual SourceSafe 6.0d Client components FrontPage 2003 Web Part Templates for Microsoft Visual Studio .NET
Build Server (DevBLD)	Low-end	Building assemblies and deployment packages	Windows XP Visual Studio .NET 2003 Visual SourceSafe 6.0d Client components FrontPage 2003	Access to this server is limited to the build master.
Source Code Control Server (DevSCC)	Low-end	Repository for source code for all custom assemblies	Windows Server 2003 Visual SourceSafe 6.0d Server components	Hosts source code repositories for other development environments.
Database Server (DevDB)	Mid-range	Shared database server	Windows Server 2003 Microsoft SQL Server 2000	Hosts databases used in SharePoint Portal Server and other development environments.
Developer Sandbox (DevSPS)	Low-end	Execution and debugging	Windows Server 2003 SQL Server 2000 SharePoint Portal Server 2003*	Hosts Web sites for each developer. All development team members have administrative access to this server. This server is configured to use local databases.
Assembly Test/Integration (AsmSPS)	(dependent on selection for Production SharePoint Portal Server servers – should be the same as Production in the ideal case)	All integration and performance testing of scheduled changes and enhancements	Windows Server 2003 SharePoint Portal Server 2003*	Hosts Web site configurations that mirror production. Administrative access to this server is limited to the build master. This server uses DevDB databases.
Fix (FixSPS)	Low-end Windows	All integration and performance testing of emergency fixes	Windows Server 2003 SharePoint Portal Server 2003*	Hosts Web site configurations that mirror production. Administrative access to this server is limited to the Build master. This server uses DevDB databases.

* If your application uses only Windows SharePoint Services features, then install only Windows SharePoint Services rather than SharePoint Portal Server 2003.

Developer Workstation

Because of the hardware and software requirements for installing Windows SharePoint Services, an isolated development model may not be feasible. However, most developers prefer to use an isolated development model whenever possible because it provides more flexibility to work remotely and without risk of disruption from other developers. The following sections describe how to configure a developer workstation to achieve each of the developer isolation models.

Semi-isolated and Non-isolated Development Models

To run and debug custom Web Parts, you must use Windows Server 2003 to host Windows SharePoint Services. Because the workstation computers of most developers have Microsoft Windows 2000 Professional or Windows XP installed, running and debugging custom Web Parts locally is not possible. In addition, custom Web Parts may also interact with other systems that you cannot make available within the isolated development environment.

For these reasons the developer should prepare his or her local workstation so that it can be used to perform only the coding and compiling****operations. This configuration is referred to as a semi-isolated or non-isolated development configuration because multiple team members share the Developer Sandbox server for execution and debugging of their custom Web Parts.

To configure a semi- or non-isolated development environment, install the following products in the order shown:

Microsoft Office FrontPage 2003
Microsoft Visual Studio .NET 2003
Web Part Templates for Microsoft Visual Studio .NET
Microsoft Visual SourceSafe

To perform development and debugging operations on the target Windows SharePoint Services server, you must adjust configuration settings on both the client developer workstation and the target Windows SharePoint Services server.

Unfortunately, the semi- or non-isolated development configuration becomes impractical when more than a few developers are working together on a team, for two reasons:

Only a single developer can debug the application at one time, and while that developer works, all other operations in the environment are blocked.
Managing and coordinating the deployment of in-progress work products with a large team becomes a logistical challenge.

Web Part Development Configuration

You can find most of the information you need for Web Part development configuration in "Developing and Debugging from a Remote Computer" in Debugging Web Parts. In addition to the steps listed in that article, you also need to perform the following procedure.

To complete Web Part development configuration

Follow the configuration steps documented in "Developing and Debugging from a Remote Computer" in Debugging Web Parts.
Add references to the SharePoint assemblies into your Web Part project.

To minimize network traffic during the build process, copy the Microsoft.*.dll files from the path remote_drive_on_DevSPS:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\ISAPI on the Developer Sandbox server to a location on the developer workstation, and add the file references by pointing to the local copies.

Note To minimize problems when moving Visual Studio projects from one developer workstation to another, ensure that all developers working on the development team use the same local path for their local copies of the SharePoint assemblies.
Ensure that SharePoint assemblies are not copied to the build folder.

When developing Web Parts on a remote computer, change the Copy Local property on the SharePoint assembly references to false to prevent the assembly from being copied to the build folder. If the build folder is set to the remote computer's path (remote_drive_on_DevSPS:\InetPub\WWWRoot\bin), and you copy SharePoint assemblies to that location, some Web Parts cannot work.
Fully enable debugging support on the server running Windows SharePoint Services or SharePoint Portal Server 2003 by changing the web.config file as follows:
1. Set the compilation element's debug attribute to true.
2. Because you are doing remote debugging, and because SharePoint Web Parts run with partial trust by default, adjust the code access security settings. Set Trust level="Full" in the web.config file. To ensure that your Web Part does not inadvertently contain code that requires more code access security permissions than are provided by the WSS_Minimal or WSS_Medium security policies, change the Trust Level to Full only when it is needed for a remote debugging session.
  
  For more information regarding code access security policies, see Code Access Security for Developers.
Change the properties of the project to start the URL where the Web Part is located.
Set the properties of the project to enable ASP.NET debugging.

Web Application Development Configuration

In addition to building Web Parts that you intend to host directly within Windows SharePoint Services Web Part Pages, you might also need to develop Web applications that are hosted on Windows SharePoint Services servers, and which interact with the Windows SharePoint Services API.

For more information, see Getting Started with Customizing a SharePoint Web Site in Visual Studio .NET.

Isolated Development Model

You can use Microsoft Virtual PC to enable you to perform isolated development of custom Web Parts. Within the Virtual PC virtual machine image, you can establish a single-box system that collapses the components of the developer workstation and Developer Sandbox onto one server image. This configuration enables a developer to perform coding, compilation, execution, and debugging operations within the Virtual PC environment on his or her local workstation.

To set up the isolated development configuration (high-level steps)

Install Microsoft Virtual PC.
Create a new virtual machine image.

Steps 3–9 are all performed within the virtual machine image.
Install Microsoft Windows Server 2003.
Configure the required server roles (File Server, Application Server, Mail Server, Domain Controller, DNS Server, DHCP Server).
Install Microsoft Office SharePoint Portal Server 2003 (which also installs Windows SharePoint Services and MSDE as part of its installation process).
Install Microsoft Office FrontPage 2003.
Install Microsoft Visual Studio .NET 2003.
Install Web Part Templates for Microsoft Visual Studio .NET.
Install Microsoft Visual SourceSafe.

Configure Visual SourceSafe Integration

You can control the versioning of Visual Studio Web Part projects and Web application projects using Visual SourceSafe in the same way you control versioning in typical class library and ASP.NET Web application projects. For more information, see Source Control Services in the Visual Studio .NET documentation.

Manage Key Files for Web Part Assemblies

If you are planning to deploy your Web Part assemblies into the global assembly cache, you must sign the assemblies using a key file to generate a strong name. You should also check with the server administrators of your target environment to confirm that they allow deployment of custom assemblies to the global assembly cache.

You can manage in many ways the key files (*.snk) that you need for giving a strong name to an assembly. Because Windows SharePoint Services requires Web Part assemblies to have strong names, you must establish an approach to manage key files for your development project that includes Web Parts.

Consider the following issues:

Key file use Will you use one key file to sign all assemblies developed by the organization, different key files within each project team, or different key files for each assembly?
Key file access Will any developer or only the build master be able to access the key files?

In the simplest case, if you determine that any developer can have access to the key files and that you can use the same key file for all assemblies, you can store them in Visual SourceSafe, link them into each project directory, and add them as items within each Web Part project. In addition, to help minimize problems when moving Visual Studio projects from one developer workstation to another, set the value of the AssemblyKeyFile attribute within the AssemblyInfo.vb file as follows:

   <Assembly: AssemblyKeyFile(".\..\..\keypair.snk")>

However, if your organization wants to tightly restrict access to key files, then the developers must use delay signing of their assemblies during the development cycle. Unless you register the assembly/public key token to bypass verification, the common language runtime does not allow the assembly to load.

To register your delay signed assembly, you need to use the Strong Name Tool (Sn.exe) provided in the Microsoft .NET Framework SDK.

      sn -Vr <assemblyName>,<publiKeyToken>

After you register the assembly, you should be able to use your delay signed assemblies within Windows SharePoint Services or SharePoint Portal Server 2003 without issues.

For more information, see Delay Signing an Assembly.

Promote Components to the Next Environment

As each member of the development team completes initial development activities, he or she promotes, or migrates, their work products from the Developer Sandbox environment up to the Assembly Test/Integration environment. These work products, which you can consider components of the solution, might be sites, Web Part Pages, Web Parts, lists, and so on. Then, test engineers on the development team execute tests against the integrated solution within this environment. After those tests pass, the work products are finally promoted to Production. The processes available for performing these promotion activities vary depending on the type of work product to promote and whether the solution resides on Windows SharePoint Services or SharePoint Portal Server 2003.

Promote Web Parts

Regardless of the processes you use to promote the site's structure and contents, which are addressed later in this article, if your site includes custom Web Parts or document library event handlers, you must first prepare the destination server environment by installing those components.

To prepare the destination server environment

Install the assemblies you need.
Create the entries (SafeControl) in the web.config file.

You can automate these steps by preparing and executing a Web Part installer. For detailed information about packaging and deploying Web Parts, see Packaging and Deploying Web Parts for Microsoft Windows SharePoint Services.

You must then package a Web Part into a .cab file, and deploy the file to the target servers using the following command:

stsadm –o addwppack –filename MyWebPart.cab

Promote Windows SharePoint Services Sites

After you complete all customizations to a Windows SharePoint Services site in the Development environment, you are ready to promote it to the Test environment.

You can move sites in two ways:

Use Stsadm.exe to back up and restore entire site collections.
Use Smigrate.exe to back up or restore individual sites and subsites.

For more information about these methods, see "Backup and Migration" in the Windows SharePoint Services Administrator's Guide.

Note FrontPage 2003 includes functionality very similar to Smigrate.exe using Backup or Restore commands (Tools menu, Server submenu). Because you cannot script this technique, you can consider it as a tool only for a manually managed promotion process.

STSADM

Use the Windows SharePoint Services administration utility (stsadm.exe -o backup) to package the site in the Development environment. This process creates a single data file that contains all of the pages and contents that are included in the site.

You can then provide the backup data file to the administrator of the target system, who in turn uses the Windows SharePoint Services administration utility restore feature (stsadm.exe -o restore) to deploy the Windows SharePoint Services site onto the target system.

Note Before you perform the restore/deploy operation, you must install any Web Parts that are used within the site on the target system.

SMIGRATE

You can also use the Windows SharePoint Services site migration utility (Smigrate.exe) to manipulate Windows SharePoint Services sites. (The utility was originally designed for migrating SharePoint Team Services from Microsoft sites to Windows SharePoint Services.) If you are backing up a Windows SharePoint Services site, Smigrate.exe does not back up security information (users, groups, rights, and so on) or personalizations (personal views of the home page).

When you use Smigrate.exe, you should examine the log files it places in your %temp% directory to see what errors were encountered. You should also manually verify your restored site.

Because Smigrate.exe does not perform all of the steps needed to move a Windows SharePoint Services site to another location, you must write additional code to enable Smigrate.exe to be used within a promotion tool. A promotion tool for the deployment of a Windows SharePoint Services application would do the following:

Create the site at the destination
Call Smigrate.exe to import an .fwp file
If your application uses document library event handlers, reconfigure those in the imported site

However, you should be aware that Smigrate.exe cannot do the following:

Create the site for you; you must write code into a deployment script to do this
Move any files from the file system, such as assemblies, the web.config file, and so on
Transfer the configuration for document library event handlers

Promote SharePoint Portal Server Sites

Your only option for migrating SharePoint Portal Server sites from one environment to another is to use the Backup and Restore program (SPSBackup.exe) in SharePoint Portal Server 2003. Although you can run the SPSBackup.exe from the Start menu, for portal site promotion purposes you should execute it in a command prompt by using a script file because you need to repeat this process during development.

To prevent overwriting the Profile or SharePoint Portal Services data in your destination portal environment

Use the following command to back up only the portal site's SITEDBS component:

spsbackup  /portalportalUrl  /service sitedbs /filebackupfilepath\fileprefix

On the destination server, restore that backup into the new environment using the SharePoint Portal Server 2003 Backup and Restore program user interface.

Because SharePoint Portal Server 2003 uses GUIDs to uniquely identify portal site instances within a server farm, you cannot restore two derivatives or versions of the same source portal site into the destination server farm environment. This means that if you want to promote the portal site again, you must first delete the previously promoted instance. When you do this, you lose all of the content that was created or modified in the destination environment as well. Therefore, you may find portal site promotion useful only before initial production deployment, or if you want to move a snapshot of a production portal site back into the Development or Test environment.

Save Windows SharePoint Services Sites as Templates

You can use the Windows SharePoint Services feature for saving a site as a template to make new sites available in each environment. After you create a team site and customize it with FrontPage with the look and feel you want, you can save the site as it exists in one environment as a template, and then bring that template over into the next environment to use as a site template to create other sites.

To save the site as a template

Click Site Settings, and then under Administration, click Go to Site Administration.
Under Management and Statistics, click Save site as template.

Note Site templates have a maximum size limit of 10 MB. If you attempt to save a site that exceeds this size limit, you receive an error message and cannot use this technique to promote the site.

After you save the site as a template in the Developer Sandbox environment, you need to download it as a file, and then upload that file into the Assembly Test/Integration environment. Where you upload the file is determined by the level at which you need to create the new site. If you need to create the new site under an existing site, you can upload the template to the parent site's Site Template Gallery. If you need to create sites at the global level for an entire site collection (for example, http://portal/sites/NewSiteBasedOnNewTemplate) based on the custom template rather than at the subsite level, then you add the template to the Central Template Gallery instead.

For more information about uploading a template to the Site Gallery or Central Template Gallery, see "Working with Templates" in the Windows SharePoint Services Administrator's Guide.

Promote Changes to Existing SharePoint Sites

To keep things simple and manageable, you should avoid promoting changes to existing SharePoint sites. The SharePoint site promotion techniques based on the backup/restore feature completely overwrite the contents of the site in the target environment and should not be used to promote incremental changes to existing sites.

For example, if a user added documents to the document library of a site in production, and then that site was re-promoted, the restore process would overwrite (destroy) those documents.

In situations where you must incrementally change an existing SharePoint site, you have only two options:

Write a custom installation script (build an installer)
Manually replicate the configuration changes

Build an Installer

Using the Windows SharePoint Services object model, you can write a script that can reliably update, replace, or delete portions of a SharePoint site. We recommend this approach, while tedious to prepare, because it enables you to test and repeat the process as you need.

When building a custom installer, you must handle web.config updates properly. Your installer should inspect the web.config file for necessary entries and add or update only those relating to your custom components as needed. Your installer should be a "good citizen" and not disrupt entries and adjustments made by other installers; it should also be robust enough to be unaffected by differences in ordering and placement of tags.

Manually Replicate the Configuration Changes

You should only use this approach as a last resort, likely as a means of deploying a change that has been prepared and carefully documented in the Fix environment and that you need to replicate in the production environment quickly. In this case the developer would open the site using FrontPage and make the required edits directly on the affected pages.

Refresh Development Environments from Production

If you use FrontPage to make changes to Windows SharePoint Services sites in the Production environment, it is a best practice to periodically use the same backup/restore approach that was described for promotion to copy the current configuration of the site back to the Developer Sandbox environment. This way your development team members can have a realistic environment in which to assess how their components and configuration changes work when applied to the production site.

Additionally, the Assembly Test/Integration and Fix environments should be reset to a backup of the Production environment prior to each promotion of changes. This serves two purposes.

You reset these test environments to a known baseline state.
You can test and confirm how your deployment process work in production.

Conclusion

Conducting team-based development of Windows SharePoint Services– and SharePoint Portal Server–based applications is complex and brings additional concerns beyond those in typical ASP.NET application development. With proper planning and coordination, you can establish a productive and functional environment that enables teams of developers to work together to deliver these solutions.