Setting up TDS to work with Azure DevOps

We recently had the challenge of moving across a legacy project, that we inherited, to run on Azure DevOps.  This project is five or six years old and still leverages TDS for packaging Sitecore items.

Helpfully the code repository already had a copy of the nuget package contents checked in and referred to by the TDS project files, however this was designed to use an older version of visual studio (2015) than we had available as a part of the default Microsoft supplied build agent (2019).  In addition we needed to make sure the build agent was able to use our TDS license keys.

Setting up the TDS license

The old HedgeHog documentation has some good info on how to set up TDS to run on a build server.  This states to set up two environment variables: TDS_Owner and TDS_Key with the license information that the TDS tool will look for at runtime.

Our first attempt to follow this instruction for DevOps was to create a powershell task to set the variables

- task: PowerShell@2
  displayName: "Setup TDS env variables"
  inputs:
    targetType: 'inline'
    script: |
      [Environment]::SetEnvironmentVariable("TDS_Owner", "[Our Org]", [EnvironmentVariableTarget]::Machine)
      [Environment]::SetEnvironmentVariable("TDS_Key", "[Our Key]", [EnvironmentVariableTarget]::Machine)

This explicitly creates the variables and we can extract them again in s subsequent stage in the pipeline, to prove that they have been setup

  - task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      $owner = [Environment]::GetEnvironmentVariable("TDS_Owner", [EnvironmentVariableTarget]::Machine)
      $key = [Environment]::GetEnvironmentVariable("TDS_Key", [EnvironmentVariableTarget]::Machine)
      Write-Output "TDS_Owner: $owner"
      Write-Output "TDS_Key: $key"
	

This displays our variables back to us, however the TDS build step of the project still fails with error messages like this:

  ##[error]GENERATEPACKAGE(0,0): Error : Exception getting license. 'Can't find product key'
  	

This had us stumped for a while, until it twigged that Azure DevOps Pipeline Variables actually also get injected as environment variables. Plugging the TDS_Owner and TS_Key into the pipeline as variables worked! TDS picked up the environment variables created and built successfully!

Getting the TDS packages to build on a newer VS version

As mentioned above, the solution provided to us already have the NuGet package for TDS 5.7 extracted and stored in the source repository in a folder names \packages\HedgehogDevelopment.TDS.5.7.0.16.  

This was referenced by two lines in each and every TDS project file (*.scproj) within the solution:

<import condition="Exists('$(MSBuildExtensionsPath)\HedgehogDevelopment\SitecoreProject\v9.0\HedgehogDevelopment.SitecoreProject.targets')" project="$(MSBuildExtensionsPath)\HedgehogDevelopment\SitecoreProject\v9.0\HedgehogDevelopment.SitecoreProject.targets" />
<import condition="Exists('..\..\..\..\..\packages\HedgehogDevelopment.TDS.5.7.0.16\build\HedgehogDevelopment.TDS.targets')" project="..\..\..\..\..\packages\HedgehogDevelopment.TDS.5.7.0.16\build\HedgehogDevelopment.TDS.targets" />

The first of thise two directives refers to the location where the TDS tool installer deploys the TDS files on a local developer machine. The second one refers to NuGet package files that had been included in source control.

As the version of TDS we wanted to run was 6.0.2, we simply extracted the contents of the latest NuGet package for TDS and following the existing convention added it to the \packages\HedgehogDevelopment.TDS.6.0.2 folder. We then updated the project code in each TDS project (*.scproj) file to reference the targets file HedgehogDevelopment.SitecoreProject.targets.

  <Import Project="..\..\..\..\..\packages\HedgehogDevelopment.TDS.6.0.2\build\HedgehogDevelopment.SitecoreProject.targets" Condition="Exists('..\..\..\..\..\packages\HedgehogDevelopment.TDS.6.0.2\build\HedgehogDevelopment.SitecoreProject.targets')" />
  

In addition, we were able to simply remove the reference to the $(MSBuildExtensionsPath)\HedgehogDevelopment\SitecoreProject\v9.0\HedgehogDevelopment.SitecoreProject.targets file, as the solution was building fine locally using the NuGet package reference only.