Notes from Daily Encounters with Technology RSS 2.0
# Sunday, April 19, 2015

Diagnostic analyzers are a new extension point in Visual Studio 2015, enabled by the new .NET Compiler Platform (codename: Roslyn). They are custom pieces of code, analyzing the source code, which run at compile time, but are also scheduled in the background inside Visual Studio when the source code changes. Results of the analysis are warnings and errors treated the same way as the ones built into the C# (or Visual Basic) compiler.

In the past such code analysis could only be added to Visual Studio using high profile extensions, such as ReSharper, CodeRush and JustCode which had to reimplement the compiler themselves. Each one of them included their own custom API for writing plugins. Such market fragmentation of course resulted in pretty small number of available plugins.

Thanks to Roslyn the price of entry for performing custom code analysis has significantly reduced, hence there are already many diagnostic analyzers available, both by Microsoft (FxCop Analyzers, Code Analysis for Azure) and open source initiatives (.NET Analyzers, Code Cracker, C# Essentials), although the final version of Visual Studio 2015 has not even been released yet. I can imagine a future, where library authors will include diagnostic analyzers as a guidance to their users and larger development companies will develop internal diagnostic analyzers to enforce their coding style.

I've already experimented with diagnostic analyzers in the first Visual Studio 2015 Preview, but since I'm going to speak about this subject at the upcoming local conference, I had to configure a working environment using the latest Visual Studio 2015 CTP 6. Although I knew exactly what I needed, it turned out quite a hassle to get everything up and running, so here's a complete list of required software. Just keep in mind that it is very likely going to change with the next release of Visual Studio 2015.

  1. Obviously you first need to install Visual Studio 2015 CTP6.
  2. To add support for building VSIX packages (installers for Visual Studio extensions) you will also need to install Microsoft Visual Studio 2015 SDK. Diagnostic analyzer template includes a VSIX project and will fail without this component installed. You will also have no simple way to debug your diagnostic analyzer without it.
  3. .NET Compiler SDK Templates for CTP 6 Visual Studio extension will add the Diagnostic with Code Fix (NuGet + VSIX) project template to Visual Studio which will create a simple working diagnostic analyzer to give you a jump start.
  4. Not strictly required but highly recommended is the .NET Compiler Platform Syntax Visualizer for CTP 6 Visual Studio extension which gives insight into the syntax tree of the code you are currently editing, as Roslyn compiler sees it. It will prove extremely useful when you start developing your own diagnostic analyzer.

.NET Compiler Platform Syntax Visualizer

Once you have installed everything, you're ready to create your first diagnostic analyzer project. Just open Visual Studio 2015, create a new project and select Visual C# > Extensibility > Diagnostic with CodeFix (NuGet + VSIX) template in New Project dialog. There's a nice ReadMe.txt file included in the generated solution. Just follow the instructions in the second paragraph to try out the generated code analyzer: make sure the VSIX project is set as startup project and press F5 to start debugging.

This should open a new instance of Visual Studio 2015 with the code analyzer already deployed to it. Create a new class library project inside it and you should already see you code analyzer in action, suggesting you to make the type name all upper case:

Diagnostic analyzer template in action

Sunday, April 19, 2015 9:43:52 AM (Central European Daylight Time, UTC+02:00)  #    Comments [0] - Trackback
Development | Roslyn | Software | VisualStudio
# Sunday, April 5, 2015

Rich Helton: Learning NServiceBus SagasAfter I published the review for Learning NServiceBus - Second Edition, I got contacted by a Packt Publishing representative, whether I'd like to review another book about NServiceBus, they have recently released: Learning NServiceBus Sagas by Rich Helton. Seeing it as a logical continuation of the book I have already read, I agreed to do it.

In spite of the introductory chapter, the reader should already be familiar in advance with the concepts of an enterprise service bus and the patterns related to it, as well as with the basics of NServiceBus. Also the book is not focused only on sagas at all; it gets distracted by many other technologies, such ASP.NET MVC, WCF, Microsoft Azure and others, not really telling much about any of them either.

The samples are very contrived and almost impossible to make sense of by just reading the book, because their crucial parts are not explained and can only be found in the accompanying download file. Not even the basic functionality and structure of sagas is properly explained, much less any advanced concepts and usage scenarios. On the other hand; just to prove how simple it is to change the transport from MSMQ to other queuing technologies, the process is described 5 times in different parts of the book, making NServiceBus use RabbitMQ, ActiveMQ (twice), Azure Storage Queues and Azure Service Bus, instead.

The content is not well structured; the author keeps jumping from one topic to the other, often repeating himself, which makes the book very difficult to follow. On top of that, the text is occasionally even misguiding; e.g. unit testing (much less TDD) is not about initially writing the code in a test and then copying it to its correct location. I can't really recommend the book to anyone. It's just a waste of time and money. You'll learn more by reading the official documentation and blog posts on the topic.

The book is available on Amazon and sold directly by the publisher.

Sunday, April 5, 2015 11:01:07 AM (Central European Daylight Time, UTC+02:00)  #    Comments [1] - Trackback
Development | .NET | Personal | Reviews
# Sunday, March 22, 2015

Paul Swartout: Continuous Delivery and DevOps - A Quickstart GuideDevOps is a topic we have all been hearing a lot about lately. When I was contacted by Packt publishing whether I am interested to review their latest book on the subject (Continuous Delivery and DevOps - A Quickstart Guide - Second Edition by Paul Swartout), I decided to grab the opportunity and learn more about the subject in a more structured way than blog posts and podcasts can provide.

It turned out this was mostly a book about soft skills, with technical topics not being in the forefront. There were a couple of tools mentioned, and the importance of monitoring and metrics was strongly pointed out, but I expected more than that. I might be a bit biased due to my engineering background, though.

A common thread through all the chapters is a story about a fictional company which successfully implemented DevOps. It serves as an example of the journey and the practices involved. Probably the most important message it tries to get across, is the fact that there's no such thing as DevOps in a box: you can't buy it or just hire an expert - everyone needs to live it and breathe it.

In the end the book falls a bit short and remains just an overview of methodologies and approaches, with lots of pointers to further resources. Although, not really actionable on its own, it is still a good starting point to learn about DevOps: what it is and why you might want to take on the task of implementing it.

The book is available on Amazon and sold directly by the publisher.

Sunday, March 22, 2015 1:43:26 PM (Central European Standard Time, UTC+01:00)  #    Comments [0] - Trackback
Personal | Reviews
# Sunday, March 15, 2015

David Boike: Learning NServiceBus - Second EditionI'm fairly familiar with the architecture of distributed applications and the concept of a service bus, though I don't have any first hand experience with NServiceBus. When I got the offer to review Learning NServiceBus - Second Edition, written by David Boike and recently published by Packt Publishing, I gladly accepted the opportunity to learn more about this premium service bus implementation for .NET framework.

The book starts out with a short step-by-step tutorial for creating a simple distributed application using NServiceBus, but it quickly moves on to a more advanced overview of the platform as a whole and the principles it builds on. Although most of the book revolves around development, it doesn't constrain itself to it. Towards the end, operational topics are covered as well: application configuration, administration, monitoring, scaling; showing the scope of the platform, being much more than just a development framework.

The author doesn't focus on NServiceBus alone; instead he gives quite a lot of attention to the basics of messaging and service buses, doing his best to provide incentives for a distributed application design. No matter the previous experience, by the end of the book the reader should be acquainted enough with NServiceBus, to recognize a project requiring it. When that happens, this introductory book won't be enough to get the job done. Still, once you've read it, it will be much easier to depend on other (mostly online) resources, listed in the book. I also like, how the author pointed out the most important changes in the latest version of NServiceBus, which will prove more than useful when reading older blog posts about it.

Whether you're starting to learn about NServiceBus, considering the adoption of distributed architecture in a .NET framework based project, or just want to know what NServiceBus is about, you should read this book. You never know when this knowledge might give you a different perspective on the challenges in your daily work.

The book is available on Amazon and sold directly by the publisher.

Sunday, March 15, 2015 3:40:59 PM (Central European Standard Time, UTC+01:00)  #    Comments [0] - Trackback
Development | .NET | Personal | Reviews
# Sunday, March 8, 2015

Writing a build script for my DocPad project was only the first step before finally setting up a configuration in TeamCity which automatically runs on every commit. Although there is no built in support for Grunt in TeamCity, it was easy enough to find a plugin for it, so that I didn't have to invoke it from command line. Plugin installation was straightforward as usual for TeamCity plugins. Of course, the correct version of Node.js must also be installed on the server which is hosting the build agent.

The first step in the build configuration must install the NPM dependencies which are not committed in the source control repository. Thanks to the already mentioned TeamCity.Node plugin this can be easily done by just selecting the Node.js NPM runner and calling it with install command as always. As long as Node.js is properly installed (and TeamCity was already restarted after the installation to pick up new machine-wide paths), it just works.

Since I already had a build script ready, I only had to run my existing Grunt tasks (generate, test and deploy) as the next 3 steps in my TeamCity configuration. Again, it was enough to select Grunt as the runner and enter the name of the task for each of the steps. As suggested in the Grunt documentation, I selected the runner to use the NPM package from project instead from a system-wide installation. It came as a slight surprise to me that this meant grunt-cli will have to be installed as a local development dependency in the project as well.

The next stumbling block on the path to a working build in TeamCity were globally installed NPM packages - DocPad to be exact. In the recent versions of Node.js NPM is globally installing packages per user and not per machine. This avoids the need to have administrative privileges when globally installing packages, but requires them to be installed separately for every user which will need them.

In the case of TeamCity build agents, this means that it is necessary to globally install the required packages also for the user account which is being used by them. As long as they are running as regular users and don't use any of the system accounts, this shouldn't be a problem: you can always log in with that account and install the missing packages.

For agents, using the Local System account, as configured by default, it is possible to start a command prompt for that account using PSTools and install the package from there. This isn't enough, though, because the install location (%WINDIR%\System32\config\systemprofile\AppData\Roaming\npm) in this case isn't added to path, as it is for the other users. Since running services with Local System account isn't a good idea any way, I would suggest to use a dedicated service account for the agents and avoid the issue altogether.

The steps above were enough to achieve a working build inside TeamCity, but in case of failed builds the output only included the name of the step which failed without any additional information:

[14:44:54]   Step 3/4: Test (Grunt)
[14:44:55]      [Step 3/4] Step Test (Grunt) failed

For cases like this TeamCity supports service messages in special format which are automatically parsed and aggregated to the build overview page. To make matters even simpler, there's already a Grunt task available which adds support for them to any existing Grunt task. The usage of grunt-teamcity is really simple:

        all: {}


  grunt.registerTask('generate-TC', ['teamcity', 'generate'])
  grunt.registerTask('test-TC', ['teamcity', 'test'])
  grunt.registerTask('deploy-TC', ['teamcity', 'deploy'])

To add emitting of TeamCity service messages to other tasks, teamcity task always needs to be executed before the other ones. To avoid its extra output when running Grunt from command line, I decided to add a simple wrapper for each of the tasks which runs teamcity as the very first task, and changed build configuration in TeamCity to start these wrapper tasks instead of their original counterparts. Now the output provides much more information in case of a failure:

[15:47:11]   Step 3/4: Test (Grunt) (1m:08s)
[15:47:16]      [Step 3/4] Resource not found linked from http://localhost:9778/ 
                           to http://localhost:9778/blog/archive1.html
[15:47:16]      [Step 3/4] Status code: 404
[15:48:19]      [Step 3/4] Aborted due to warnings.
[15:48:19]      [Step 3/4] Done, but with warnings.
[15:48:19]      [Step 3/4] Step Test (Grunt) failed

The same report is also included in the mail sent from TeamCity every time a build fails. In most cases the included information should be enough to fix the build even without looking at the complete log in TeamCity. I'm quite satisfied with that.

Sunday, March 8, 2015 8:07:01 PM (Central European Standard Time, UTC+01:00)  #    Comments [0] - Trackback
Development | Grunt | Software | TeamCity
My Book

NuGet 2 Essentials

About Me
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

All Content © 2015, Damir Arh, M. Sc. Send mail to the author(s) - Privacy Policy - Sign In
Based on DasBlog theme 'Business' created by Christoph De Baene (delarou)
Social Network Icon Pack by Komodo Media, Rogie King is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.