Porting a SharePoint 2007 WSPBuilder Solution to SharePoint 2010 — Part 1
Clavin Fernandes
When we decided to make our popular PDF Converter for SharePoint compatible with SharePoint 2010, we had no idea what we were in for. Will it be a nightmare, will it just work, will we need to throw everything away?…. we simply didn’t know. Fortunately SharePoint 2010 is much like SharePoint 2007 and as a result we released the SharePoint 2010 compatible version earlier today.
As there is very little available information or guidance on this topic, we would like to share our experience with migrating SharePoint 2007 based WSPBuilder projects to SharePoint 2010 while maintaining a single code base that supports both environments.
This post, the first one in the series, describes what happened when we tried to install a SharePoint 2007 based solution on a machine running SharePoint 2010.
The following posts are part of this series:
-
Part 1 – Problems installing the existing 2007 version on SP2010 (this post)
Please note that this article is based on our experiences with the beta version of SharePoint 2010. Some of the issues we have identified may have been resolved in the final release.
Our goal
When we started the planning phase for the SharePoint 2010 migration, we decided that ideally we would end up with a single code base that can be used to build a single WSP file that is compatible with both SharePoint 2007 and 2010. To make the product easy to maintain we only want a single Visual Studio Solution and as little code duplication as possible. At the same time we wanted to leverage SharePoint 2010’s new facilities such as the Ribbon without breaking compatibility.
Although we had to give up our single WSP file dream, more on that later, we managed to achieve our other goals.
Installing a SharePoint 2007 based solution on SharePoint 2010
When we embarked on our migration project we briefly thought: what if it just works? That would have been great, but unfortunately we stumbled at the first hurdle, the installer.
The installer for the SharePoint WFE part of the solution is a simple cmd script that invokes stsadm directly. In SharePoint 2010 stsadm lives in a different directory from its SharePoint 2007 counterpart so our dream ended rather abruptly.
Once we had fixed the installer we stumbled onto a rather annoying problem that kept us busy for the better part of 2 days. Whenever we tried to deploy a WSP file (any WSP file it turned out) the process failed without any error messages. However, the following message was logged to the Windows Application Event log: Requested registry access is not allowed.
After consulting many sources, it turned out that if the first attempt to install SharePoint 2010 fails (ours did) then the privileges on the HKLM\SOFTWARE\Microsoft \Shared Tools\Web Server Extensions\14.0\Secure\FarmAdmin registry key are not configured during subsequent successful installations. After giving the Everyone group full control on this key it was finally possible to deploy WSP files. (I realise that giving Everyone access is not best practice, but it solved the problem on our development server).
For details about the changes we had to make to our deployment scripts see part 4 of this series.
Where are my menu options?
Once the wsp file was installed and deployed, the Convert to PDF option became visible in the ECB (file context menu), woohooo! Unfortunately, the link to our Central Administration based configuration screen was missing. Because the Central Administration screens have been restructured, the Locations recognised by SharePoint 2007 have no direct mapping to their SharePoint 2010 equivalents. It is a shame that SharePoint is not automatically remapping those Locations that have a direct equivalent in SharePoint 2010. After all, the External Service Connections Location is available in both versions.
Link to the PDF Converter Settings screen in SharePoint 2007
For details about the changes we had to make in order to make the menus work, see part 3 of this series.
Why does it all look wrong?
The main problems we encountered during this entire exercise were related to the visual fidelity of our Application screens. We take great pride in the appearance of our solutions so we were disappointed to see that, even though we have gone through great lengths to only use those user interface elements and controls that ship with SharePoint, things didn’t look quite right.
The main visual problems we encountered are as follows:
-
The vertical alignment of checkboxes is completely off.
-
There is extra vertical spacing between the various user interface elements.
-
Some elements, particularly buttons, have a different default width and therefore wrap over multiple lines.
The following screenshots provide a visual comparison between the SharePoint 2007 and 2010 versions before any changes were made.
Original SharePoint 2007 interface and the SharePoint 2010 one before making any changes
This concludes the overview of identified problems.
Continue to Part 2 – Reconfiguring the Visual Studio Solution.
Clavin is a Microsoft Business Applications MVP who supports 1,000+ high-level enterprise customers with challenges related to PDF conversion in combination with SharePoint on-premises Office 365, Azure, Nintex, K2, and Power Platform mostly no-code solutions.
