More than once while working with EasyRepro projects I’ve found myself in a situation where tests that were once working inexplicably stopped. After combing through code and verifying credentials I eventually figured out that references to one or more of the required Selenium components somehow got updated without my knowledge. An example of when this can be particularly frustrating is when the Chrome driver gets updated to the latest version which works with the always updated version of Chrome installed on my machine. Everything works fine when running tests locally. When deploying to Azure DevOps and running on an agent where an older version of Chrome is installed, everything fails because the latest driver doesn’t support older browser versions.

To avoid this issue I created a PowerShell script which will reset the Selenium component versions referenced in the project to what EasyRepro supports. Luckily this mismatch between driver and browser doesn’t seem to effect the opposite scenario of what I previously described, at least when Chrome is being used.

Older driver version + newer browser version = OK
New driver version + older browser version = NOT OK


When this runs it will update the packages.config file in the project and make sure that the versions listed at the beginning of the script match. If there is a mismatch it will also update any references in the project file. If this makes an update when the project is open in Visual Studio you’ll be prompted about a conflicting modification (because of the background update), go ahead and select Overwrite and everything should be good.

There are 2 ways of using the script.

Use during development

1. Add a folder name Tools to your test project and add to it this script and a copy NuGet.exe.
2. Open the .csproj for your project and add these lines:

<Target Name="FixEasyRepro" BeforeTargets="EnsureNuGetPackageBuildImports">
   <Exec Command="powershell.exe -NonInteractive -ExecutionPolicy Unrestricted Tools\FixEasyReproPackageReferences.ps1" />

This will execute the script prior to the automatic NuGet package restore which happens before the actual project build.

Use in Azure DevOps

The package restore and build process works a little different in Azure DevOps. The recommended approach is to use a NuGet build task to restore prior to executing the build task. The script will still run however the automatic package restore will not happen. If there was an update made you’d likely see a build failure because NuGet had already restored an incorrect package version. In order to maintain the modification to the project file so it works locally, add a PowerShell task which executes the script before the NuGet task runs. This will correct any mismatches so that the correct versions are restored. When the script re-runs during the build step, everything will already be correct and the build should complete.