Recently a friend of mine was working on creating a Document Management portal.
That is, he was using SharePoint as the user interface, and was populating the pages with web parts that would allow the user to interact with a back-end document management system.
He had built up the Portal using SharePoint 2007, and had created several sub-sites that contain web parts that were relevant to the requirements of specific groups of users. He had run some informal testing and had confirmed that the web parts were offering the business users the functionality that they required. He had also spent some time on the design of each page. He was using a standard master page so that each sub-site had the same look and feel, but had made small tweaks to each page so that the presentation of the web parts was optimal.
Then he wanted to move the system to a SharePoint 2010 system. Fortunately the Portal site was not yet in use, and nothing extra, or unknown, had been done to the sites, so was pretty sure there wasn’t any customization. However he wasn’t sure what the best way to get his Portal from 2007 to 2010. So he called me.
We had a look at the options:
- In-place upgrade,
- Database Attach
- Build the site from scratch.
SharePoint 2010 had already been installed on a new, suitably spec’d server, so an in-place upgrade was not an option.
We examined the database attach method. This would involve making a backup of the 2007 content database, restoring it in the new SQL Server installation on the the new server, This sounded like a good option. The only thing we were worried about was the third-party we parts (the ones that hooked into the third-part document management system). We weren’t quite sure how these were going to respond.
We considered the third option – building the site from scratch on SP2010. This also introduced new challenges. Could we migrate the default. master from 2007 to 2010? I knew that 2010 didn’t use default.master, but now used v4.master. What impact would that have? We also had the ribbon to contend with, as well as the “Tags & Notes”, and “I like it” buttons. (The sites were meant to be static, offering only the ability of users to work with their documents. It was not meant to be a “social” site.)
One other benefit of an in-place, or database attach upgrade, was the fact that SharePoint 2010 offered a “Visual Upgrade”. That is, the 2007 look and feel is maintained, and there was the ability to “preview” how the sites would look in 2010. Once you were happy with them, you could make the changes permanent.
This would have been nice, but, because of the fact that we wanted to make sure that we could document how the Portal was built up, we decided that option 3 would be the best option.
So – the decision was made. The first step was to install the third-party web parts. And this is where it got interesting. We were using the latest version of these web parts that were SharePoint 2010 compatible, so we thought there would be no problem.
Except there was one small thing…
The third-party web parts were designed to use WSE. WSE, or Web Services Enhancements, is an add-on to the .NET framework that offers improvements to security and communication. It was released in 2005. The SharePoint server had been installed by another department according to a “standard”, and this included WCF, or Windows Communication Foundation. WCF was brought out as the “next-generation web service/interoperability framework”.
So here was the question: Do we get the department that installed the SharePoint server to uninstall WCF, and install WSE? Or do we ask the vendor to test, and certify that their web part technology will work with WCF?
Removing WCF and installing WSE would have very little impact to the overall scheme of things (the server was not being used for anything else), BUT it would mean a non standard installation.
On the other hand, the vendor has stated that their application was compatible with SP2010, and one would assume that it would be designed to use the newer WCF component.
Currently the discussion is going back and forth between the two options.
One thing though, this small compatibility issue wouldn’t have become quite so obvious if we had not decided to build up the Portal from scratch.
- Determine upgrade approach (SharePoint Server 2010)
- Interoperability between WCF and WSE 3.0
- What’s New in WSE Version 3.0
- What Is Windows Communication Foundation