In Part 1 of this 2 part tutorial series on integrating Xamarin into a continuous build environment, I detailed how to use Jenkins to build Xamarin.iOS and Xamarin.Android projects and a Team Foundation Build server to build Windows Phone Projects. In Part 2, I’ll detail how you can take advantage of Microsoft’s new Build.vNext technology that is a part of Visual Studio Online (VSO) and Team Foundation Server (TFS) 2015.

The Shortcomings of Jenkins

While the method that I walked you through in Part 1 works fairly well, it does have a few shortcomings:

You need to configure your Xamarin.iOS/Xamarin.Android builds in a separate place from your Windows/Windows Phone builds: Now theoretically, you could set up a Jenkins server on Windows to build your Windows/Windows Phone projects, but you’d still be managing your builds from two different servers, even if they use the same UI. While you can’t get away from the need of having both a Windows and Mac build server, you can consolidate the location of the build definitions by using Build.vNext.
The Xamarin.iOS and Xamarin.Android builds aren’t uploaded as build artifacts to VSO/TFS: While the Windows/Windows Phone packages get uploaded to VSO/TFS by the Team Foundation Build server for easy retrieval, the Xamarin.iOS and Xamarin.Android packages do not. They stay on the Jenkins server and need to be retrieved from the workspace of the job that was built. Build.vNext allows you to upload these packages as build artifacts.
Service Hooks requires direct server access from VSO: If you’re using Visual Studio Online, to enable the Service Hooks functionality, you need to open ports to make the Jenkins server open to the internet so that VSO can connect to it. The Build.vNext build agents use NAT traversal so that opening ports isn’t required.
Jenkins doesn’t report the build results back to VSO/TFS: Jenkins does a good job at logging the results of each build, but it isn’t able to share that result back with VSO/TFS, so you need to log into the Jenkins server to see if a build succeeded or failed, whereas the Team Foundation build server does report the results back to VSO/TFS. Reporting the results back to VSO/TFS allows for features like ‘Gated Check In’ to work properly (preventing code that fails to build to be checked in) as well as for build results to be emailed out to team members who subscribe to those types of alerts. The Build.vNext build agents support all of this.

So just before I detail how to configure the Build.vNext system to build Xamarin solutions, I’ll just recap some of the assumptions and pre-requisites that were specified for Part 1.

Pre-requisites & Out of Scope Topics

Due to the complexity of this topic, there are some pre-requisites that I’m going to assume you already have knowledge about and already have installed and configured properly on your machine.

