Porting a SharePoint 2007 WSPBuilder Solution to SharePoint 2010 — Part 2
Clavin Fernandes
In part of 2 of our series about porting a SharePoint 2007 based WSPBuilder project to SharePoint 2010 we discuss the changes made to our Visual Studio 2008 based project to support both versions of SharePoint
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.
The following posts are part of this series:
-
Part 1 – Introduction / Problems installing the existing 2007 version on SP2010
-
Part 2 – Reconfiguring the Visual Studio Solution (This post)
WSP Builder
On January 13 a new ‘2010’ compatible version of WSPBuilder was released. I seriously doubt this new version is required in order to build SharePoint 2010 compatible solutions, but we upgraded to it nevertheless.
Note that if you want to use WSPBuilder to build a hybrid SharePoint 2007 / 2010 solution or a solution that just targets SharePoint 2007 then you must perform the build on a machine that runs SharePoint 2007. The latest version of WSPBuilder checks which version of SharePoint is installed on the build machine and adds SharePoint 2010 specific elements to the generated WSP file, causing deployments to fail in SharePoint 2007 environments.
Unfortunately it does not seem to be possible to modify this behaviour using a command line switch.
Visual Studio Project structure
Depending on the complexity of your project, and on the need to add any SharePoint 2010 specific functionality, you may not need to make any changes to your project structure.
However, in our case we decided to make the following changes:
-
We renamed the 12 folder to SPHive. From a functional perspective there is no need to make this change, however it provides our developers with a more consistent experience as, depending on the platform they are targeting, the files may go to either the 12 or 14 hive.
-
A separate shadow SPHive_2010 folder was created to store SharePoint 2010 specific copies of files that will break compatibility when deployed to SharePoint 2007. For example element files that contain Custom Actions that target the SharePoint 2010 specific Ribbon will prevent a WSP file from deploying to SharePoint 2007. Application pages that contain the DynamicMasterPageFile attribute will break compatibility as well.
When a build is carried out the two SPHive folders are merged and 2 separate WSP files are created. For details see the next section.
Post Build event
Although the WSPBuilder Extensions for Visual Studio are great, our projects don’t use them. Instead our main project’s Post Build event invokes either WSPBuilder manually to generate WSP files or carries out a deployment using XCOPY.
As part of this exercise we have made the following changes:
-
Auto detect the installed version of SharePoint.
-
Determine the location of the SharePoint root directory (12 or 14 Hive).
-
Added support for generating both SharePoint 2007 and 2010 WSP files when doing a release build.
-
Added the ability to carry out an XCOPY deployment of a merged version of the SPHive and SPHive_2010 folders..
A simplified copy of our PDF Converter’s post build event is included below. As all our development servers run the 64 bit version of Win2K8 or Win2K8R2 this script may not work on Win2K3 or 32 bit installations. Some long lines, especially those invoking WSPBuilder, have been wrapped and reformatted for readability. When copying this script please make sure that multi-line commands are all placed on a single line.
set useWSPBuilder=false set gacutil="$(SolutionDir)..\..\SharedBinaries\GACUtil\gacutil.exe" set wspbuilder="$(SolutionDir)..\..\SharedBinaries\WSPBuilder\wspbuilder.exe" set SPHive_2010=$(ProjectDir)SPHive_2010 @echo ** Detect which version of SharePoint is installed. set CommonProgramsFolder=%CommonProgramW6432% set SharePointRoot=%CommonProgramsFolder%\Microsoft Shared\Web Server Extensions\14 set IsSP2010=true if exist "%SharePointRoot%\bin\STSADM.EXE" goto endVersionDetection set SharePointRoot=%CommonProgramsFolder%\Microsoft Shared\Web Server Extensions\12 set IsSP2010=false if exist "%SharePointRoot%\bin\STSADM.EXE" goto endVersionDetection echo ** SharePoint does not appear to be installed on this server. goto end :endVersionDetection echo Detected SharePoint Root: "%SharePointRoot%" if $(ConfigurationName)==Debug goto debugMode @echo ** Not running in debug mode so enabling WSPBuilder set useWSPBuilder=true :debugMode @REM Do we want to build using XCopy or WSPBuilder? if %useWSPBuilder%==false goto useXCopy @echo ** Build mode: WSP Builder @echo ** Remove files from the WSPBuilder GAC Directory del /F /Q "$(ProjectDir)GAC\*.*" @echo ** Move dependent DLLs to GAC directory to allow WSPBuilder to package them up move /y "$(TargetDir)Muhimbi.SharePoint.Common.dll" "$(ProjectDir)GAC" move /y "$(TargetDir)Muhimbi.SharePoint.Diagnostics.dll" "$(ProjectDir)GAC" move /y "$(TargetDir)Muhimbi.Licensing.Base.dll" "$(ProjectDir)GAC" move /y "$(TargetDir)Muhimbi.Licensing.Validator.dll" "$(ProjectDir)GAC" move /y "$(TargetDir)Muhimbi.Licensing.SharePoint.dll" "$(ProjectDir)GAC" @echo ** Building WSP for SharePoint 2007 %wspbuilder% -BuildDDF True -BuildWSP true -ResetWebServer False -Outputpath "$(ProjectDir)Solution" -12Path "$(ProjectDir)SPHive" -GACPath "$(ProjectDir)GAC" -ProjectPath "$(ProjectDir)" -Cleanup True -Excludefiletypes "cmd,cs,scc" -WSPName Muhimbi.PDFConverter.wsp -BuildSafeControls False @echo ** Building SPHive for SharePoint 2010 set SPHive_Temp=$(ProjectDir)_SPHive_Temp rm -f -r "%SPHive_Temp%" md "%SPHive_Temp%" xcopy /E /Y "$(ProjectDir)SPHive" "%SPHive_Temp%" xcopy /E /Y "%SPHive_2010%" "%SPHive_Temp%" %wspbuilder% -BuildDDF True -BuildWSP true -ResetWebServer False -Outputpath "$(ProjectDir)Solution" -12Path "%SPHive_Temp%" -GACPath "$(ProjectDir)GAC" -ProjectPath "$(ProjectDir)" -Cleanup True -Excludefiletypes "cmd,cs,scc" -WSPName Muhimbi.PDFConverter.SP2010.wsp -BuildSafeControls False @echo ** Cleaning up rm -f -r "%SPHive_Temp%" del /F /Q "$(ProjectDir)Solution\makecab.ddf" goto end :useXCopy @echo ** Build mode: XCOPY xcopy /E /Y "$(ProjectDir)SPHive" "%SharePointRoot%" if %IsSP2010%==false goto skipSP2010Copy @echo Copying SharePoint 2010 specific files xcopy /E /Y "%SPHive_2010%" "%SharePointRoot%" :skipSP2010Copy @echo ** Installing GAC assemblies %gacutil% /if "$(TargetDir)Muhimbi.SharePoint.Common.dll" %gacutil% /if "$(TargetDir)Muhimbi.SharePoint.Diagnostics.dll" %gacutil% /if "$(TargetDir)Muhimbi.Licensing.Base.dll" %gacutil% /if "$(TargetDir)Muhimbi.Licensing.Validator.dll" %gacutil% /if "$(TargetDir)Muhimbi.Licensing.SharePoint.dll" @echo ** Installing $(OutDir)$(TargetFileName) into the GAC... %gacutil% /if "$(TargetPath)" echo ** Recycling App Pools cscript //NoLogo "$(SolutionDir)\RecycleAppPools.vbs" :end @echo ** rebuilding sitemaps and translations "%SharePointRoot%\bin\STSADM.EXE" -o copyappbincontent
The vbscript file that we use to recycle the application pools at the end of the build process was not working on our SharePoint 2010 development machine for some reason. We are not sure if this is related to the fact that we migrated to Win2K8R2 (from Win2K8) as part of the SharePoint 2010 deployment process or if it is because the script was always broken. Basically it fell over if one of the Application Pools was not started.
The new script is now as follows:
Set oWebAdmin = GetObject("winmgmts:root\WebAdministration")
Set oAppPools = oWebAdmin.InstancesOf("ApplicationPool")
For Each oAppPool In oAppPools
WScript.Echo "Recycling application pool: " & oAppPool.Name
'** Only recycle pools that are currently started
if oAppPool.GetState = 1 then
oAppPool.Recycle
end if
NextContinue to Part 3 – Programmatic / visual changes.
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.
