John W Powell : TFS

A Simple Build Script for Packaging Visual Studio Extensions for Windows SharePoint Services (VSEWSS 1.3) Projects with Team Build

johnwpowell — Sun, 16 Aug 2009 16:24:00 GMT

In a previous post, I provided a walkthrough for automating builds for VSEWSS 1.3 projects. The script I used was based on the SharePoint Guidance Drop 11, and after using it, I felt it could be simplified. I’m a proponent of implementing the “simplest possible thing that will work,” and the following build script contains the minimal functionality needed to automate the building and packaging of your SharePoint solutions.

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />

  <ProjectExtensions>
    <ProjectFileVersion>2</ProjectFileVersion>
  </ProjectExtensions>

  <PropertyGroup>
    <RunTest>false</RunTest>
    <RunCodeAnalysis>Never</RunCodeAnalysis>
    <SkipWorkItemCreation>true</SkipWorkItemCreation>
  </PropertyGroup>

  <PropertyGroup>
    <ContosoSolutionDir>c:\NightlyBuild\main\</ContosoSolutionDir>
    <ContosoSolutionName>Contoso.sln</ContosoSolutionName>
    <ContosoWSPName>Contoso.Deployment.wsp</ContosoWSPName>
    <ContosoDeploymentProjDir>c:\NightlyBuild\main\Contoso.Deployment\</ContosoDeploymentProjDir>
    <IDEPath>C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\</IDEPath>
  </PropertyGroup>
  
  <ItemGroup>
    <SolutionToBuild Include="$(BuildProjectFolderPath)/../../main/Contoso.sln">
    </SolutionToBuild>
  </ItemGroup>

  <ItemGroup>
    <ConfigurationToBuild Include="Debug|Any CPU">
      <FlavorToBuild>Debug</FlavorToBuild>
      <PlatformToBuild>Any CPU</PlatformToBuild>
    </ConfigurationToBuild>
  </ItemGroup>

  <Target Name="AfterCompile">
    
    <!-- The extensions modify files in the pkg directory, so those files cannot read only-->
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Making the pkg directory editable.">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>
    <Exec Command="attrib -R &quot;$(ContosoDeploymentProjDir)pkg\*.*&quot; /S /D" />
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Id="$(StepId)" Status="Succeeded" />

    <!-- Build using /package switch  -->
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Packaging wsp.">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>
    <Exec Command="&quot;$(IDEPath)devenv&quot; &quot;$(ContosoSolutionDir)$(ContosoSolutionName)&quot; /Deploy debug /Package" />
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Id="$(StepId)" Status="Succeeded" />

    <!-- Copy package to drop folder -->
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Copying wsp to drop folder.">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>
    <Copy SourceFiles="$(ContosoDeploymentProjDir)bin\debug\$(ContosoWSPName)" DestinationFolder="$(DropLocation)\$(BuildNumber)" />
    <Copy SourceFiles="$(ContosoDeploymentProjDir)bin\debug\setup.bat" DestinationFolder="$(DropLocation)\$(BuildNumber)" />
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Id="$(StepId)" Status="Succeeded" />

  </Target>
  
</Project>

Automate SharePoint Solution Builds with Visual Studio Extensions For Windows SharePoint Services (VSEWSS) 1.3

johnwpowell — Mon, 22 Jun 2009 00:55:00 GMT

In this walkthrough, I’ll demonstrate how to achieve automated builds and continuous integration by creating a build script for VSEWSS 1.3 solutions. The patterns and practices SharePoint Guidance (11 drop) contains an example build script that this article is based on, but I found some issues with it in practice that I’d like to share. Before we get started, I’d like to talk about the design of the extensions and some of the problems you may encounter with them.

