Absolutes: The Bane of Professional SharePoint Developers

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:

rsconnect.rsds

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!

Code-behind in InfoPath 2010 continues to use Visual Studio Tools for Applications (VSTA), which does not provide built-in source control capability. This makes multi-developer code-behind in InfoPath difficult because developers must choose between two compromised situations. Either they work on code that is stored by InfoPath in the same file location (which significantly limits the ability of more than one team member to work on a solution) or they follow the workaround that Philip Newman and Christopher Brotsos describe in the Microsoft InfoPath team blog article “Using TFS for Source Control in InfoPath 2010."

Although the workaround described in the blog is clever, it still requires a fair amount of local workstation configuration—including exporting the XSN from InfoPath Designer, manually removing the read-only attribute flag from the files in the XSN, and making sure that all developers map their local workspace to an identical absolute path on their file systems. This last dependency is a direct result of having to rely on absolute paths in the InfoPath configuration settings.

Another option is to stay away from InfoPath code-behind whenever possible and to do what you can by using the rules engine that is built into the interface. I first heard this advice from a well-known and well-respected SharePoint developer when I first faced the frustrating multi-developer code-behind experience in InfoPath 2010. Initially, I thought this was a cop-out. But after having to work with InfoPath 2010 extensively on my team’s current project, I consider this good advice. Sure, there are times when you won’t be able to avoid using InfoPath 2010 code-behind. But keep in mind that on a professional, multi-developer software project, you will face code maintenance and code promotion challenges with InfoPath 2010.

If you are fortunate enough not to require InfoPath code-behind to meet your user’s requirements, but you have to promote your InfoPath forms from one environment to the next (i.e., from a development farm to a test farm), you’ll be faced with deployment challenges. The InfoPath 2010 Quick Publish feature is a significant improvement over the InfoPath 2007 publishing experience. In this improved model, you can publish forms to the Item folder below an InfoPath-enabled SharePoint list. Unfortunately, there’s no way in InfoPath Designer to change the publish location of the form. The Manifest.xsf file in the InfoPath form XSN package uses absolute URLs for the list deployment location for the form (.xsn file) and for form services. Listing 2 shows what this looks like.

Assume that an InfoPath-enabled external list named Orders exists in a Customers site collection in each of your farm environments (DEV, QA, and PROD). In order to deploy your form that was created in development to the other two environments, you must unpack the XSN and update the manifest.xsf file before you publish the form anywhere else but in development. Because Microsoft doesn’t provide any tooling for this, Tomek Stojecki and I described how to automate and deploy these updates by using PowerShell in “Speeding InfoPath 2010 Custom Form Deployment to External Lists."

Encouragement at the Core

SharePoint Foundation, unlike many of the tools and technologies that sit on top of it, is better designed for a professional development life cycle. It’s the core product that provides the framework for solution deployment and retraction and for feature activation and deactivation. Relative URLs are supported in other locations. For example, the URL property of the ListInstance element in an elements.xml file is associated with a list instance that you create.

Perhaps a good approach for the next version of SharePoint would be for the SharePoint Foundation team to verify that other Microsoft teams that are writing software to sit on top of SharePoint do two things: consider the professional development life cycle and stop relying on absolute URLs and file paths.

A Strategic Choice

One of the shortcomings of SharePoint is that it forces the professional developer to spend a lot of time and energy on reconfiguration and deployment. We’ve discussed only the deployment and configuration challenges that you might face by using two useful technologies in SharePoint Server 2010, in SQL Server 2008 R2 Reporting Services in SharePoint Integrated Mode, and in InfoPath 2010. But there are plenty of other examples.

Until Microsoft resolves these issues, you can employ other strategies. Determine whether there’s a way to facilitate code promotion through configuration. Try to avoid using SharePoint features that are not designed for a professional development life cycle. And for those times when you have no other choice, PowerShell is a good scripting platform that can help you overcome these challenges.

Listing 1: Modifying the DataSourceReference element in PowerShell

$xml = New-Object XML

# load the report file to be updated

$xml.Load("d:\bin\original.rdl")

 

# change the element to a different value

$xml.Report.DataSources.DataSource.DataSourceReference =

  "https://qc.contoso.com/sites/Customers/DataConnections/rsconnect.rsds"

 

# save the report file with a new name

$xml.Save("d:\bin\new.rdl")

Listing 2: Snippet of an InfoPath 2010 Manifest.xsf showing absolute URLs

Comments

Plain text