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 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.

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.

Start building ASP.NET Core 1.1 with TFS

In my spare time I am looking at ASP.NET Core – it brings so much change that you can’t really ignore it even if you are not a web developer.

After putting together the first samples (thanks to the help of a book as well, review coming in a few weeks) I wanted to build something in my lab with a TFS build, so totally on-premise and with no connection to the shiny VSTS.

After installing all the prerequisites (Visual Studio 2017 RC is a great starting point, and I added this on top as well) you can easily get up and running by using command-line tools in the build:

But it isn’t really what I wanted… and in Team Foundation Server 2017 there are no OOB tools for .NET Core. Not everything is lost though.

Firstly, install tfx-cli. Not only it works perfectly on-premise as well as with VSTS, but given that TFS now has a Personal Access Token system we can stop using basic authentication with it. Awesome.

Then, we need the nice task VSTS uses. You can get it from here and upload it to your local TFS by using tfx build tasks upload --task-path <your path>. Simple as that.

So you can start using it! Instead of using a .json file as a Project file you can totally point it at a .csproj file – what the task does is nothing but wrapping calls to dotnet.exe so as long as it is updated you are totally fine.

As I am using a basically empty ASP.NET Core application I unchecked the Publish Web Project option in the dotnet publish step – I want total control over the command. Zip Published Projects is fine as it just zips the artifacts.

This is it – I now have a CI build running in…say five minutes?

.NET Core support in the new Team Build with VSTS

Technology on its own is not really helpful IMHO – having an ecosystem really helps. So I noticed that VSTS now supports .NET Core in the Team Build, and obviously I wanted to give it a go

I started by creating a Team Project in VSTS and adding a sample application created with dotnet new –t web to its Git repository:

So it is time to build it:

There is now a Build Definition Template for .NET Core – long are the days when you had only a couple of them…

What this Template does is nothing really fancy – it encapsulated the basic commands from dotnet to tasks. You could have done the same with a command line task yourself, but the key point here is that this is all out-of-the-box now.

I just accepted all the default settings and triggered a new build. It is successful of course…

But again, the point here isn’t about the template itself (which you’ll customise anyway).

The big point is providing support to cutting edge technology, without support and an ecosystem technology alone, regardless of how cool and innovative it is, is pretty much useless.

Don’t just chuck your stuff in VSTS, take advantage of the artifact repository!

If I’d get a penny for any question on this activity I would be a billionaire by today:

It is a waste of time not sorting and creating proper folders for your artifacts – why should you dig into subfolders when you can create the best possible structure?

Firstly, start by splitting any infrastructural definition. There is no point in handling the json files or anything else related to the infrastructure with the packages, binaries and application-specific scripts.

Then try to divide your output into groups. In my case I really like to split between Infrastructure, Packages and Scripts. This is more than enough 99% of the time.

This is way clearer than this:

Without mentioning the folder structure…

That is because the default activity will collect everything you specify in your matching pattern regardless of the folder structure, while the custom activity (where you just add a new one basically, there is nothing really custom there) gets only the final leaf.