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

That little 2 is key, when you continue down the documents page the additional information is the answer.
There are several issues with consuming .NET Standard libraries that were built for those versions from .NET Framework 4.6.1 projects. For .NET Framework projects that need to use such libraries, we recommend that you upgrade the project to target .NET Framework 4.7.2 or higher.
We then bumped up the project that we are using Mono with to .Net 4.7.2 and everything went back to normal.

This got me thinking further, should we ever use .Net Standard libraries with our .Net Framework 4.6.1 projects, my initial thoughts were no, it's just not worth the risk and I was sure I remembered a few people on Twitter discussing this.

And then Immo Landwerth chimed in with a few comments:

So this confirmed my thoughts, using .Net 4.6.1 with .Net Standard just isn't ideal. This isn't a massive issue for us as where possible we can always upgrade to 4.7.2 or still Multi Target for our more legacy projects.

That's it for this lesson, onwards to lesson 3 :)

Comments

  1. odalet7 May 2019 at 08:08

    I learnt exactly the same lesson!

    ReplyDelete
  2. Howard Richards7 May 2019 at 11:01

    Going through similar pains here as we try to move most libraries to .NET Standard 2. We're not going down the multi-targeting route - we first upgraded to net 472 (after learning the 461 issues the hard way as well!).

    Next, we only create new libraries/code in .NET Standard 2, and will gradually go back through existing ones to port over to netstandard2.0.

    Once all that is done we have to upgrade our web project to .NET Core and razor pages - although we might go direct to Blazor.

    ReplyDelete

Post a Comment

Popular posts from this blog

WebUSB - An unexpected update...

Image
In January at my new(ish) user group Momentum Meetups , I presented on "Reaching out beyond the Chrome" (although suffering from food poisoning so I was definitely going green at points!). It included  WebUSB and WebBluetooth . I was excited by how powerful it was and even had a colleague present something we had been prototyping in out work place. During the talk I mentioned security and how it had been designed so it only works on https and there's a permission model where you have to approve the device before it can be used. Unfortunately this week it came to light that Authentication devices could be bypassed via USB. These devices are a great way of proving you are who you say you are on the web beyond basic 2FA text's or applications. So being able to be able to bypass them via WebUSB is a big deal :( My Original Security Slide A few days later Google then disabled WebUSB by default effectively killing it off until such a time where its made secure
Read more

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

Image
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
Read more

DotNet CLI , private NuGet feeds and Linux...

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
Read more