Digests » 224
The O'Reilly Velocity Conference is heading to New York City in just a couple of weeks and where will you be? At the office, wishing you weren’t missing the leading conference on DevOps, performance, cloud infrastructure, and more? With Pavilion Plus passes starting at only $149, you can't afford to miss it. Plus, as a C# Digest reader, you can get 20% off of your Gold, Silver, or Bronze pass with code CDIG20—that’s up to $519 in savings! Find the pass that's right for you and start making your plans today.
I've been doing .NET image processing since the beginning. In fact I wrote about it over 13 years ago on this blog when I talked about Compositing two images into one from the ASP.NET Server Side and in it I used System.Drawing to do the work. For over a decade folks using System.Drawing were just using it as a thin wrapper over GDI (Graphics Device Interface) which were very old Win32 (Windows) unmanaged drawing APIs. We use them because they work fine.
I don’t know how this happened but for the last couple years (at least), whenever I read an author who writes about ORMs, I often see a sentiment like this: “ORMs are fine, just make sure you disable this pesky feature called Lazy Loading”.
First, to avoid misunderstandings, let me explain what I understand by generic repository.
During the 2018 Microsoft Hack Week, members of the Mono team explored the idea of replacing the Mono’s code generation engine written in C with a code generation engine written in C#. In this blog post we describe our motivation, the interface between the native Mono runtime and the managed compiler and how we implemented the new managed compiler in C#.
According to Microsoft it’s super simple to migrate from .NET Core 2.0 to 2.1. Just change netcoreapp2.0 to netcoreapp2.1, remove some CLI tools and you’re done! When we tried this approach we ran into a NETSDK1061 issue. Below is a step by step on how we fixed it.