Although SharePoint 2010 has brought welcome improvements for the professional developer, many of the important tools and technologies that run on top of SharePoint can hamper your efforts to fully implement a professional development life cycle. Fundamental aspects of this life cycle include source control and the promotion of code and artifacts.
Code and artifact promotion is the process of moving your software and associated artifacts, such as web pages and Cascading Style Sheets (CSS), from one SharePoint environment to the next as software solutions evolve. For example, you might create code and artifacts in a development environment, promote it to a quality assurance environment for testing, and finally move it to production. In this article, I’ll refer to these environments as DEV, QA, and PROD.
For scheduled or continuous build efforts, it's critical that you employ a source control system, such as Microsoft Visual Studio Team Foundation Server (TFS) or Subversion, to make sure that your code is stored in a centralized location that is regularly maintained. Source control also provides a safe method for multiple developers to work on the code concurrently.
I’ll describe these deployment and configuration challenges in more detail, and look at ways to deal with those challenges.
Reporting Services Targets
Reporting Services in SharePoint Integrated mode has been available since SharePoint 2007. As the name suggests, this feature integrates Reporting Services with SharePoint by leveraging SharePoint infrastructure components, including content types and libraries, to define and store report artifacts, such as report files and data connection files. Reports are then rendered in the SharePoint interface instead of in the native Reporting Services interface. The Reporting Services team did a great job of simplifying the deployment of Reporting Services in SharePoint Integrated mode in Microsoft SQL Server 2008 R2.
Depending on the SharePoint features that you’ve activated in a particular web site, SharePoint can include data connection library and report library list definitions that you can use to create list instances for report artifact storage. To make this happen, you simply create the list instances and configure the libraries by using the appropriate content types. For example, you can add Report Server content types to a report library and the Report Data Source content type to a data connections library. This approach lets you keep your Reporting Services shared data sources—such as the PerformancePoint Data Source and Office Data Connection File content types—aggregated in one library.
This makes pretty good sense, right? Unfortunately, the model falls apart from the perspective of report artifact promotion. The reason this happens is that each Reporting Services report file (.rdl) contains one or more DataSourceReference elements, which define the path to a shared data connection file. The problem with this situation is that the defined path must be an absolute URL when it references another SharePoint library.
For example, assume that you’re working with the three SharePoint environments I outlined earlier: DEV, QA, and PROD. These sites are represented as dev.contoso.com, qa.contoso.com, and prod.contoso.com. In addition, assume that you’ve created a data connection library that’s located in the same relative location in all three environments. This library is represented as /sites/Customers/DataConnections. You named your data connection file rsconnect.rsds, then uploaded and configured each file in its respective library.
Figure 1: An absolute URL appearing in InfoPath Designer
In this scenario, a valid data source reference for each library will be the absolute URL to the data connection file. In the sample environment, therefore, the paths are as follows:
- DEV: dev.contoso.com/sites/Customers/DataConnections/rsconnect.rsds
- QA: qa.contoso.com/sites/Customers/DataConnections/rsconnect.rsds
- PROD: prod.contoso.com/sites/Customers/DataConnections/rsconnect.rsds
However, as we’ve already discussed, relative paths to the connection file will fail, and Reporting Services will throw an rsInvalidDataSourceReference exception.
I'm hopeful that future versions of Reporting Services in SharePoint Integrated mode will support relative paths to data connection files. In the meantime, there are two possible approaches for dealing with this issue as you try to promote reports from one environment to the next. The easy solution for using shared datasource files is to put the connection files in the report library that contains the other report artifacts. When you do this, you can simply refer to the data connection files and not have to include a path in the DataSourceReference element. In our example, then, the element for one shared data connection file would resemble the following:
<DataSourceReference>rsconnect.rsds</DataSourceReference>
The other solution is to continue using a separate data connection library, and modify the value of the DataSourceReference element in the XML, either manually or through a scripting language such as PowerShell. Listing 1 shows a simplified script for doing this. The script should be augmented by error handling and passing in parameters, such as the report file to modify, the report file to create, and the data connection value for the new report file.
InfoPath Targets
As Microsoft touts, the form design experience in InfoPath 2010 is significantly improved over the one in InfoPath 2007. What hasn't improved much is the code-behind and multi-environment deployment experience. If you deploy InfoPath forms to a single farm, if you’re not concerned about having an integrated source control experience for your forms and code development work, and if you’re the sole developer on an InfoPath 2010 project, the development and deployment experience is fine. But if this doesn’t fit your development profile, read on!