Adding a Build Definition
- PDF for offline use:
Let us know how you feel about this.
We are now ready to bring everything together and have our Team Foundation Server build and test our Xamarin app whenever changes are checked into version control. For this we need to create a new Build Definition in our team project. Note that a team project can contain any number of build definitions for different purposes; the one we're creating here specifically serves the needs of continuous integration.
In Visual Studio, go to Team Explorer and click Builds:
In the pane that appears, click the New Build Definition link to open a new build definition tab in the main area of Visual Studio.
On the General tab enter Build and Test All for the Build definition name along with an appropriate description:
Click the Trigger tab next and select Continuous Integration – Build each check-in. This runs the build definition every time any developer checks code into the team project:
Notice that there are two additional options you can use. Rolling builds will combine check-ins is a build is already running instead of queuing a new build for each individual check-in. The Gated Check-in option instructs TFS to run a build and tests before the check-in is actually accepted. If the build or any test fails, the check-in will be rejected, which guarantees that no checked-in code would break the build. With the Continuous Integration option that we're using here, code is always checked into version control first; failed builds or tests are then reported and logged as bugs to the responsible developer.
On the Source Settings tab, right-click the line with the folder $/, and select Delete. Otherwise you'll get warnings during the build.
For the purpose of this walkthrough we’ll not need any output binaries from the automated build, so select the Build Defaults tab and select This build does not copy output files to a drop folder. In a production scenario, you might typically place the build binaries or packages on a shared drop folder from which the app could be side-loaded for manual testing.
Select the Process tab and click the … button under Build > Configurations:
In the Configurations to Build dialog that appears, click Add, select Release for the Configuration, select Mixed Platforms for the Platform, then click OK:
If you needed to move the Android SDK as instructed in Configuring the TFS Server to Build Android Apps, expand expand 5. Advanced in the build definition and add /p:AndroidSdkDirectory=c:\android-sdk to the MSBuildArguments setting (changing c:\android-sdk to wherever you moved the Android SDK). If you did not need to move the Android SDK (e.g. you installed it with Visual Studio 2015), leave this field blank.
Select the dropdown for 5. Advanced > MSBuild platform and select X86 so that the TFS server can build for Windows Phone:
To run unit tests after the automated build completes, click … by the Automated Tests entry, which brings up the Automated Test dialog box:
Select the first test shown and click Edit…. In the next dialog, enter Backend Tests for the Name, check Fail build on test failure, ensure Visual Studio Test Runner is selected for Test runner, finally select Enable Code Coverage for Options:
Click OK to return to the Automated Tests dialog, which should appear as below. Click OK again to close.
Save the build definition, which adds it to the list of available builds in the Team Explorer pane:
Testing the Build Definition
Everything is now in place to test continuous integration with TFS:
- In Visual Studio, right-click the TaskyPortable solution in Solution Explorer and select Check-In…. This will switch to the Team Explorer panel. Enter Added Unit Testing and Automated build for the comment and click Check In.
Checking in code will automatically kick-off the build definition that we created earlier. To see the results of the build, click the Home icon in Team Explorer and click Builds:
To see the results of the build, double click the Build and Test All entry under My Builds. This will show current status as the build progresses, and then the results of the build and its unit tests when everything is complete:
And with that, we've connected out Xamarin solution to a TFS team project and successfully configured continuous integration to run builds and tests with every check-in!
Troubleshooting Build Failures
Error message about a missing Android SDK
This indicates that the TFS build account still cannot find the Android SDK. Double-check the locations to which you moved the SDK and NDK, the environment variables you configured, and the /p:AndroidSDKDirectory setting in the build definition.
Error message about Android API level
This indicates that there is a mismatch between the expected API level of the project and the SDKs that are installed on the TFS machine. With the project opened in Visual Studio, right-click the TaskyAndroid project and select Properties. Under the Application tab, check the setting under Compile using Android version. Then go to the TFS machine, open Visual Studio, and select the Tools > Android > Android SDK Manager...". From here you can install SDKs for specific API levels.
Errors about missing components
Double-check that you added the two DLLs in the Dependencies folder of the TaskyPortable sample to the TaskyPortable solution before adding the solution to version control. Without these DLLs in version control, the TFS machine will not have them available during a build.
Tests don't run accompanied by an error message about Microsoft.VisualStudio.TestPlatform.Utilities
This indicates a mismatch between the versions of Visual Studio that are installed on the developer machines and the TFS machine. For example, if the TFS machine has Visual Studio 2015 installed, but a developer machine is using Visual Studio 2013, the solution will be looking for the 12.0 version of this assembly but the server has only the 14.0 version. To solve this, make sure the Visual Studio versions match, or make sure that the TFS machine has both Visual Studio 2013 and 2015 installed if developer machines have mixed versions.
Test run failure
If the build fails because of failed tests, double-check the unit tests that we added to the TaskyPortable project.