Adding a Visual Basic 6 project to a TFS 2010 Build

Adding a Visual Basic 6 project to your TFS 2010 build process is not are hard as I had expected it to be. I had assumed I would have to write a custom build workflow template, but it turned out I was able to use the default template with just a few parameters changed from their defaults. This is the process I followed.

I created a basic ‘Hello world’ VB6 application. I had previously made sure that my copy of VB6 (SP6) could connect to my TFS 2010 server using the Team Foundation Server MSSCCI Provider so was able to check this project into source control.

Next I created a MSbuild script capable building the VB project, as follows

<Project ToolsVersion\="4.0" DefaultTargets\="Default" xmlns\="http://schemas.microsoft.com/developer/msbuild/2003"\>

  <PropertyGroup\>

<TPath\>C:Program FilesMSBuildExtensionPack4.0MSBuild.ExtensionPack.tasks</TPath\>

    <TPath Condition\="Exists('C:Program Files (x86)MSBuildExtensionPack4.0MSBuild.ExtensionPack.tasks')"\>C:Program Files (x86)MSBuildExtensionPack4.0MSBuild.ExtensionPack.tasks </TPath\>

</PropertyGroup>

  <Import Project\="$(TPath)"/>
```

```
  <PropertyGroup\>

<VBPath\>C:Program FilesMicrosoft Visual StudioVB98VB6.exe</VBPath\>

    <VBPath Condition\="Exists('C:Program Files (x86)Microsoft Visual StudioVB98VB6.exe')"\>C:Program Files (x86)Microsoft Visual StudioVB98VB6.exe</VBPath\>

</PropertyGroup>

<ItemGroup>

    <ProjectsToBuild Include\="Project1.vbp"\>

  <OutDir\>$(OutDir)</OutDir\>

      <!-- Note the special use of ChgPropVBP metadata to change project properties at Build Time -->

  <ChgPropVBP\>RevisionVer=4;CompatibleMode="0"</ChgPropVBP\>

    </ProjectsToBuild\>

</ItemGroup>

  <Target Name\="Default"\>

<!-- Build a collection of VB6 projects -->

    <MSBuild.ExtensionPack.VisualStudio.VB6 TaskAction="Build" Projects="@(ProjectsToBuild)" VB6Path="$(VBPath)"/>

</Target>

<Target Name=“clean”>

    <Message Text\="Cleaning - this is where the deletes would go"/>
```

```
  </Target\>
```

```
</Project\>
```

This used the [MSBuildExtensions task](//msbuildextensionpack.codeplex.com) to call VB6 from MSBuild, this MSI needed to be installed on the PC being used for development. Points to note about this script are:

*   I wanted this build to work on both 32bit and 64bit machines so I had to check both the “Program Files” and “Program Files (x86)” directories, the Condition flag is useful for this (I could have used an environment variable as an alternative method).
*   The output directory is set to $(OutDir). This is a parameter that will be passed into the MSBuild process (and is in turn set to a Team Build variable by the workflow template so that the build system can find the built files and copy them to the TFS drop directory).

This MSBuild script file can be tested locally on a development PC using the MSBUILD.EXE from the .NET Framework directory. When I was happy with the build script, I stored it under source control in the same location as the VB project files (though any location in source control would have done)

The next step was to create a new Team Build using the default build template with a workspace containing my VB6 project.

The first thing to edit was the ‘Items to Build’. I deleted whatever was in the list (sorry can’t remember what was there by default). I then added the build.xml file I had just created and stored in source control

[![image](/wp-content/uploads/sites/2/historic/image_thumb_7D77D4F7.png "image")](/wp-content/uploads/sites/2/historic/image_4E09662B.png)

I then tried to run the build, this if course failed as I needed to install VB6 (SP6) and the [MSBuildExtensions](//msbuildextensionpack.codeplex.com) on the build server. Once this was done I tried the build again and it work. The only issue was I got a warning that there were no assemblies that Code Analysis could be run against. So I went into the build’s parameters and switched of code analysis and testing as these were not required on this build.

So the process of build ingVB6 on TFS 2010 turned out to much easier than I expect, it just goes to show how flexible the build system in TFS 2010 is. As long as you can express your build as an MSBUILD file it should just work.