Remember that TeamBuildTypes are VS2005 Solution centric. Fortunatly InstallShield comes with VS2005 and MSBuild integration right out of the box. When you add an InstallShield ( .ISM ) project to a VS2005 solution it automatically wires up a .ISPROJ file and some source control binding files.
The purpose of the .ISPROJ file is to teach the solution how to process the project using MSBuild. Using stanard VS2005 patterns such as Configuration Manager, TeamBuild simply builds the project completly unaware of the fact that it's using InstallShield to build one of the projects inside the solution.
In our previous article I mentioned the `LATEST` pattern. Since the binaries needed to be consumed into the Windows Installer database are in a seperate solution, we need to bring them into scope. We do that using MSBuild ItemCollections and CopyTasks like this:
<MySourceFiles Include="$(LATEST)\**\*.*" />
<Copy SourceFiles="@(MySourceFiles)" DestinationFiles="@(MySourceFiles->'$(SolutionRoot)\ProgramFilesFolder\MyCompanyName\MyProductName\\%(RecursiveDir)%(Filename)%(Extension)')"/>
So now the WorkspaceMappings.xml brings the InstallShield files into scope and this CopyFiles tasks gets us our binaries from the previous build output. The result is ( assuming proper Windows Installer design of the InstallShield Wizard ) is 100% ready to perform a minor upgrade of just those component keyfiles that were rebuilt and branded with a newer version number.
Obviously I've not provided an entire sample solution showing all of the integration points. Hopefully I've not overlooked any so feel free to leave a comment if your getting stuck wiring up your new TFS based incremental, versioned build automation.