VSEWSS 1.3 stores information used to build the wsp file in a directory named “pkg” that is not included in the project. This works fine for individual development on a single machine, but not so well for team development and build automation. The pkg directory must be manually included in the project so files needed to build the wsp are included in source control. If you forget to do this, your teammates won’t be able to build the wsp, and you risk losing deployment configuration. Furthermore, if you later add a new feature, you also have manually add the new feature subdirectory to the project. In addition to storing configuration information, the pkg directory is also where solution files (feature.xml for example) are automatically generated. When you package the wsp (or refresh in the wsp view), the files in the pkg directory must be checked out to be re-generated. This also causes problems on the build server because the files in the pkg directory are read-only because they are checked into source control. An improved design would be to store wsp configuration information in a folder/file that is part of the project and use the pkg directory only for generating packages based on the wsp configuration files. So now that you are aware of some of the team development “gotchas” with VSEWSS 1.3, I’ll show you, step-by-step, how to configure automated builds.

If you just want to see the build script, get it here. Update: get a simplified build script here.

If you have not installed TFS Build, you will need to install it using the TFS installation media. You will also need to configure a service account such as TFSBuild, and add the account to the TFS server group Team Foundation Licensed Users and the Team Project(s) group Build Services.

To get started, configure the build agent. In the team project select Builds > Manage Build Agents…

Enter the build agent properties for your build server

Create a new build definition by selecting Builds > New Build Definition…

Enter a name for the build definition

Configure the workspace. Note: all files in the source control folder will be downloaded to the local folder you specify, so be sure the location you specify has enough free space

Create the project file (TFSBuild.proj) by selecting the version control folder where you want it stored and selecting Create…

Select the Visual Studio solution to build and click Next

Select the configuration(s) to build and click Next

If you want to run unit tests or code analysis during the build, configure it and click Finish

Now that the project file is created, click OK

Configure how many builds you would like to retain and click OK. Note: you should at least keep the latest of failed or partially succeeded builds or the build log file you need to troubleshoot will be deleted

Enter a share where the build files will be dropped and click OK

Configure what triggers the build, either manually, on a schedule or when files are checked in (continuous integration)

Test the build by highlighting the build definition and selecting Queue New Build…

Click Queue

At this point you should have a working build, but it doesn’t package the wsp file yet

Next, we’ll modify the build script to package the wsp file. The build steps are as follows:

Clean up any workspaces / files left by the previous build packaging
Build the Visual Studio solution
Delete the workspace that was created by the build
Create a workspace for the wsp packaging build
Open a second instance of the IDE and package the solution using the /package switch
Copy the wsp to the drop folder

In addition to this process, a nice to have is to display the packaging steps in the GUI, so we’ll use the BuildStep task to accomplish that

To get started, get the latest version of the Team Build Types folder

Check out the TFSBuild.proj file. Note: when developing the build script, you will have to check it out to work on it, and check it back in to test it

Add the custom tasks used by the build. Although we could accomplish what we need to using TF commands, these tasks are installed with TFS and work well

<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

  <!-- These tasks are used by the Team Build process defined in this file -->
  <UsingTask TaskName="Microsoft.TeamFoundation.Build.Tasks.DeleteWorkspaceTask"
           AssemblyFile="$(TeamBuildRefPath)\Microsoft.TeamFoundation.Build.Tasks.VersionControl.dll" />
  <UsingTask TaskName="Microsoft.TeamFoundation.Build.Tasks.CreateWorkspaceTask"
             AssemblyFile="$(TeamBuildRefPath)\Microsoft.TeamFoundation.Build.Tasks.VersionControl.dll" />

Add the variables needed for wsp packaging. Note: there is probably a better way to determine the location of the IDE

  <PropertyGroup>

    <!--  
    Variables added for VSeWSS 1.3 builds 
    -->

    <!--  IDEPath
    The path in which DevEnv and TF reside 
    -->
    <IDEPath>C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE</IDEPath>

    <!-- TempWorkspaceName
    Workspace name, must not match an existing namespace name 
    -->
    <TempWorkspaceName>NightlyBuildTempWorkspace</TempWorkspaceName>
    
  </PropertyGroup>

