SonarQube UTF-8 error after upgrading

I’ve upgraded a SonarQube instance, and then, suddently I realyze that some builds start failing due to to a strange error in the SonarQube complete analysis task.

2016-12-09T11:41:00.8695497Z ##[error]WARN:
 Invalid character encountered in file C:\vso\_work\3\s\src\Jarvis.ConfigurationService.Client.CastleIntegration\Properties\AssemblyInfo.cs at line 25 for encoding UTF-8.
 Please fix file content or configure the encoding to be used using property 'sonar.sourceEncoding'.

Thiserror in turns made the entire task execution failing with a really strange error

2016-12-09T11:41:03.5135467Z ##[error]ERROR: Error during SonarQube Scanner execution
2016-12-09T11:41:03.5145430Z ##[error]java.lang.IllegalArgumentException: 5 is not a valid line offset for pointer. File [moduleKey=Jarvis.ConfigurationService:Jarvis.ConfigurationService:893ED554-3D86-47C8-B529-965329DB32AF, relative=Properties/AssemblyInfo.cs, basedir=C:\vso\_work\3\s\src\Jarvis.ConfigurationService.Client.CastleIntegration] has 1 character(s) at line 2
2016-12-09T11:41:03.5145430Z ##[error]at
2016-12-09T11:41:03.5145430Z ##[error]at org.sonar.api.batch.fs.internal.DefaultInputFile.checkValid(
2016-12-09T11:41:03.5145430Z ##[error]at org.sonar.api.batch.fs.internal.DefaultInputFile.newPointer(

This is really annoying, but actually I start investigating the error logging to the build server and checking the file that generates the error. When you have strange encoding erorr I strongly suggested you to visualize the file with some Hex editor, and not a standard editor.

I immediately realized that the error is due to my GitVersion task script, because it manipulates assemblyinfo.cs files to change version numbers and save back the assemblyinfo.cs in UTF-16 encoding. If you do not know Byte Order Mark I strongly suggest you to take a look in wikipedia, because this is an important concepts for Unicode files.

I immediately checked with an hex editor, and verified that the original assemblyinfo.cs has a BOM for UTF-8 but the PowerShell script modified it converting to UTF-16 but the BOM is correct. The annoying stuff is that the build worked perfectly until I updated SonarQube (server + analyzers) this means that for some reason, the most recent version of Sonar somewhat does not check the BOM to understand file encoding.

I’ve solved the problem simply changing the Set-Content call to force UTF8 and the problem is gone.

Set-Content -Encoding UTF8 -Path $file.FullName -Force

I really like SonarQube, but you should always verify that everything works after every upgrade.

Gian Maria.

Budget for Hardware

I’ve just read this blog post that deals about the benefit of having the right hardware to work for developers. Quite often having or not having an SSD is not the real problem, because developers works with machine with low ram and slow disks and this is especially true for people working with laptop, that often uses 5.400 standard RPM disks.

It is difficult to understand how much minutes or hours per day a developer can save moving from an average speed hardware to a top speed hardware and without these numbers it is difficult to justify the expense of buying top speed hardware. On the opposite, if it is difficult to demonstrate the gain in productivity with fast hardware, it is quite simpler to demonstrate the lack of productivity with crappy hardware.

Developers are strange kind of workers, quite often they like their work and working with crappy hardware will make a developer sad and frustrated. I’ve seen people that must wait for minutes to do a Subversion updates and minutes to fully rebuild a solution just because they have 5.400 RPM disks and 2 GB of RAM. The first bad effect of having crappy hardware is creating frustration in developers and a frustrated employee usually is less productive.

If the developer should wait for 2 minutes to build the solution, he will tend to utilize that time to do other stuff, because watching compiler output for 2 minutes is not a viable option ;); but 2 minutes is not enough time to do anything useful, then the programmer will do something “not useful” like: facebook, twitter, or else. Usually it will end with the compiler finished working and the developer still occupied answering to twitter.

Another problem is losing the “context”, if you need to wait a long time waiting for your tool of choice to compile and test your modification you loose your stream of thought. This is especially true if you are fixing complex bug, or you are doing a complex task, if you spend long time waiting for the result, your mind start to thinking to other stuff and you lose your focus.

When you are used to crappy hardware, you start thinking that the company will never spend money even for useful tools, so you start to lose time reinventing the weel or doing work in the wrong way.

My suggestion is, if you are not convinced that you developer will really need Top Speed Hardware, please convince yourself that they need at least Average Speed Hardware, because the lack of productivity of a developer with low performing hardware is terrific.

But in the end I can confirm also that the gain of speed of having a top speed machine is worth the price and I strongly encourage to buy fast SSD for every developer and machine with at leash 8 GB of RAM and an i5 or i7 CPU, this will make your developers more productive and usually happier and not frustrated.

Gian Maria.

The good part of having a lot of RAM

I’ve learned in the past a precious rule about hardware: try to imagine how you will use your pc in at least one or two years period before thinking to buy some piece of hardware.

I remember a lot of years ago, when I bought a pc with a 1.6 GB Hard Disk, a size that was really big for these period, when standard pc had 512 MB Hard Disk or less. I remember a couple of friends of mine told me “why you spent money on such a big Hard Disk, it is really too big, you will never need such a big space”. After one year, I ran in those machine a partition of Windows 95, one for DOS, a stable partition with Linux Slackware distribution and a fourth partition to experiment the new distribution of linux that we downloaded from the university. I’ve plenty of space while my friends strived themselves to keep everything inside 512 MB.

Today I installed a virtual machine to experiment TFS 11 and saw that during installation of SharePoint foundation there is a warning telling me that 10GB RAM is suggested for best experience, so I go to VM setting, and gave 12 GB of RAM to the VM. :)


Actually there is no need to have 12 GB to experiment with TFS11, a 4 GB machine will be enough to create a test environment, but having 16 GB of ram and an SSD on my machine permits me to play with a superfast test TFS 11 machine.

And I rethink to a couple of friends of mine, that 4 month ago told me that spending money on 16 GB of ram is not so useful, because 8 GB is surely enough for any usage :).

Now I’m moving toward a QNAP External HD case, and probably for Christmas another SSD (A Vertex 3) :P, I love hardware.


How could I work without resharper

In a system that use heavily IoC principle, it is common during component modification, to discover that to add a new functionality that component need to add a dependency on some interface. Here is the constructor of a component

   1: public MainNavigator(

   2:     IEBrochureService brochureService, 

   3:     IBroker broker)

   4: {

Now I need to add dependency from the IWpfSystem interface, so I simply add another parameter to the constructor, and R# suggests me a lot of action that could be triggered from this modification


The first one automatically declare a field called _engine and initialize into the constructor, but I have a lot of other options, like applying change signature refactoring, and change all call to this constructor, creating an overload version without this new parameter or even check for null assignment.

Shortcut like these one can tremendously boost up your productivity.