Question

I have a nightly script that should build Debug and Release zip files then upload these via ftp to the client.

Ive always used AfterDropBuild for deployment of a single configuration – which works fine – but building both config’s in a single build doesn’t seem to work. I was hoping that AfterDropBuild would execute twice. I can of course code the tasks in AfterDropBuild to handle both configs but this doesnt feel right.

Is there a better way?

<Target Name="AfterDropBuild">
    <CreateProperty Value="$(DropLocation)\ToClient">
      <Output PropertyName="DeploymentFolder" TaskParameter="Value" />
    </CreateProperty>
    <GetBuildProperties TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)">
      <Output TaskParameter="BuildNumber" PropertyName="BuildNumber"></Output>
    </GetBuildProperties>
    <CreateProperty Value="%(ConfigurationToBuild.FlavorToBuild)">
      <Output PropertyName="ConfigFlavor" TaskParameter="Value" />
    </CreateProperty>

    <MakeDir Directories="$(DeploymentFolder)" />

    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
               BuildUri="$(BuildUri)" Name="ZipSite"
               Message="Zipping Site">
      <Output TaskParameter="Id" PropertyName="ZipStepID" />
    </BuildStep>
    <!-- get a list of all the files in the published web sites -->
    <CreateItem Include="$(OutDir)_PublishedWebSites\Site.Web\**\*.*"  >
      <Output TaskParameter="Include" ItemName="FilesToZip"/>
    </CreateItem>
    <CreateItem Include="$(OutDir)\Site.msi" >
      <Output TaskParameter="Include" ItemName="FilesToZip"/>
    </CreateItem>

    <!-- zip the deployment files -->
    <Zip Files="@(FilesToZip)"
         ZipFileName="$(DeploymentFolder)\Site_$(BuildNumber)_$(ConfigFlavor).zip"
         WorkingDirectory="$(OutDir)_PublishedWebSites\Site.Web" />

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

    <!-- upload the zip -->
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
               BuildUri="$(BuildUri)" Name="UploadZip"
               Message="Uploading Zip to Client">
      <Output TaskParameter="Id" PropertyName="ZipUploadID" />
    </BuildStep>

    <CreateItem Include="$(DeploymentFolder)\*.zip" >
      <Output TaskParameter="Include" ItemName="FilesToUpload" />
    </CreateItem>

    <FtpUpload
      RemoteUri="ftp://ftp.blahblah.com/"
      LocalFiles="@(FilesToUpload)"
      RemoteFiles="@(FilesToUpload->'%(RecursiveDir)%(Filename)%(Extension)')"
      UserName="user"
      Password="password"
      />
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
           BuildUri="$(BuildUri)" Id="$(ZipUploadID)" Status="Succeeded" />
  </Target>

Thanks

Answer 1

You can add as many configurations as you like to the SolutionsToBuild (e.g. we build several separate library solutions and then two different applications that are built from the same source code (one solution) but built from two configurations using a #define to alter the output code)

You only get called once when the build completes, but that handler can then run as many processes/steps as needed to deploy the results (in our case, we build the two compiled applications plus a load of resource files into 10 different customer-specific installers, so there are 10 “steps” to our post-build, each producing another final output).

You can place the commands to build each of these final results into its own target so it’s really easy to include/exclude different results from the build if you need to chop and change things regularly – but chances are that once it’s set up you won’t need to change it often anyway. Then the only “special case” code that has to know about the fact that all these variants are built wil be the post-build target, which will simply depend on any targets you need. So it ends up quite tidy.