ImageTagHelper in .NET Core–add data URI scheme

The ImageTagHelper in ASP.NET Core MVC ( is lacking one attribute that I find somehow useful: a data uri to embed the image as base64 ( )

I was curious about how fast it will be to make such a modification on my PC.

So the process was:

  1. Downloading branch rel/1.1.1 from as a zip file
  2. Unlock the file, unpack, run  MVC.sln with VS2015
  3. Compile the entire project.
  4. See tests  ( also run dotnet test in the Mvc-rel-1.1.1\test\Microsoft.AspNetCore.Mvc.TagHelpers.Test to figure what was missing)
  5. Started modifying the file ImageTagHelper( adding
     public bool RenderBase64 

    and creating FileBase64ContentProvider.cs with the (approximately) same content as FileVersionProvider

  6. Adding tests to  mvc-rel-1.1.1\test\microsoft.aspnetcore.mvc.taghelpers.test\imagetaghelpertest.cs  ( also modifying mocker –
    for my purposes, to read the file, I need file length

                    .Setup(m => m.CreateReadStream())                
                    .Returns(() => new MemoryStream(Encoding.UTF8.GetBytes("Hello World!")));
    mockFile.SetupGet(f => f.Length).Returns(12);
  7. Modifying HtmlTargetElement attribute from ImageTagHelper
  8. Adding “Microsoft.AspNetCore.StaticFiles”: “1.1.0”, and app.UseStaticFiles();  to HtmlGenerationWebSite and going to http://localhost:5551/HtmlGeneration_Home/image

And that was all. Now I will see how to fork and submit changes 😉

Later Edit: Submit a bug, fork, pull request. Approved.

7 rules of logging ( and 7 notes)

Those are my 7 rules for logging (you can read also the side note for every rule)

So here they are:

  1. Logging is good for developers, not for the user .
  2. You should not re-invent logging framework – just use one that exists in your programming language.
  3. The logging should not affect the usual behavior of the program.
  4. You should log everywhere there is a layer made by you (including GUI).
  5. If the software returns/throws a generic code for error,then he should log the concrete details of what happened and the time * although this should be automatically done by the logging framework).
  6. The logging should be easy to configure ( where to log, what to log ).
  7. The format in which are you logging should be easy to understand by an automatic text parser

Note 1: Corollary : Every software needs logging and this should be performed as good as possible , with all specific details to understand the problem.

Note 2 : Choose one that works well in multi-threaded application, has multiple outputs ( database, log file, console , others) and provides various levels of logging( at least debug, info , error). For   .NET : log4net, nlog .  Do re-invent the wheel – if you believe that you can make something better .

Note 3 :  For example logging a function that modifies some parameters or logging variable.ToString() and this throws the infamous “null reference”

Note 4 : See 

Note 5 : For example, if you throw a generic exception “ Something bad happened “ in order to not bother the user with mundane details, you should log the primary error and the reason that you throw the generic exception

Note 6:  This means it is easy for DevOps to configure the software to not log into production the debug levels .

Note 7: See



I have become tired of reading about how to enable Wifi HotSpot in Windows 10 . The reference is here: . ( also, for bandwidth throttling you can try and / or   )

I was trying to make a Windows Store application – but, apparently, it is very difficult to run command lines application from Windows Store/

So I made a small powershell file ( hosted at )


Final 2016 and predictions for 2017

2016 meant for me

1. YouTube tutorials on .NET and tools –

3. Hardware Share Initiative – through which we provide Raspberry Pi and others

4. Reconfirm MVP

5. .NET Core – I have to get up to speed.

6. The job of Technical Director – the meetings were not so harsh.


In the 2017 I (want to) see


1. Consolidation of JavaScript frameworks – or browsers ( now I see so many flavors that is difficult to make a choice)

2. It works on my machine will be soon enough “It works on my Docker/Virtual Machine” and I will deploy as “Docker/Virtual Machine”  into production

3. The OOP programmer will be soon replaced by functional programmer and / or Component Expert Programmer (means the programmer that knows what components to use)

4. IoT will be joined with Augmented Reality

Logstash on Windows– transformation of data

Part 1: 

Part 2 :

Now we want to use logstash for transforming data. For this , we use filter plugins to modify the data.

The process is like this:  Logstash receive the data(input plugin) , then apply a filter plugin( to parse and make new fields of data) and then sends data to output ( with an output plugin)

Let’s say we have this data that comes in a csv form,  like this:


AndreiPC, 10

OtherPC, 5

But we want to collect also from local pc ( let’s say console ) and do not put the PC name. The configuration is

input {
tcp {
    port => 9000
    type => "tcpLog"
  stdin {
    type=> "console"
    if [type] == "tcpLog" {   
        csv {
            columns => [       
                "Source" => "tcp"
    if [type] == "console" {   
        csv {
            columns => [                           
                "PCName" => "%{host}%"
    mutate {
         convert => { "RAM" => "integer" }
  output {
stdout {codec => rubydebug}


I find the configuration easy to understand – the output is a detailed json( rubydebug) and the input can be either tcp, either console.

If type is console, than a field will be add ( PCName ) .

And , at the final of the filter , the RAM field will be mutated into integer.

You can find filter plugins at