Porting a SharePoint 2007 WSPBuilder solution to SharePoint 2010 – Part 2

Posted at: 15:11 on 12 March 2010 by Muhimbi

SharePoint2010

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:

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

VS2008-ProjectsDepending 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:

  1. 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.
     
  2. 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:

  1. Auto detect the installed version of SharePoint.
  2. Determine the location of the SharePoint root directory (12 or 14 Hive).
  3. Added support for generating both SharePoint 2007 and 2010 WSP files when doing a release build.
  4. 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
Next

 

 

Continue to Part 3 – Programmatic / visual changes.

.






Labels: , , , , ,

6 Comments:

  • Hi Jeroen,

    The vbscript was always broken.

    Brett

    By Anonymous Anonymous, At 15 March, 2010 00:11  

  • Hi Jeroen,

    On IIS 7 and above try using AppCmd directly in the Post Build step:

    %systemroot%\system32\inetsrv\APPCMD recycle apppool "AppPoolNameHere"

    Regards
    Graham Jest

    By Anonymous Anonymous, At 28 June, 2010 14:40  

  • Good one, thanks Graham.

    By Blogger Muhimbi, At 28 June, 2010 14:44  

  • Thanks for that blog!!!
    But I have a question. You handle both versions (2007 and 2010) in one Project - great, that's what I want too. How you handel the reference to the sharepoint.dll?
    Do you use the the old one (12) to avoid compatibily issues. or you use the new one (14) to be able to use all the new Sharepoint-API-stuff?

    By Anonymous Holger, At 27 October, 2010 15:27  

  • We use the old DLL (SP2007), which is located in our 'shared binaries' directory. See the Muhimbi SharePoint Development Guidelines for the TFS structure at http://blog.muhimbi.com/2009/05/muhimbis-sharepoint-development.html

    I personally try to prevent touching the SP2010 specific methods and properties as that stops the software from working in 2007. In some rare places I actually use reflection to reach some of the SP2010 specific functionality.

    If you have a lot of that then you could put all SP2010 specific logic in a separate project with associated reference to the SP2010 DLL.

    By Blogger Muhimbi, At 27 October, 2010 15:38  

  • actually i was looking for WSP builder usage in sharepoint 2007

    By Anonymous sudeer, At 10 May, 2011 07:45  

Post a Comment

Subscribe to Post Comments [Atom]

Subscribe to News feed

Headlines
Archives