Michael James - Developer

As I've mentioned a few times recently I've been pushing our use of ARM based devices at work for a while now. What started on Raspberry PI 2's &  3's as prototypes and early builds has developed into something much bigger. Which is great, however the way we've been writing and building code has got stuck in a bad process. For all of our .Net Core code we have a full CI pipeline which produces appropriate outputs for deploy to our devcies in an automated way. However in some of our more recent work we've needed to start compiling third party dependencies for our ARM based boards and even some C++ components. It's always been on the "Todo:" list to ensure these dependencies and components got into our CI pipeline but with using various contractors and being "busy" things have gone too long with "works on my machine" builds and various network shares containing "OpenCV NEON optimised" and other such dependencies. ...

Today I hit an issue whilst trying to run dotnet run for some of our benchmarkdotnet tests which I like to run all new hardware I try out. My pair of Raspberry PI 4's arrived and I wanted to compare the performance of our Fingerprint capture code. I've hit the issue before and last time I figured it out I swore I'd blog and write it up as I knew I would forget! My benchmark project is a straight forward BenchmarkDotNet project however it consumers NuGet packages from both nuget.org as well as our private NuGet repository which requires authentication. For all of our windows machines this works without an issue for machines on the domain they authenticate seemlessly however when using Linux devices this is a different issue :( Instead on Linux devices we always get: /home/pi/dotnet/sdk/2.2.300/NuGet.targets(121,5): error :   GSSAPI operation failed with error - An invalid status code was supplied (SPNEGO cannot find mechanisms to negotiate). This essentially means it ...

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 interest...

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 d...

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...

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...

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 Learnt Net Standard Libraries and Multi-Targeting Multi-Targeting Class Libraries #ifdefs Conditional NuGet's Muti-Target your Unit Test...