Michael James - Developer

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