Add the solution to build. Note: this will build the binaries, but will not generate the wsp file

  <ItemGroup>

    <SolutionToBuild Include="$(BuildProjectFolderPath)/../../Intranet/Intranet.sln">
        <Targets></Targets>
        <Properties></Properties>
    </SolutionToBuild>

  </ItemGroup>

Add the target to clean up any files left by the previous build packaging (if the previous build failed or was cancelled). This target is called during the build just before the workspace is created to build the solution

  <!-- Before the build workpace is initialized -->
  <Target Name="BeforeInitializeWorkspace" >

    <!-- Delete temporary workspace (if left by previous build) -->
    <BuildStep
        TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
        BuildUri="$(BuildUri)"
        Message="Deleting temporary workspace &quot;$(TempWorkspaceName)&quot; (if left by previous build).">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>

    <DeleteWorkspaceTask
          TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
          BuildUri="$(BuildUri)"
          Name="$(TempWorkspaceName)"
          DeleteLocalItems="true" />

    <DeleteWorkspaceTask
          TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
          BuildUri="$(BuildUri)"
          Name="$(TempWorkspaceName)"
          DeleteLocalItems="false" />

    <BuildStep
              TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
              BuildUri="$(BuildUri)"
              Id="$(StepId)"
              Status="Succeeded" />

    <!-- Error Occurred -->
    <OnError ExecuteTargets="MarkBuildStepAsFailed" />

  </Target>

Add the error handling target. If any of the other steps fail, they will call this target using ExecuteTargets

    <!-- Handles custom errors -->
  <Target Name="MarkBuildStepAsFailed">
    <BuildStep
        TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
        BuildUri="$(BuildUri)"
        Id="$(StepId)"
        Status="Failed" />
  </Target>

In the AfterCompile target, add the step to delete the workspace that was automatically created by the build

<!-- After the solutions are compiled -->
  <Target Name="AfterCompile" >

    <!-- Delete build workspace -->
    <BuildStep
            TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
            BuildUri="$(BuildUri)"
            Message="Deleting build workspace &quot;$(WorkspaceName)&quot;.">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>

    <DeleteWorkspaceTask
          TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
          BuildUri="$(BuildUri)"
          Name="$(WorkspaceName)"
          DeleteLocalItems="false" />

    <BuildStep
              TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
              BuildUri="$(BuildUri)"
              Id="$(StepId)"
              Status="Succeeded" />
    <!-- END Delete build workspace -->

Just below that, add the build step to create the temporary workspace

    <!-- Create temporary workspace -->
    <BuildStep
        TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
        BuildUri="$(BuildUri)"
        Message="Creating temporary workspace &quot;$(TempWorkspaceName)&quot;.">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>

    <CreateWorkspaceTask
          TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
          BuildUri="$(BuildUri)"
          BuildDirectory="$(BuildDirectory)"
          SourcesDirectory="$(SolutionRoot)"
          Name="$(TempWorkspaceName)"
          Comment="Temporary workspace">
    </CreateWorkspaceTask>

    <BuildStep
              TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
              BuildUri="$(BuildUri)"
              Id="$(StepId)"
              Status="Succeeded" />
    <!-- END Create temporary workspace -->

Add the step to package the solution. This first marks all files in the pkg directory as not read only--the packaging will not be able to overwrite these files otherwise. Then it runs the IDE and uses the /package switch to generate the wsp. Finally, it copies the wsp to the drop folder. If you had multiple wsp files to build, you could repeat the steps below or refactor into a target

    <!-- Place projects to package here -->

    <!--  Build and package solution -->
    <BuildStep
        TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
        BuildUri="$(BuildUri)"
        Message="Packaging &quot; Contoso Intranet solution&quot;.">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>

    <!-- The extensions modify files in the pkg directory, so those files cannot read only-->
    <Exec Command="attrib -R &quot;$(BuildDirectory)\Contoso\Intranet\Deployment\pkg\*.*&quot; /S /D" />

    <!-- Open a second instance of the dev environment and build using /package switch  -->
    <Exec Command="&quot;$(IDEPath)\devenv&quot; &quot;$(BuildDirectory)\Contoso\Intranet\Intranet.sln&quot; /deploy debug /package" />

    <!-- Copy to drop location -->
    <Exec Command="xcopy &quot;$(BuildDirectory)\Contoso\Intranet\Deployment\bin\debug\Contoso.Intranet.wsp&quot; &quot;$(DropLocation)\$(BuildNumber)\&quot; /E /Y /R" />

    <BuildStep
              TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
              BuildUri="$(BuildUri)"
              Id="$(StepId)"
              Status="Succeeded" />
    <!-- END Build and package solution -->

