Comment by bob1029 | Hacker News Reader

Comment by bob1029 | Hacker News Reader

Congrats to everyone involved. This is a huge accomplishment and arguably many steps in the right direction.

We are very excited to get our hands dirty with .NET 5 sometime in Q1 next year. We currently run on .NET Core 3.1. I expect our migration from 3.1=>5.0 will be a total non-event, but we don't want to risk any regressions during our current crunch phase. Our migration from 4.7=>2.0 was the most difficult, but once we got everything off Framework and onto Core things have been going really smoothly with the incremental upgrades. Really hoping this trend continues indefinitely.

The only part of .NET 5.0 that has left me disappointed is the continued lack of polymorphic deserialization support in System.Text.Json - a la Newtonsoft.Json's TypeNameHandling enumeration. This is the only thing holding us back from migrating to this first-party dependency. I have already left feedback regarding our use case in the appropriate dotnet/runtime GH issue.

The biggest new features I am looking forward to are the performance enhancements surrounding startup time, GC, etc. Improved P95 latency is something that will be very welcome in some of our busier environments.

In terms of the overall package that .NET brings to the table, we couldn't be happier. Sure, VS could run a little smoother and some of the configuration/DI stuff can be very aggravating (at first), but overall its a fantastic experience.

>I expect our migration from 3.1=>5.0 will be a total non-event, but we don't want to risk any regressions during our current crunch phase

FWIW, I just did a find/replace across 66 projects for `netcoreapp3.1` => `net5.0` and it build and passed tests first try. There were a fair few new nullable reference type warnings though!

"Our migration from 4.7=>2.0 was the most difficult"

Would love to see a write up of your challenges / approach. Seems to be a big lack of write ups on this process that I'm sure lots of devs would appreciate!

I can give you a 500 word abstract here.

The core challenge was dealing with 3rd party dependencies (Nugets) relative to each project. We ultimately found that attempting to mix Framework/Core/Standard projects together was an excellent substitute for nightmare fuel. So, the happy path for us turned out to be to do it all at once and only use .NET Core project types throughout (DLL/EXE). Trying to convert your overall solution 1 project at a time hoping for some sort of incremental outcome is probably going to be more frustration than it's worth.

Assuming you bite the bullet on all or nothing, the next challenge will be: Is your code is even supported anymore? This is obviously going to vary wildly depending on your use cases. For us, the Microsoft.Windows.Compatibility shim was enough to restore 100% of the functionality (we rely on System.Drawing and DirectoryServices). But, there was also a lot of other rewrite to support new AspNetCore primitives, and we also moved over to Blazor for web UI (which is more of a rewrite than migration).

Thanks!

My team did this when we moved Bing.com over to .NET Core, but it's internal. I will see if we can make it public. The problem is there are some skeletons in the closest that are irrelevant now (some since NS2.0, more since netcoreapp3.1), so I wonder how informative it will be.

Would love to read about that, even if some parts are now already outdated or no longer as big am obstacle.

A site as large / complex as I assume bing is would possibly allay lots of our concerns and give us some concrete steps to move forward with.

Reply on news.ycombinator.com