vNext Build fails with error message ‘Cannot find solution’ because it does not exist.

Issue

Recently we have seen some cases where a vNext build, when queued, would fail with a message like below:

· Cannot find path ‘<build agent working folder>\<team project name>\path to solution> because it does not exist.

 ·        MSBUILD : error MSB1009: Project file does not exist.

 ·        Unexpected exit code received from msbuild.exe: 1

Also, the build logs would indicate an unusual behavior during the Get Sources step as below where workspace version is indicated as -1:

 ·        Done syncing repository Agile to version C71 (workspace version -1)

 whereas normally the message should look like:

 ·        Done syncing repository Agile to version C71 (workspace version C71)

Account used for Get operation during vNext build

Unlike xaml builds, vNext build doesn’t use the build service account to contact TFS to perform the Get.

The account used will depend on the ‘Build Job Authorization Scope’ set in the build definition. This can be found in the General tab of your vNext build definition.

· If this value is set to Current Project, ‘Project Build Service’ account will be used for the Get.

· If this is set to Project Collection, the ‘Project Collection Build Service’ account will be used.

By default both these accounts will have the necessary source control permissions.

Cause

We have identified this to be an issue which happens when the account that is used to do the Get operation doesn’t have sufficient permissions on source control to perform the Get.

· You can find the source control folder by opening up the vNext build definition and navigating to the Repository tab:

This mostly happens when you have inheritance broken for the source control folder which you have mapped to the build. To check this:

· Open TFS web access and navigate to the CODE tab.

· Browse to the source control folder which you have mapped to the build definition.

· Right-click on the folder and open up Security.

· Click on the ‘Inheritance’ drop down to check if Inheritance is Off.

Resolution

Breaking inheritance could be the reason why the accounts lost permission on source control. Turning On Inheritance would give the required permissions back to both Project Build Service and Project Collection Build Service accounts, and that should resolve the issue.

If you have a requirement to keep inheritance broken at source control, making sure either Project Build Service or Project Collection Build Service account (based on the scope selected in the build definition) has necessary permissions on the folder should also allow the build to get the files successfully.

Below snapshot indicates the default permissions assigned to both Project Build Service and Project Collection Build Service, on a source control folder at the team project level.

Hope this gets your builds going!

Content created by – Sreeraj Rajendran
Content reviewed by – Chandra Sekhar Viswanadha

Comments

• Anonymous
  December 21, 2016
  Thanks for sharing the above blog post. it really helped me. :) i was facing the same issue, now its resolved.