AngleSharp is a HTML parser library for .NET. Previously I’ve mainly used Html Agility Pack for parsing, but AngleSharp seems to be getting quite much traction nowadays.

I had a scenario where I wanted to use AngleSharp to wrap all the images with links. Given the following HTML:

<img src="2019-02-17-13-10-47.png" class="img-fluid" alt="Test stuff">

I wanted to transform it to this:

<a href="2019-02-17-13-10-47.png" class="lightbox">
	<img src="2019-02-17-13-10-47.png" class="img-fluid" alt="Test stuff">

Here’s how you can do this:

  1. Create the new link wrapper
  2. Get image’s original parent element
  3. Replace the image parent element’s image with the link wrapper
  4. Set image as the child of the wrapper

In C# using AngleSharp:

                var wrapperLink = document.CreateElement("a");
                wrapperLink.SetAttribute("href", image.GetAttribute("src"));
                wrapperLink.ClassName = "lightbox";

                var imageParent = image.ParentElement;
                imageParent.ReplaceChild(wrapperLink, image);
Where document is of type IHtmlDocument and image is of type IHtmlImageElement.


I’ve been doing some work converting Graze to .NET Core. Graze is a static web site generator which uses Razor and is built using .NET Framework.

One of the problems I hit when converting a class library to .NET Standard 2.0 was the following error at compile time:

Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create'

Graze uses dynamics in some places and turns out this error is related to dynamic keyword. To fix it I had to include I just had to include Microsoft.CSharp from Nuget.


We wanted to run integration tests in VSTS’ release phase. Our application is ASP.NET Core 2.0 based and the integration tests are on .NET Core 2.0 projects. Unfortunately we were always met with the following error:

Testhost process exited with error: A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'D:\a\r1\a\IntegrationTests\'.

It turned out that the problem was that we were publishing integration tests in the build phase without providing the framework and runtime arguments. We had to provide both of these arguments to the publish command to get things working:

-c $(BuildConfiguration) -o $(Build.ArtifactStagingDirectory) -r "win10-x64" -f "netcoreapp2.0"


I released NSQLFormatter few years ago (actually it’s more than few years ago, back in 2011.). As a reminder, NSQLFormatter is "an open-source SQL Beautifier written with C#".

In 2015 the library was released as a Portable Class Libray. There's now a new version which targets .NET Standard 1.3. This version is supported by about every currently supported .NET platform, including .NET Core, Mono and .NET Framework 4.6.1.

Let me know if you encounter any issues with the project.

GitHub: https://github.com/mikoskinen/NSQLFormatter-dotnet

NuGet: https://www.nuget.org/packages/NSQLFormatter/


In this post we will use NetMQ to build a solution where multiple clients can run commands on the server and the server dynamically created a worker for each command.


ZeroMQ and its .NET port NetMQ are interesting technologies. They seem to have a rather smallish but very enthusiastic group of users and the “scene” gives similar vibes as the Redis community.

ZeroMQ is a technology for adding distributed messaging into your system. Pub & sub, reply & request and other types of communication patterns are available. ZeroMQ doesn’t require a server installation, so it’s a library instead of full blown server solution. For communication, you can use TCP, inproc and other techniques.

Dynamic workers

We needed to use NetMQ in a situation where there’s multiple clients running commands on the server. The idea was that the server would spin up a worker for each client request. Even though ZeroMQ’s documentation is good, finding an example with dynamic workers turned out cumbersome.

We ended up using the following topology:

Client: RequestSocket

Server: RouterSocket (TCP 5555) – DealerSocket (TCP 5556) & Poller

Worker: DealerSocket

Creating the server

The server has a frontend for the requests coming from the client. It also has the backend for communicating with the workers. Poller is used to handle the messages:

Console.WriteLine("Starting server");
using (var front = new RouterSocket())
using (var back = new DealerSocket())

    var poller = new NetMQPoller();

	front.ReceiveReady += (sender, eventArgs) => {...};
	back.ReceiveReady += (sender, eventArgs) => {...};


Creating the workers

When the server’s frontend receives a message, we want to spin up a new worker. In this example we use ThreadPool to create the worker:

front.ReceiveReady += (sender, eventArgs) =>
    var mqMessage = eventArgs.Socket.ReceiveMultipartMessage(3);

    var id = mqMessage.First;
    var content = mqMessage[2].ConvertToString();

    Console.WriteLine("Front received " + content);

    ThreadPool.QueueUserWorkItem(context =>
		// The worker
		// Parameters are available from the context.
        var context = (Tuple<NetMQFrame, string>) context;

        var clientId = context.Item1;
        var message = context.Item2;

		// Run the command

		// Send message to server's backend which then will return the reply to the client
        using (var workerConnection = new DealerSocket())

            var messageToClient = new NetMQMessage();
            messageToClient.Append("hello from worker");


    }, Tuple.Create(id, content));

Returning the message to client

As we can see from the code above, the worker message sends the reply to the server’s backend. Only thing left is to route the reply back to the client:

                    back.ReceiveReady += (sender, eventArgs) =>
                        Console.WriteLine("Back received message, route to client");
                        var mqMessage = eventArgs.Socket.ReceiveMultipartMessage();

The client

Our client uses RequestSocket to call the server’s frontend. We use a blocking call, so we wait for the server (the worker) to reply:

using (var client = new RequestSocket())
    client.SendFrame("hello from client");
    var returned = client.ReceiveFrameString();
    Console.WriteLine(i1.ToString() + ": back at client " + returned);


This post shows one solution for spinning up worker tasks (threads) dynamically using NetMQ. Even though NetMQ only includes few basic concepts, the concepts are so flexible that it’s quite that there’s many other ways to handle this situation.