Can you use BuildRoot with Windows Subsystem for Linux......

A quick note I started this blog post back in August of 2018 and never completed it. Essentially I wrote most of it and then found I just couldn't run BuildRoot properly, I came back to it every Windows 10 release due to performance improvements etc however its only now with WSL2 that this is possible. Read on to find out the full story :)

Original Post I love Windows Subsystem for Linux, I mention it all the time in work, done "brown bag" sessions on it, even did a lightning talk on it at DDDSW 18.

This week I've been working with a contractor to produce essentially an Embedded OS for a project. Previously I've always used existing distributions and made them "lite" or used preconfigured ones, Raspbian Lite for example however he promptly told me I'm doing it wrong and that I shoudl be using BuildRoot.
Buildroot is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation. Sound's interesting but wha…

Lessons Learnt: Migrating From Net Framework to Net Core - Changing SQLite Providers

I mentioned back in the first post how we swapped SQLite providers during our port from .Net Framework to .Net Standard and .Net Core. Previously we used System.Data.SQLite and we now use Microsoft.Data.SQLite.  In order to support some older .Net 4.5 projects we use multi targetting and some #ifdefs to swap the providers without any real knowledge to the calling applications.

For the most part this worked without a hitch however today I want to highlight a difference between the providers which doesn't cause a build error and ended up being caught very late on in testing.

Rightly or wrongly a decision was made a long time ago to store a date time value in a sqlite db not as ticks but as a string, 2019-05-08T17:14:26.3441705+01:00 for example. It wrongly wasn't being stored as UTC but there was no visible side effect of this in its use case and this has been in the codebase for several years.

During recent final testing it was noted that it appeared just one table of data in o…

Lessons Learnt: Migrating From Net Framework to Net Core - Net Standard Libraries and Net Framework 4.6.1

My second lesson that I wanted to share is related to .Net Standard 2.0 libraries and .Net Framework 4.6.1. You might remember from last time that ".Net Standard 2.0 requires .Net 4.6.1 as a minimum", I've added emphesis to the as a minimum. In the beginning we were using most of our .Net Standard libraries without a problem in 4.6.1 but a couple of times we started hitting random errors that I couldn't pinpoint.

One example I had was using our .Net Standard 2.0 library which uses the System.IO.Ports NuGet package. On Windows everything appeared fine however when we used this with Mono we kept having "Unable to find port" exceptions. We knew this worked fine when we targetted .Net 4.5 however since switching to Net Standard and then the System.IO.Ports Nuget we were hitting this issue. At one point we even considered if this was a real deal breaker and did we have to revert the changes but I remembered the 4.6.1 being a minimum and the little note next to i…

Lessons Learnt: Migrating From Net Framework to Net Core - Net Standard Libraries and Multi-Targeting

One of the first lessons I'm going to share from our recent migration happened very early on in the project but continually popped up as we went along and updating each service.

I've always been a fan of code reuse and sharing code within our solutions however I don't like everything being used from one location. I like to modularlise and componentise any shared code. To date this has always been via Class Libraries and Portable Class Libraries when these were shared with Mobile Applications built with Xamarin as well. I've always versioned these and published via an internal Nuget server to reduce the risk when changes are made and to enforce decoupling.

My migration strategy to .Net Core (we chose 2.1 originally) stipulated that we should be fully backwards compatible; this meant that every library that we needed to use had to ideallly continue to work in all other referenced projects. Ideally I wanted to just update all of our class libraries to .Net Standard 2.0 an…

Lessons Learnt: Migrating From Net Framework to Net Core - Part 1 Introduction

I'm nearing the end of a major project in my work. Taking a number of our essential services running on IoT devices and porting them from running on Windows x64 over to Linux Arm; whilst still maintaining backwards compatability and still running these services on the existing Windows devices. This may sound like a daunting and major undertaking but actually it hasn't been too bad, it's very possible and the benefits of doing this, for us at least, are significant.

What I want to do over my next couple of blog posts is to highlight lessons I learnt during the process, thing's I wish I hadn't done / wish I had known before I started as well as any other things to takeaway from this.

As this will form a mini series of posts I'll keep a list of all posts updated below and maintain this on subsequent posts.
Lessons LearntNet Standard Libraries and Multi-TargetingMulti-Targeting Class Libraries#ifdefsConditional NuGet'sMuti-Target your Unit Test ProjectsNet Stan…

x86 .Net Core application fails to launch and debug via Visual Studio 2017

Today I had a random issue following changing one of my .Net Core projects. Usually I run these AnyCPU but this one needed to be X86 due to a third party library. I've done this before and had no issues but today VS seemed to launch the app and then immediately quit with an error exit code but no useful information!

So far whenever I hit something like this I always try and run it via the console using dotnet run in the project directory. Fortunately this showed the issue straight away:
It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '2.1.5' was not found.
  - Check application dependencies and target a framework version installed at:
      C:\Program Files (x86)\dotnet\
  - Installing .NET Core prerequisites might help resolve this problem:
  - The .NET Core framework and SDK can be installed from:

The mysterious case of being unable to debug a .Net Core Console application using Visual Studio 2017

This morning I had a very frustrating time. It started off well and I was continuing my drive to convert alot of our hardware services from .Net Framework over to .Net Core. Phase 1 is simply .Net Core running on Windows but then Phase 2 is true cross platform. To date its gone very well and I'll probably write about it further another time.

This morning I was continuing to port code across, mainly making our libraries .Net Standard 2 or .Net Standard 2.0 with .Net 4.5 multi targeting. All worked fine until I converted my final library. The app built, it ran and seemed to be working fine however all of a sudden none of my breakpoints in Visual Studio worked.

During this entire process I have found I've hit many build / compile issues when switching between branches and have often had to nuke my obj folders or do a git clean -xdf but this was not the case. Everything worked bar the breakpoints. The usual tricks didn't work, I even reboot my machine and then checked out the …