Building with C1Studio controls in Visual Studio Team Services

Visual Studio Team Services (formerly Visual Studio Online) has become increasingly popular among enterprise development teams. With Azure integration, Git, agile, and continuous integration wrapped up in a hosted solution, I can see how eager any development team would be to use the service. If you're planning to use the VSTS hosted build system to compile applications that make use of GrapeCity controls, though, there's one roadblock: licensing. The GC licensing model relies on the developer activating a serial key on the machine that will build or compile the software. The issue with using GrapeCity controls in VSTS is that you’ll never know where to activate the serial key as you may never use the same hosted server to build twice. The solution to this problem is setting up an on-premise build agent in VSTS. This is a server or machine that you have access to that VSTS will perform build tasks on. We'll be able to activate a serial key on this build agent and build as we normally would while still taking advantage of all the benefits of using VSTS. In this article, we’re going to run through the creation and setup of the following:

• Setup of a new VSTS project
• Adding code to the project's repository
• Cloning the project in Visual Studio 2015 and adding some code
• Setting up a build agent and definitions in VSTS to run on a local machine
• Building the project from VSTS on the local machine

Set up a new Visual Studio Team Services project

The first thing that we'll need to do is set up a new project in Visual Studio Team Services. While logged into VSTS, click on the "New" link at the top-right of the main screen. This brings up a dialog where we can enter the details of the project, including name, project description, process template (agile, scrum, etc.), and version control options. For the purposes of this blog, let's leave the process template and version control to their respective defaults, which are agile and git. Once we have the new project set up, we can add a solution to the project. The easiest way to do this is to use Visual Studio 2015. Once you're in your newly-created project in the browser, click on the “Code” tab and select the “Clone in Visual Studio” option. This launches Visual Studio and presents us with some options in the Team Explorer window. The first thing we see is a prompt to clone the repository we just created in VSTS. Let's select a location for our local repo and click "Clone." Once that's completed, we're prompted to create a new project or solution to add to the local repository. For the purposes of this article, we'll be creating a new project using the Windows Forms Application template in Visual Studio. After creating the project and solution, it should open automatically and create changes that are staged for commit in our local repo. Once the project is loaded, let's add a FlexGrid for WinForms control to the form and save the solution. Just to be sure everything is working as it should, it's a good idea to do a quick “clean” and “rebuild”. Once we've done that, we can commit our changes. Navigate to the Team Explorer window and click on the “Changes” button, add a comment, and click “Commit All”. Finally, we'll sync our changes with the VSTS repository. Visual Studio will ever so kindly prompt us to do this once our commit has finished. Click the “Sync” option in the Team Explorer window and then “Push” in the subsequent step. Now we're ready to move on to create our build definitions.

Set Up a PAT (Personal Access Token)

Before we proceed, we’ll need to set up what Microsoft calls a “Personal Access Token." This tells VSTS that a given machine or resource is allowed to access information. There is more information on where to set up the PAT at https://www.visualstudio.com/en-us/docs/setup-admin/team-services/use-personal-access-tokens-to-authenticate. We’ll need to set up a personal access token for the build agent to use when performing builds for VSTS. This PAT is required for a future step, so it'll need to be created at this point. Let's create a new PAT for our local build agent using the settings below. For this article, all we really need is the Agent Pools (read, manage) scope.

IMPORTANT!: You should copy the PAT to a secure place on your machine as it will only be shown to you ONCE.

Download the Build Agent

With our PAT in hand, we can begin setting up our local build agent, which is actually relatively painless. This set up should only take a few minutes, with a minimal amount of tears. First, let's head over to our project in the browser, click on the little gear icon near the top middle of the page, and select “Agent queues”. Click the button labeled “Download Agent”. This calls up a window with a download button, as well as some instructions on what to do once the files have been copied to the appropriate directory. Now we can move over to our machine where we'll be setting up the build agent.

Setting Up the Build Agent

Ok. We’re at our build machine…what now? The first thing that we need to do is create a directory on the C:\ drive where the build agent files will live. Following the instructions from the window above, we’ll need to create a directory called agent at C:\agent and extract the files from the zip file we downloaded previously. The directory should look something like this after the files have been downloaded. Now we can run Windows Powershell as administrator and get this thing set up. We’ll need to cd into the agent directory that we just created and type the following command:

C:\\agent> .\\config.cmd

This queues up the configuration file and begins the setup process. The information that we need to enter is as follows. >> Register Agent:

• Enter agent pool (press enter for default) > {press enter here to leave as default}
• Enter agent name (press enter for C1CE22) > {this will be the name of the machine that you are running on currently…press enter}
• Enter work folder (press enter for _work) > {press enter here to leave as default}
• Enter run agent as service? (Y/N) (press enter for N) > {we want to run as a service so type Y then enter}
• Enter User account to use for the service > {this will be your domain/user account on the build machine}
• Enter Password for the account *** > {this is the password for the user account you entered above}

All told, we'll see the following, with the end result being the agent service started and ready for use. Setting up the agent as a service allows us to “set it and forget it” when queuing up builds from VSTS.

Create the Build Definition

Let’s head back over to our browser and set up a build definition using the build agent we just created. From within the project, let’s click on the “Build & Release” tab at the top of the screen. Once there, we can select “+New Definition”. As we can see from the next screen, VSTS provides a host of build and release options. We’ll keep it simple: select “Empty” and click next. In the next window, set the default agent queue to “Default,” because that's the pool we used to create our build agent. That’s it! Now we can use our new definition to fire off a build on our local build agent.

Let’s Build It!

All that’s left to do is queue a build and see if it runs. From the builds tab in our project, select the appropriate build definition and click the “Queue new build” button. Ensure that the default queue is selected in the subsequent window and… Success!