.NET Standard

The .NET framework has been branched into several implementations to match the constraints of the target platforms, e.g. Compact Framework for Pocket PC, Mono for Linux and the full .NET Framework for Windows.

This poses a problem regarding library compatibility between them. Writing a library is not straightforward since one has to target the specific framework in which the library is consumed.  This has somewhat been alleviated by Portable Class Libraries (PCLs), since this type of library can target multiple frameworks. It is not a 100% solution, since when a new framework emerges the library in question is not automatically compatible with the new framework.

The solution has been to introduce a versioned formal API specification called .NET Standard. This standard is implemented by all the most common framework implementations. Writing a library targeting .NET Standard 1.0 ensures that the library can be consumed across different frameworks, if they implement the .NET Standard 1.0.

The .NET Framework 4.5 implements .NET standard 1.1 while .NET Framework 4.6 implements .NET Standard 1.4. Writing a library for both .NET Framework 4.5 and 4.6 can easily be done by targeting .NET Standard 1.1. Also, Windows Phone 8.1 and Mono implements .NET Standard 1.3 or above making the said library compatible with these implementations.

Each new version of the .NET Standard inherits from the previous version, making a new version a super-set of the old version. The API specification is written i C#, making it straight forward to read and adapt the API to a new implementation.

.NET Core is the latest framework implementing .NET Standard, more on this later.

Linq To Sql .Attach

Linq to SQL is a very nice abstraction when dealing with MSSQL, specifically the ability to conduct Linq queries in C# against MSSQL is pretty sweet. Updating a row through an ORM object, e.g. a HTTP Put, into the DB without doing manual field copying between the tracked entity and the de-serialized entity from the PUT is however a bit troublesome.

.Attach allows one to attach an entity to a Context, however calling SubmitChanges will not submit the changes of the attached object due to it not being marked as modified. Calling Attach(entity, asModified) with asModified = true did not work for me – an exception was thrown.

Apparently, this overload can only be called with asModified = true IFF Update Check is set to Never in the DBML file. This needs to be done for all properties of the given entity class, not sweet, but at-least it avoids the need to manually copy each member to an existing tracked Entity in the Context.

Jira SDK nuget

Accessing Atlassian Jira from a .NET application can be done very easily by installing the Atlassian Jira SDK.

Install-Package Atlassian.SDK

From the nuget console.

This introduces the Jira assembly with alot of different classes and helper functions. E.g. one can connect to Jira using:

Jira.CreateRestClient(url, username, password)

which instantiates the Jira class which can be used to get Versions, Issues, etc. from Jira. A real treat using this library is that it proved Async methods, i.e. await keyword can be used throughout the usage.

getting all Versions of a specific project/key can be done using:

var results = await jiraConn.Versions.GetVersionsAsync(key)

getting issues using a specific JQL query can be done using:

var results = await jiraConn.Issues.GetIssuesFromJqlAsync(jql)

super easy!

System.AccessViolationException and .NET 4.0

The  System.AccessViolationException is thrown if one tries to marshal unamanaged memory from an invalid location, e.g. using a bad pointer. Prior to .NET 4.0, this exception was catch-able from within the CLR.

With .NET 4.0,  System.AccessViolationException exception is no longer catched within the CLR, meaning that the application now crashes without necessarily logging the information in log4net. The stack trace can however be seen in windows’ event viewer.

It is possible to mark the method in which the exception is thrown using HandleProcessCorruptedStateExceptionsAttribute, thus making the method throw the exception into the CLR and making it catchable.


XenServer Auto-boot

Apparently, auto-booting of a VM on a XenServer was removed in 6.0+.

auto-booting can still be done by utilizing the command line from XenCenter.

First, one must specify the Pool as being “auto-bootable”.
Next, one must specify the VM as being “auto-bootable”.

This guide shows the exact steps necessary to achieve both:




Creating Virtual Machines (VMs) is a great way to easily deploy software for testing and production purposes. For many of my projects, especially those requiring a HTTP backend, I create a VM to host said solution.

Azure is a great way to host in the cloud, but it can get quite expensive – especially if one needs a lot of VM’s for testing purposes. In addition, transferring stuff to and from the cloud requires a beefy internet connection when dealing with BigData related entities.

Recently I experimented with setting up my own HyperVisor using cheap hardware, specifically: a Intel celeron J1900 quad core with a small 128GB SSD and 8GB of ram, to host some of my VMs.

Installing VMWares VSphere Hypervisor (ESXi) was my initial thought, but I could not get the install process all the way through. Apparently, ESXi only supports a limited number of hardware configurations. Luckily, an OpenSource alternative exists call XenServer.

XenServer is, more or less, a Linux powered hyper-visor. Installing is a breeze, simply get the ISO from XenServer.org, flash an USB with the image and bootup a x64 with the virtualization technology enabled. After a few minutes of installing, XenServer is up and running and can be connected to from another PC using XenCenter management tool.

XenCenter allows one to create VMs, configure NFS, remote control a VM, take snapshots of a VM, and so on. XenCenter also allows one to create Pools of one or more XenServers (clustering=. The latter is especially awesome since it allows one to setup a centralized NFS for the virtuals disks and then deploy the VMs between the available XenServers.

I have not yet created a pool with more than one XenServer, but I want to install three of the above mentioned hardware and designate one as master and the other two as slaves. This would allow me to virtualize across three nodes, with a total of 12 CPU cores, 384 GB fast SSD and 24GB ram.

Stay tuned for the latter when I get more hardware to add to my pool.


Nearly all my latest projects have some sort of RESTful API. For testing purposes I use Postman, a HTTP client aimed at making it easier to test APIs by allowing custom messages to be formed.

The application can be run as a Chrome app or downloaded for Windows, MacOS and Linux distros as an application (executable).

Testing GET using the browser is straightforward, unless some specific header needs to be constructed. Testing POST, PUT, etc. is typically harder in a browser, since the browsers addressline is tied to GET (for obvious reasons).

Postman allows one to use many (if not all) of the HTTP methods. Postman allows one to specify the body of e.g. a POST. It allows also the ability to specific the exact headers for the request.

Frequently used requests can be saved into a history which is searchable, and one can also make collections of HTTP requests for specific applications.

Regarding the body content, postman supports TEXT, JSON, HTML, XML, etc. Binary is also supported by choosing a file on the disk to send.

Highly recommended for those who build or consume RESTful APIs.

Postman in action, running as a Windows 10 application.