Saturday, 14 January 2017

Help! My PowerShell path in the prompt is gone!

If you follow my speeches you surely know I am a huge fan of posh-git, an extremely handy PowerShell module to display inline repository information.

Today I installed it in a Virtual Machine I am going to use for demos at a conference next month and I noticed something odd at first sight:


Where is my path?!

Thanks to Antonio I realised that maybe it was a good idea to check the documentation. It was indeed…


The whole step 2 section explains how to customise the PowerShell prompt – so it was trivial to restore it to the full path as I like it Smile

Wednesday, 4 January 2017

Error AADSTS90093 with SonarQube and AAD, why?


It happens. And the reason here is extremely easy and straightforward: if you have any permission on your AAD application for SonarQube which you don’t need you will be denied access Smile

The documentation was updated in June but this error came out recently on an old instance set up before then.

Monday, 19 December 2016

Use the SonarQube Scanner with the new activity for the Team Build

As I mentioned the new SonarSource-maintained activity allows for the SonarQube scanner to be run independently of MSBuild – very useful for repositories containing only JavaScript files for example, where you cannot use the MSBuild-based task because of the lack of a .*proj file.

So all you need to do is to add the relevant task to your build definition:


You only need to configure the required options in the task - it comes with a pre-configured file so you are ready to go!

You need to create a SonarQube Endpoint like described in the other post, add the typical project key/name/version property triplet and, if you want, you can change the folder containing the source files. Also, if you have your own ready for use you can supply it in the Advanced pan:


Scenarios where you might want to use this task are where you don’t have a MSBuild-based project system supporting your code, so the other task would not work. Also, it is very handy with heterogeneous projects.

Tuesday, 13 December 2016

The new connected extension installation experience in TFS 2017

A few months ago I blogged about how the Marketplace takes advantage of the shared TFS and VSTS architecture to provide a good experience to the administrator when it comes to Extensions.

Now the experience goes from good to excellent with TFS 2017!

The installation experience is now completely seamless. From my local TFS Gallery I can browse the Marketplace like I always did:


By clicking that link I am going to be redirected to the Marketplace, but even if I am not logged in as a user I will be logged in as a server:


This is done on the Team Foundation Server instance you are using, if you look at the URL you clicked you can see a serverKey attribute in the query string.

Now I can browse the Marketplace and select whatever I am interested in. Let’s say the Countdown Widget:


Clicking on Install is going to trigger the installation, already pointing at the local TFS Gallery – the extension was already downloaded for you, this happened as soon as you clicked on Install:



That’s it!


It is a great improvement as the experience now no longer requires manual interaction with the server.

This is also an excellent example of a good experience in a context of a Hybrid DevOps Stack, where the Marketplace providing the extensions is part of the stack and it provides the very same service both on-premise and as a service.

Thursday, 8 December 2016

What happened to the SonarQube extension?

If you run a SonarQube analysis in your pipeline you might have noticed this:

imageIt is actually the case – the SonarQube extension is being spun off the product and transferred to SonarSource for further development.

This is not bad news, as we already gained the possibility of running the command-line scanner in the Team Build, both on-premise and (that is where it is important!) on the hosted one.

Also, there is a new integration type – a native SonarQube one:


Here you can define your server and use a token for authentication, which is much better than credentials.

Monday, 28 November 2016

Review – Professional C# 6 and .NET Core 1.0

.NET Core brings so many changes, even if you don’t write production code on a daily basis you might want to have a refresh Smile and that’s what I did with Christian Nagel’s book.


It is very well flowing and never too near a knowledge base article – Christian writes very well. The content in there is for Visual Studio 2015, but you can definitely use it with 2017 as well.

I was particularly interested in the .NET Core and ASP.NET Core sections, and I reckon they are really a fresh and clear starting point on the matter. Given we are talking about a printed book it might not be fully updated, but again it is a matter of a few touches here and there. It is worth remembering that it is stuff in continuous evolution, so I would expect it.

But the book definitely isn’t just about .NET Core and ASP.NET Core. It covers extremely well the stack from top to bottom, and I quite enjoyed the What’s new in C# 6.0 section and the recap from C# 1.0 to 6.0 in the first pages. As I said it is about the whole stack, so once you are off the first 450 pages (Part I is all about the language) you can tackle the IDE, the Compiler Platform and more.

I particularly liked how broad the approach was. The Testing section for example mentions not only MSTest but also xUnit, and in both .NET Core and .NET Framework, the Diagnostics section mentions Application Insights, etc. Christian did an amazing job summarising these broad but also specialist topics, and the result is really well-integrated

I am a huge fan of books, and I really enjoy having a well-written reference I can dive into instead of going straight to Google, losing context in the meantime. This is one of these, and I also strongly suggest this book to whoever needs a refresh or is tackling C# and the Microsoft stack with a bit of past experience.

Tuesday, 22 November 2016

Safely add tasks to an on-premise Build Agent from the vsts-tasks repository

In my last post I uploaded a task from the vsts-tasks GitHub repository to my on-premise Build Agent. How did I know it was going to work in the same way as with VSTS?

First of all you need to check the minimum agent version in the task you are interested in. Let’s take the .NET Core task I used as an example, that task has a minimum version of 1.95:


This means that the task is going to work from version 95 of the closed-source version on Windows. How do I know that?

Before TFS 2017 there were two different agents – a Windows-only, closed-source version and a Xplat, open-source one. The closed-source version was v1.x, the open-source version was v0.x. This version number can be retrieved in the Agent.Version property of your Build Agent:


Now the agents come from a single repository and they are written in .NET Core as a single code base. This version of the agents is marked with v2.x.

So whenever you want to add a task from the tasks repository always check for the minimum agent version required for it. Generally, if you are on the latest version you won’t have problems adding new tasks unless there are breaking changes – and these are really well documented, if any.