Makes Your Laptop Becomes A Build Agent Of VSTS

 

You are a developer and working on some open source projects. You are using VSTS to maintain your source code. As you know the free version of VSTS is giving 240 minutes every month for the build. What happens if your free minutes have gone? You need to wait for until to next month to build and deploy your projects?

You are using the preview version of Visual Studio (currently is 2017 preview 3) to develop some projects on .Net Core 2 and .Net Standard 2 preview 2. However, the is no available build agent on VSTS for the preview framework yet.

I have a crazy idea why don’t use our laptop as a build agent for VSTS so that you can install whatever you want on your laptop worry less about the host compatible? If you are facing some difficulties above then this post I will show you how to makes your laptop becomes a build agent of VSTS.

1. Download Agent Package

Login to your VSTS and navigate to the Agent Queues and then click download agent. There is three package available for Window OS X and Linux. You shall able to download a zip package around 83MB for your window. This package contains all needed components for a build agent host.

 

2. Generate Personal access tokens

Click on you account icon at the top right and navigate to security then Personal access tokens. Create a new token named build-agent with the Authorized Scopes as below.

After clicking the save button, you will have a token look like this:

khyppjfxamx6sjjrmhfdefthbdxzssltvoevxp56rn5ezdrunkcoding

Refer here for details of Personal access token creating and revoking.

3. Agent Installation

  • Right click on the downloaded zip package -> properties and check the unblock checkbox then click ok.
  • Unzip the package into C:\vsts-agent.
  • Create a folder C:\vsts-build for the build this one will be used to contain the source code from VSTS when executing a build definition.
  • Run the PowerShell with administrator privilege and point the unzipped package (by using cd command).
  • Run the ./config.cmd to start the installation:

  • When running agent as service it will ask for the service account, I’m using Network Service as the service account for the agent. The reason to run the agent as service is whenever you start your laptop/Pc up the agent will be available in the VSTS immediately without any configuration needed.

Run the command .\config.cmd remove to un-install the agent on your laptop if need.

I like the way Microsoft develop the agent, your laptop doesn’t need a static IP for it, The agent will work whenever the laptop is up and connected to the internet care less about the IP and location. Bring your laptop everywhere you want and execute the build anytime you need.

4. Agent Configuration

Now navigate to the default agent pool on your VSTS your laptop name should appear. Before executing the build, you need to define the capabilities of the new agent as below. The Java capabilities on the below screenshot are needed if you are using some Java build tasks example Sonarqube tasks.

 

Here is the full text of the capabilities of my laptop for your reference purpose.

  • java: C:\Program Files\Java\jdk1.8.0_131
  • jdk: C:\Program Files\Java\jdk1.8.0_131
  • jdk_8: C:\Program Files\Java\jdk1.8.0_131
  • MSBuild: C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise\MSBuild\15.0\Bin
  • VisualStudio: C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise
  • VSTest: C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TestWindow

Now you can execute your build without the limitation. However, please note that this one for personal use only. I don’t recommend to use this on your company as exposing a server to the internet is not compliance and dangerous.

If your company is using VSTS, then should purchse the agents from Micrsoft or hosting everything (TFS and Agents) on the premises to maximize the flexibility is also a case.

This is the screenshot to prove that my laptop is working fine with VSTS.

Nuget Packager Unsupported Framework Issue on VSTS

 

I was facing an Unsupported Framework issue with Nuget packager on Visual Studio Team Service Online (VSTS) when porting my HBD Framework to the .Net Standard.

I had been mad with this issue in a couple of days, and eventually, I found a solution to fix it. Let me explain about the problem and the solution. So it might help for those who are facing the same problem.

1. Build and Deployment Process.

First, I would like to share my Nuget Publishing Automation Process. I have using VSTS as primary source codes repository sin last few years. In there, I created a few auto build and auto release processes that help to publish my packages into Nuget.org continuously.

Internally, I’m using the Package Management for VSTS as my test environment. So all beta versions of my packages have been published into this tool for testing purposes. Once the package is stable, I just simply trigger the other release to put it to Nuget.org.

Below is the illustration of the publishing process that had been implemented on my VSTS.

I will show you the details of the continuous deployment in difference post as the purpose of this post is fixing the Nuget Packager issues.

Continuous Deployment

2. The Issue.

When ported my HBD framework to the .Net Standard, the Nuget Packager was showing the below warning message when packaging my binaries on VSTS.

After then The .Net Standard had displayed as the Unsupported framework on my package. Hence, my package was not able to publish to Nuget.org as it is not allowed an Unsupported framework to be deployed.

Furthermore, if open the nuspec file with Nuget explorer the frameworks is displaying properly.


Here is the configuration of my nuspec file.

3. The solution

After spending a lot of times on this issue, I realized that the problem is the version of default Nuget.exe file in Nuget Packager is old (3.x), and it is not supporting the .Net Standard.

So, to fix this issue, I downloaded the latest version of Nuget.exe here and replaced the default version of Nuget packager by the following configuration of the build definition on VSTS.

  1. Put the Nuget.exe file in the Shared location on VSTS.
  2. Map the Shared location to the Build Definition.
  3. Replace the Nuget.exe of Nuget Packager with the version in Shared location.

 

Then execute a new build and re-deploy the package to Nuget.org again, here is the result.

  • Hopefully the issue of the Nuget Packager will be fixed soon. However, ai this time if you are facing the same problem then just apply this as the work around solution for your build.
  • VSTS online is free tool. Register here if you want to learn about the auto build, auto deployment.

You can download the latest source code of HBD.Framework here.