Add the build step to delete the temporary workspace we created

    <!-- Delete temporary workspace -->
    <BuildStep
        TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
        BuildUri="$(BuildUri)"
        Message="Deleting temporary workspace &quot;$(TempWorkspaceName)&quot;.">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>

    
    <DeleteWorkspaceTask
          TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
          BuildUri="$(BuildUri)"
          Name="$(TempWorkspaceName)"
          DeleteLocalItems="false" />

    <BuildStep
              TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
              BuildUri="$(BuildUri)"
              Id="$(StepId)"
              Status="Succeeded" />
    <!-- END Delete temporary workspace -->

Check the project back in to source control, and queue the build to test it

Team Explorer Window Won't Open Or Is Blank

johnwpowell — Mon, 05 May 2008 22:00:00 GMT

If recently worked with several developers that were unable to open the Team Explorer 2008 window (or if they did open it, the window was blank). They had pre-release versions of Visual Studio 2008 installed and despite following the instructions on uninstalling previous versions, were unsucessful. Having found the fix for this issue, I thought I'd share it in case anyone else encounters it.

Open a Visual Studio 2008 command prompt and run the following command:

devenv /setup

It will take awhile for this command to complete, but afterwards, the issue should be resolved. Here is documentation on the /setup switch if you would like to know more about it.

TFS AutoShelve: a utility to automatically shelve check outs to the TFS server

johnwpowell — Thu, 01 May 2008 19:32:00 GMT

Have you ever worked on a team where a developer went on vacation without checking in an important change? Ever known someone that kept a file checked out over multiple days (or weeks) and lost their work because of hard drive (or other) failure? Having seen the effect of such mishaps, I decided to implement a simple utility that will automatically shelve each developer's check outs to the Team Foundation Server.

If you are not familiar with shelving, it's a feature in TFS that will store pending changes on the server without checking them in. Shelving is very useful in many scenerios, but it is especially useful to me for prevention and insurance.

The utility is a dead simple console application that is configured to run as a log off script on each developer's computer. You could also configure it as a scheduled task. It connects to the TFS server, determines what the user has checked out on that computer and shelves the changes on the server. The full utility is available on CodePlex here, but I thought some of you might find it useful to see the essential shelving code.

string tfsServer = "tfs.contoso.com"; string shelfSetName = "AutoShelve"; // Connect to the Team Foundation Server TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(tfsServer); // Get the Version Control Server VersionControlServer vcs = (VersionControlServer)tfs.GetService(typeof(VersionControlServer)); // Get the list of workspaces for the current user Workspace[] workspaces = vcs.QueryWorkspaces( null, tfs.AuthenticatedUserName, null); // Enumerate each workspace and // determine if there are any pending changes foreach (Workspace ws in workspaces) { // You can only shelve what is on this computer! if (System.Environment.MachineName.ToUpper(CultureInfo.InvariantCulture) != ws.Computer.ToUpper(CultureInfo.InvariantCulture)) { // Continue to next workspace continue; } // Get the changes in this workspace PendingChange[] changes = ws.GetPendingChanges(); // If there are any pending changes, // shelve them if (changes.Length > 0) { // Create a shelveset Shelveset set = new Shelveset( vcs, shelfSetName, tfs.AuthenticatedUserName); // Shelve the changes ws.Shelve( set, changes, ShelvingOptions.Replace); } }

TFS AutoShelve is a very simple utlity that is quite powerful in practice--especially the first time it saves your backside.