You have the latest version of Xamarin already installed and configured on your Windows and Mac machines. This includes all of the Xamarin pre-requisites that are included in the Xamarin installer (Java, MDK Framework, GTK# and Android SDK).
On your Mac, you have the latest version of XCode installed.
You have Visual Studio 2013 or 2015 installed on your Windows machine. The awesome thing about Visual Studio 2015 is that it can install Xamarin and all of it’s pre-requisites as part of the installation if you choose to do so (highly recommended). If you’re setting up a new Xamarin development environment, it makes sense to use Visual Studio 2015.
You have the latest Android SDK components installed. If you installed Xamarin, you can open the Android SDK Manager by either opening Visual Studio and choosing Tools -> Android -> Android SDK Manager or by opening Xamarin Studio and choosing Tools -> Android SDK Manager. The SDK Manager will tell you if there are updates available to the components you have installed.
You have a Xamarin solution that currently builds into a deployable app on the machine you want to turn into your build server. This means you’ve got your Provisioning Profiles and Development Certificates correctly configured for your Xamarin.iOS apps and your Java Keystore file created for your Xamarin.Android apps (or you’re using the sample solution, the sample Java Keystore file). For iOS apps, this means you’ll need to be a part of the Apple Developer Program.
You already have either a Visual Studio Online (VSO) account or a server running Team Foundation Server (TFS) 2015. You also have Administrator access to that account/server to make the configuration changes required.
For this Part of the tutorial series, you need a Team Project with the Git source control option chosen (as at the time of publication of this tutorial series, TFVC support for the cross platform build agent is getting very close to release).
This tutorial isn’t a tutorial on how to use Visual Studio Online or Team Foundation server as a source code repository. I assume you already know how to check in code and connect Visual Studio to VSO/TFS.
Finally, although testing is a critical part of continuous integration, this tutorial doesn’t cover this particular topic. I do plan to write a follow up tutorial at some point that will add testing to the continuous integration environment that you’ll be creating in this tutorial series.

Finally, this tutorial series has been written as an accompaniment to a talk I did at the Queensland C# Mobile Developers user group in Brisbane, Queensland, Australia in July 2015. You can watch the video from that talk here (apologies for the lack of screen capture, that didn’t save correctly this time).

Sample Solution

To give you a sample solution to work with for building these continuous integration environments, I’ve taken the TaskyPortable solution from the Xamarin Samples GitHub account, made some modifications and uploaded it to my GitHub account. So you just need to download this solution and check it in/commit it to your VSO or TFS Team Projects in order to use it.

I’ve also created a sample Java Keystore file that you can use alongside the sample solution. Java Keystore files are used for building Xamarin.Android projects. Don’t use this sample Java Keystore in production apps.

With this preamble out of the way, let’s configure a Build.vNext build environment!

Configuring Visual Studio Online For Builds (Pools & Alternative Credentials)

The first step in configuring Build.vNext is to log in and configure the agent pools. Agent pools allow you to have several build agents pooled together into a collection. When you create build definitions in VSO/TFS, you select which agent pool queue you want that build definition to use for builds and from there, VSO/TFS looks at for free agents in that pool that meet the demands of that build. This allows you to have different groups of build agents assigned to different types of builds. In this tutorial you’re just going to use the default pool that is created for you, but in a production scenario, you may have many different pools for different purposes.

There are two types of accounts groups associated with agent pools. The first type is the administrators account group. Being a member of this account group allows you to add, remove and configure agents in the pool. The second type of account group is called the ‘Service Account’ group. This account group lets you execute builds. So the first time you configure an agent, you log in using an account in the administrators account group to add the agent to the agent pool and then every other time after that, you log into that agent using an account from the service account group.

So to add your account to the appropriate groups needed to produce builds, follow the steps below.

1. Start by logging into VSO/TFS, clicking the settings icon in the top right hand corner and then clicking the Agent Pools tab.

2. In the left panel under the Agent Pools Permissions heading, click on Agent Pool Administrators. Then in the right panel, click Add... -> Add User

3. In the Add A User dialog, search for your user account and then click Save Changes. Your name will now appear in the list of Agent Pool Administrators.

4. In a production environment, you would create a separate user account that is not an Administrator that would act as your Service Account for your Agent Pool. In this tutorial though, from the left panel, click Agent Pool Service Accounts and then repeat the steps above to add your account as an Agent Pool Service Account.

This small section only applies if you’re using Visual Studio Online. For the Build.vNext cross platform build agent to work properly, like Jenkins, you’ll need to enable alternative credentials. Hopefully as the cross platform build agent is developed more, this requirement will be dropped. An on-premises Team Foundation Server uses IIS’ authentication instead and the cross platform build agent should be able to understand that.

1. Log into Visual Studio Online and then click your name in the top right hand corner and choose My Profile

2. Next, choose the Security tab and then the ‘Alternative authentication credentials’ item from the left panel.

3. Tick the ‘Enable alternative authentication credentials’ option and then enter a secondary username and password into the appropriate fields. Then click Save.

Configuring The Windows Build Agent

The Build Agent is an application that runs on your build server and listens for builds from VSO/TFS. When it receives a build, it executes the steps in the build definition. Currently you have to use a Windows build agent to build Windows/Windows Phone apps and Xamarin.Android apps and a cross platform build agent on the Mac to build Xamarin.iOS projects. In the future, the cross platform build agent should also be able to build Xamarin.Android projects too.

To build Windows/Windows Phone apps and Xamarin.Android apps, the Windows build agent needs the following items installed on it:

Java JDK 1.7
Android SDK
Xamarin
Windows Phone SDK

Thankfully installing Visual Studio 2015 installs all of these items if you do a custom install and pick the Cross Platform Mobile Development, Universal Windows App Development Tools and Windows 8.1 and Windows Phone 8.0/8.1 Tools options. Once you have these pre-requisites set up, you can follow the rest of these steps to configure the build agent.

While Visual Studio 2015 installs all of the required pre-requisites needed, it doesn’t set the ANDROID_HOME and JAVA_HOME environment variables that are needed for the build agent to locate these components and advertise them as capabilities.

1. Open the System item in the Control Panel, choose Advanced System Settings and at the bottom of the Advanced tab click Environment Variables. Then add the following two items to the system variables section:

a. Variable Name: ANDROID_HOME

Variable Value: C:\Program Files (x86)\Android\android-sdk

b. Variable Name: JAVA_HOME

Variable Value: C:\Program Files (x86)\Java\jdk1.7.0_55

The jdk1.7.0_55 bit might change depending on what version of Java was installed on your build server.

2. The Java Keystore file that is used to sign Xamarin.Android apps needs to be placed onto the build server so that the build agent can find it. I recommend creating a folder in the C:\ drive called BuildAssets and putting the Keystore file in there. Remember you can download the sample Java Keystore file for this tutorial if you don’t have one, but you’ll need to create your own for a production environment.

To run the build agent, your build server needs to be able to execute PowerShell commands. For security reasons PowerShell commands are set to Restricted on all versions of Windows except for Windows Server 2012 R2 (which is set to RemoteSigned). To allow the Build Agent to run, the security setting needs to be set to RemoteSigned.

3. To change your PowerShell security settings to RemoteSigned, search for PowerShell using Start Menu/Start Screen search, right click on Windows PowerShell and choose Run as Administrator. Then run the following command: Set-ExecutionPolicy RemoteSigned

4. Finally it’s time to download and run the build agent. You can download it by logging into VSO/TFS, then clicking on the Settings icon in the top right hand corner and finally clicking the Agent Pools tab. Then click the Download Agent button at the top of the left panel. This will download a zip file containing the build agent.

5. I recommend creating a BuildAgents folder in the C:\ drive to store all of the agents you wish to create (you can have multiple agents running on the same machine). Inside this BuildAgents folder, create another folder called Agent1 (or whatever you want to name your build agent). Then extract the contents of the zip file you downloaded into this folder.

6. In File Explorer, navigate to this folder that you just extracted the contents of the build agent zip into and choose File -> Open Windows PowerShell -> Open Windows PowerShell as Administrator (or if you’re on Windows 7 and don’t have this option, open Windows PowerShell from the Start Menu and use the cd command to navigate to the folder where you’ve extracted the build agent to).

7. In the Windows PowerShell command window type .\ConfigureAgent.ps1 and press enter.

8. You should now be asked the following questions that will let you configure the build agent:

a. Enter the name for this agent: You can use whatever name you want to here, but you should keep it close to the name of the folder that you’re running this agent out of, so it’s easy to identify which agent is which

b. Enter the URL for the Team Foundation Server: This is the URL of your Team Foundation Server. If you’re using Visual Studio Online, this URL is in the following format: https://myvsoaccountname.visualstudio.com/ (where myvsoaccountname is the name of your account)

c. Configure this agent against which agent pool: This allows you to put the agent into a specific pool. If you’re following along with the sample solution, just press enter to use the default pool.

d. Enter the path of the work folder for this agent: Just press enter to accept the default path, there’s normally no reason to change this.

e. Would you like to install the agent as a Windows Service?: For the purpose of this tutorial, you’ll choose No, but if you’re setting up a build agent that is going to be used in a production environment, then this is recommended so that a user doesn’t have to be continuously logged on to keep the build agent running. Windows Services start when the computer starts up and they don’t require a user to be logged in to run them.

9. Finally, a OAUTH login page will appear asking you to sign in with your Microsoft Account details. This Microsoft Account must be the one that was configured earlier to administer build agents.

The build agent should now successfully configure itself, detect what capabilities your server has (e.g. does it have Visual Studio or Java or Xamarin.Android installed) and make itself available to execute builds that are sent to the specified agent pool . Do not close the PowerShell window until you want to stop the build agent. You can stop the build agent by pressing Ctrl-C. To start the build agent again, repeat the .\ConfigureAgent.ps1 command again (when you’ve navigated to the Agent1 folder). This time it will remember all of the entries you set so you can just keep pressing enter to accept all the defaults.

Configuring The Mac OS X Build Agent

For the first time, Microsoft has created a cross platform build agent for the release of Team Foundation Server 2015 (as well as Visual Studio Online). This cross platform build agent allows Mac OS X and Linux machines to be build agents for build definitions created using the Build.vNext tools included in Team Foundation Server 2015 and Visual Studio Online. They’re written in Node.js and so you install, update and run them using Node.js

To build Xamarin.iOS apps, the cross platform build agent on Mac OS X needs the following items installed on it:

Xamarin
Xcode

Note: This cross platform build agent is still in pre-release form (this is currently the one big disadvantage of using the Build.vNext tools at the moment). I have experienced several bugs while using this tool, but you can report issues and (if you want) submit pull requests with fixes to bugs that you find. The cross platform build agent is open source and you can find it on GitHub (https://github.com/Microsoft/vso-agent). Also, because it’s built on Node.js, the entire agent is written in JavaScript and so you can edit the code on your own build agent to fix any issues.

1. Download Node.js from http://www.nodejs.org/ and run through the installer, accepting all the defaults.

2. Open the Mac OS X Terminal and type: sudo npm install vsoagent-installer –g . This will download and install the latest version of the cross platform build agent to your machine. This won’t actually create an agent for you though. This is essentially just a templated copy that you can then use to create actual agents later.

3. While still in the Mac OS X Terminal, run the following command: sudo chown –R $USER ~/.npm . This is recommended by Microsoft to avoid a bug in Node Package Manager.

4. I recommend creating a BuildAgents folder in the root of your Macintosh HD partition to store all of the agents you wish to create (you can have multiple agents running on the same machine). Inside this BuildAgents folder, create another folder called Agent1 (or whatever you want to name your build agent). You can create these folders using the Finder.

5. In the Mac OS X Terminal, type cd /BuildAgents/Agent1 to switch to the newly created folder.

6. Type vsoagent-installer to install a cross platform build agent into that folder.

7. Next, type node ./agent/vsoagent to start the configuration of the build agent.

8. You should now be asked the following questions that will let you configure the build agent:

a. Enter alternative username: If you’re using an on-premises TFS server, enter the username of the account that was configured to administer build agents earlier. If you’re using VSO, enter the alternative username that you set, for the account that was configured to administer build agents earlier.

b. Enter alternative password: Enterthe corresponding password for the account chosen in the previous step.

c. Enter server url: This is the URL of your Team Foundation Server. If you’re using Visual Studio Online, this URL is in the following format: https://myvsoaccountname.visualstudio.com/ (where myvsoaccountname is the name of your account)

d. Enter agent name: You can use whatever name you want to here, but you should keep it close to the name of the folder that you’re running this agent out of, so it’s easy to identify which agent is which

e. Enter agent pool name: This allows you to put the agent into a specific pool. If you’re following along with the sample solution, just press enter to use the default pool.

9. The cross platform build agent should now successfully configure itself, detect what capabilities your server has (e.g. does it have Xamarin.iOS or Java installed) and make itself available for builds that are sent to the specified agent pool. Do not close the Terminal window until you want to stop the build agent. You can stop the build agent by pressing Ctrl-C. To start the build agent again, repeat the node ./agent/vsoagent command at the Terminal (when you’ve navigated to the Agent1 folder) and this time you’ll only need to enter the alternative username and password to start the agent again.

Creating A Xamarin.iOS Build Definition

Now that you have the build agents set up on both Windows and Mac OS X, it’s time to create the build definitions on VSO/TFS to build our solutions. This is the easy bit of the process and the steps are extremely similar for Xamarin.iOS, Xamarin.Android and Windows/Windows Phone projects. Firstly you’ll start with iOS, which uses the build agent running on Mac OS X.

1. Log into your VSO/TFS account and click on the team project you want to build to bring up the home page for that team project.

2. From your team project Home page, click on the Build tab and click on the green Add (plus) button on the left panel to add a new build definition.

3. In the Definition Templates dialog that appears, on the Build tab, click on Xamarin.iOS and click OK. This will create a new Build Definition with some Build Steps pre-configured.

4. Click the Edit link next to “New Xamarin.iOS definition 1” to start editing the build definition.

The build definition editor screen has several important sections. Firstly there are several tabs that appear along the top of the editor (such as Build, Options, Repository etc.). These tabs appear for every single build definition you create and will all offer the same settings for you to change (although the settings aren’t global settings that apply to all build definitions). On the Build tab of the editor, you’ll see a two column layout. The left panel lists build steps and the right panel shows settings that are specific to that build step.

When you create a new build definition that is based on the Xamarin.iOS template, it is pre-configured to include two steps: Build the Xamarin.iOS project and then test it in Xamarin Test Cloud. You need to modify the Xamarin.iOS build steps so the build agent will build the solution and upload the .ipa package that is created as a build artifact to VSO/TFS.

5. Looking at the first build step listed (which is called Xamarin.iOS), beside the ‘Solution’ input field, click the ellipsis and select the solution file for the solution you want to build. Then click OK.

6. Next, click ‘Add Build Step...’ and in the Add Build Steps dialog that appears, click Add beside the ‘Publish Build Artifacts’ item. Then click Close.

7. Looking at the new ‘Publish Build Artifacts’ build step, In the ‘Copy Root’ input field type: $(Agent.BuildDirectory)\bin\Release

If you’re using the sample solution, replace Release with Release_iOS

8. In the Contents input field type: **\* (this uploads everything in the folder you selected above, which is normally the bin folder for your release build configuration)

9. In the ‘Artifact Name’ input field type: drop (you can theoretically name this anything you like, but drop is a commonly used term)

10. In the ‘Artifact Type’ dropdown list choose Server (this uploads the artifacts up to the VSO/TFS server, you can also choose a file share if you prefer).

11. As testing isn’t covered in this tutorial series, just click the X beside the Xamarin Test Cloud entry to remove it.

Now you’re going to change a couple more settings, these are the more generic settings that aren’t specific to a certain project type.

12. On the Triggers tab, tick the Continuous Integration (CI) tick box so that every time a new change is synced up/checked in to VSO/TFS, a new build will be automatically triggered.

13. On the Variables tab, make sure that the value for Configuration is Release.

If you’re using the sample solution, replace Release with Release_iOS

14. On the General tab, change the Default Queue from Hosted to Default, so that your build agent that is in the default agent pool is selected to execute your build definition. You cannot use the hosted build queue for Xamarin.iOS builds because there are no hosted Mac build server available at this time.

Also note at the bottom of the General tab the Demands section. This is a list of components that must be available on the build agent for that agent to be able to successfully execute this build definition. A build agent advertises what it has installed through its capabilities. Essentially the capabilities and demands have to match up for a build definition to work correctly.

15. Finally, click Save and give the build definition a name such as “Xamarin.iOS Build”, add a comment if required and click OK.

You can now test your Build Definition by choosing Queue Build... and clicking OK. If everything has been configured correctly, your build definition should finish with the message “Build Succeeded” on a green banner. If it fails, you can look through the logs and figure out why it didn’t work.

Creating A Xamarin.Android Build Definition

Now that you have a successful Xamarin.iOS build happening, it’s time to create a Build Definition for our Xamarin.Android project, which uses the Build Agent running on Windows.

1. From your team project Home page, click on the Build tab and click on the green Add (plus) button on the left panel to add a new build definition.

2. In the Definition Templates dialog that appears, on the Build tab, click on Xamarin.Android and click OK. This will create a new Build Definition with some Build Steps pre-configured.

3. Click the Edit link next to “New Xamarin.Android definition 1” to start editing the build definition.

The build definition that comes pre-configured when you pick the Xamarin.Android template includes quite a number of build steps. Unlike Xamarin.iOS builds, Xamarin.Android builds can be built using the hosted build server and so they come a lot more pre-configured with steps needed to allow for that to work. For the purposes of this tutorial, you’re going to remove the steps for MSBuild and Xamarin Test Cloud as well as the steps for activating and deactivating the Xamarin Licences, because testing won’t be covered in this blog post and therefore you don’t need to activate and deactivate Xamarin on the fly for every build on your own personal build agent. You can remove steps by clicking on them and then pressing the red X beside them.

You need to modify the Xamarin.Android build steps so the build agent will build the Android project, sign the resulting .apk package, then zipalign that signed .apk package finally upload the zipaligned .apk package as a build artifact to VSO/TFS.

4. Firstly you’ve got to configure the Xamarin.Android step so it can build your Android project and output an unsigned .apk package. Beside the Projecy input field , click the ellipsis, select the project file for the Xamarin.Android project you want to build and click OK

5. For the Target input field, type: PackageForAndroid (this will trigger the build target that will create a .apk package once the project is built)

6. Now, select the Android Signing build step. Under Jarsigner Options tick the ‘Sign the APK’ option.

7. In the Keystore File input field, type the path to your Keystore file (if you’re using the recommended location that was suggest earlier in this tutorial, it should be located in C:\BuildAssets\SampleKeystore.jks (where SampleKeystore.jks is the name of your Keystore file)

8. In the Keystore Password input field, type the password of your Keystore

If you’re using the Sample Keystore, the password is: Demo123

9. In the Alias input field, type the name of the Alias which stores the key you’re using to sign your .apk package.

If you’re using the Sample Keystore, the Alias is: Demo

10. In the Key Password input field, type the password associated with the alias you chose.

If you’re using the Sample Keystore, the password is: Demo123

11. In the Jarsigner Arguments input field, type: -verbose -sigalg MD5withRSA -digestalg SHA1

12. Under ZipAlign Options, tick the ‘Zipalign’ check box.

13. Select the Publish Build Artifacts step. In the Copy Root input field type: $(Agent.BuildDirectory)\bin\Release

If you’re using the sample solution, replace Release with Release_Android

14. In the Contents input field type: **\* (this uploads everything in the folder you selected above, which is normally the bin folder for your release build configuration)

15. In the ‘Artifact Name’ input field type: drop (you can theoretically name this anything you like, but drop is a commonly used term)

16. In the ‘Artifact Type’ dropdown list choose Server (this uploads the artifacts up to the VSO/TFS server, you can also choose a file share if you prefer).

17. On the Triggers tab, tick the Continuous Integration (CI) tick box so that every time a new change is synced up/checked in to VSO/TFS, a new build will be automatically triggered.

18. On the Variables tab, make sure that the value for BuildConfiguration is Release.

If you’re using the sample solution, replace Release with Release_Android

19. On the General tab, change the Default Queue from Hosted to Default, so that your build agent that is in the default agent pool is selected to execute your build definition. You could use the hosted build queue if you like, but in this tutorial, the point is to set up a local build agent to do the building for you.

20. Finally, click Save and give the build definition a name such as “Xamarin.Android Build”, add a comment if required and click OK.

Creating A Windows/Windows Phone Build Definition

Now that you have successful Xamarin.iOS and Xamarin.Android builds happening, it’s time to create a Build Definition for our Windows or Windows Phone project, which uses the Build Agent running on Windows.

1. From your team project Home page, click on the Build tab and click on the green Add (plus) button on the left panel to add a new build definition.

2. In the Definition Templates dialog that appears, on the Build tab, click on Visual Studio and click OK. This will create a new Build Definition with some Build Steps pre-configured.

3. Click the Edit link next to “New Visual Studio definition 1” to start editing the build definition.

When you create a new build definition that is based on the Xamarin.iOS template, it is pre-configured to include four steps: Build the Visual Studio solution, test that solution, publish the symbols from that solution and then upload the build artifacts. You need to modify the Visual Studio build steps so the build agent will build the solution and upload the .xap or .appx package that is created as a build artifact to VSO/TFS. For the purposes of this tutorial, you’re going to remove the step for ‘Visual Studio Test’ as well as the step for indexing sources and publishing symbols because testing won’t be covered in this blog post and you won’t be working with symbols. You can remove steps by clicking on them and then pressing the red X beside them.

4. Now you’ve got to configure the Visual Studio Build step so it can build our solution and output a .xap or .appx package. Beside the ‘Solution’ input field on the Build tab, click the ellipsis, select the solution file for the solution you want to build and click OK

5. Next, select the Publish Build Artifacts step. In the Copy Root input field type: $(Agent.BuildDirectory)\bin\Release

If you’re using the sample solution, replace Release with Release_WinPhone

6. In the Contents input field type: **\* (this uploads everything in the folder you selected above, which is normally the bin folder for your release build configuration)

7. In the ‘Artifact Name’ input field type: drop (you can theoretically name this anything you like, but drop is a commonly used term)

8. In the ‘Artifact Type’ dropdown list choose Server (this uploads the artifacts up to the VSO/TFS server, you can also choose a file share if you prefer).

9. On the Triggers tab, tick the Continuous Integration (CI) tick box so that every time a new change is synced up/checked in to VSO/TFS, a new build will be automatically triggered.

10. On the Variables tab, make sure that the value for BuildConfiguration is Release.

If you’re using the sample solution, replace Release with Release_WinPhone

11. Still on the Variables tab, for the BuildPlatform value input field, type: ARM for a Windows Phone project or x86 for a Windows project.

12. On the General tab, change the Default Queue from Hosted to Default, so that your build agent that is in the default agent pool is selected to execute your build definition. You could use the hosted build queue if you like, but in this tutorial, the point is to set up a local build agent to do the building for you.

13. Finally, click Save and give the build definition a name such as “Windows Build” or “Windows Phone Build”, add a comment if required and click OK.

Summary

This brings Part 2 and therefore this tutorial series to a close. Hopefully you’ve been able to follow along and now have a continuous build environment that can build your Xamarin.iOS, Xamarin.Android and Windows/Windows Phone packages automatically on each check in.

I’m excited about the Build.vNext tools and am keen to see them improve in future updates (especially the cross platform build agent).

If you have any questions or feedback about this topic, leave your comments below. :)

Setting Up A Continuous Build Environment For Xamarin: Part 2 - Build.vNext