Check Angular AoT with a TFS Build

Developing with Angular is a real fun, but usually during development you serve the application without any optimization, mainly because you want to speedup the compilation and serving of your Angular application.

When it is time to release the software, usually you build with –prod switch and usually you also use the –aot switch (it seems to me that it is on by default on –prod in latest version of the ng compiler). The aot switch enable the Ahead of Time compiling, that is used to speedup your deployed application and also it find some more error than a normal compilation.

I do not want to made examples when a simple ng build compile just fine but the production build with aot fails, the important concept is, when you fire your production build to generate install packages, it is really annoying to see your angular build fails because of some errors. Since building with aot is really expensive I’ve decided not to trigger this build for each commit, but only for special situations. First of all, here is the whole build.


Figure 1: Build to check aot compilation

As you can see, with TFS Build it is really a breeze to create a build that simply trigger the ng compiler to verify that it correctly compiles with aot switch on. Thanks to the trigger panel of my build, I’ve decided to build automatically only master and release branches.


Figure 2: Trigger configuration for my AOT build

This is another great advantage of Git over a traditional source control system, I can configure a single build for every branch on my repository. In this specific situation I require that the build will be triggered for release and master branches.

This is usually a good approach, but I want to move a little bit further so I configure that build as optional for pull request for develop branch. With this technique, whenever a pull request is done on the develop branch, that build is triggered, and people can fix errors before they slips to the main develop branch.

Thanks to VSTS build system, it is just a matter of minutes to setup specific build that checks specific part of your code, like angular production compilation and optimization.

Gian Maria.

How to security expose my test TFS on the internet

I’m not a security expert, but I have a basic knowledge on the argument, so when it is time to expose my test TFS on the outside world I took some precautions. First of all this is a test TFS instance that is running in my test network, it is not a production instance and I need to access it only sometimes when I’m outside my network.

Instead of mapping 8080 port on my firewall I’ve deployed a Linux machine, enabled SSH and added google two factor authentication, then I expose port 22 on another external port. Thanks to this, the only port that is exposed on my router is a port that remap on port 22 on my linux instance.

Now when I’m on external network, I use putty to connect in SSH to that machine, and I setup tunneling as for Figure 1.


Figure 1: Tunneling to access my TFS machine

Tunneling allows me to remap the 8080 port of the machine (my local tfs) on my local 8080 port. Now from a machine external on my network I can login to that linux machine.


Figure 2: Login screen with verification code.

This is on a raspberry linux pi, I simply use pi as username, then use verification code from my cellphone (google authenticator app) and finally the password of my account.

Once I’m connected to the raspberry machine I can simply browse http://localhost:8080 and everything is redirected through a secure SSH tunnel to the machine. Et voilà I can access any machine, any port in my network just using SSH tunneling.


Figure 3: My local TFS instance now accessible from external machine

This is surely not a tutorial on how to expose a production TFS instance (please use https), but instead is a simple tutorial on how you can access every machine in your local lab, without the need to expose directly the port on your home router. If you are a security expert you will probably find flaws in this approach, but surely it is better than directly map ports on the router.

Gian Maria.

Choose agent at build queue time

This is a simple feature that is not known very well and deserve a blog post. Sometimes you want to queue a build to a specific agent in a queue and this can be simply done using as a demand.

Demands are simple key/value pairs that allows the build engine to choose compatible agents and each agent automatically have a couple of capability to store computer name and agent name (they can be different)


Figure 1: Capability of agentes, computer name and agent name are automatically present

This allows you to use one of them if you want to run a build on a specific machine, just queue the build and use the demands tab to add or agent.computername demands.


Figure 2: Choosing specific agent at queue time with capability

If you specify a name that is not valid you will get a warning, if the queue contains that specific agent the build will be queued and will be executed only by that agent.

This technique is useful especially if you add a new agent and want to trigger some specific build on it to verify if it has all the prerequisite ok.

Gian Maria.

VSTS agent on Ubuntu 16.04 error in

I’ve downloaded the build/release agent from VSTS page to install in my Ubuntu 16.04 system, but when I tried to run the configuration shell script I got the following error

Failed to initialize CoreCLR, HRESULT: 0x80131500

This happens because I installed the version for Ubuntu 14.04 and not the one specifically compiled for Ubuntu 16.04. In my situation the error happened because the download page of my VSTS account does not list the version for Ubuntu 16.04, but only for Ubuntu 14.04 and this incorrectly lead me to the false belief that it works for both versions. The page from where you download the agent is and should also list the version for 16.04.


Figure 1: Agent download page in your VSTS account.

To avoid error the best way to download the agent is checking the official GitHub account page.

The best place to download and to look for VSTS agent information is the official GitHub page.

As you can verify from Figure 2, we have a two distinct compiled version for Ubuntu.


Figure 2: Distinct builds for vsts agents (Ubuntu 14 and 16)

To download the correct version, you can easily go to the release page ( where you can download all official versions for all supported operating system / version.

Gian Maria.

New Nuget Task in VSTS Build

If you edit a build in VSTS where you configured Nuget Packaging and Publishing, you can notice that all the old tasks to pack and publish are marked as deprecated.


Figure 1: Old nuget tasks that are now deprecated.

Deprecating a package is needed when the Author decide to completely replace the entire package, changing also the id. This is needed when the task will be completely redesigned and will work in a complete different way from the old version.

For nuget package, Microsoft decides to publish a new task that can do Restore/Pack/Publish, all in one pacakge. The new package also uses a new dedicated nuget feed connection from your VSTS account to external nuget feed.

If you use VSTS internal feeds, there is no change, but if you are using an external feed, you can verify that now you can add a dedicated type of  connection for Nuget feeds (Figure 1).


Figure 2: External service endpoints configuration, now a dedicated Nuget feed is present.

The nice part of having a dedicated Nuget feed is that you can specify a dedicated authentication (1) and also you can Verify Connection (2) to check if all the data is good; the service knows that this is a Nuget endpoint and can verify if everything is good before triggering a build.


Figure 3: Configuration of Nuget Endpoint


Figure 4: Usage of the Nuget endpoint.

Once you defined one or more Nuget Endpoint, you can easily choose them from a Combobox in the Nuget Task, simplifying the configuration of the build.

I strongly suggest you to try this new task and to update all of your build to take advantage of it.

Gian Maria.