Hacker News Reader

Comment by CoryMathews | Hacker News Reader

With very little way to easily convert a large app.

That is the exact opposite of my experience.

Outside of UI components which MSFT is getting to, they’ve worked very hard to make the transition as easy as possible.

If anything, the backwards compatibility has led to making some things worse, IMO, e.g. switching from the simple JSON based project file format they had to the XML based .csproj style one, which I’m pretty sure was done to be able to support .Net framework projects.

Classical .NET Framework CMS like Sitecore are now API first, and migrating away from .NET into a mixture of .NET, Java and JavaScript offerings.

Back in .NET Core 2.1 days, I had a two months project to port an application from .NET Framework into Java and deployed into Red-Hat Linux, because if a rewrite was required, then better away from Microsoft ecosystem, as this specific company already had enough from rewrites.

This is how well some customers have been taking the .NET Framework => Core migration.

What are you specifically referring to? .NET core has pretty much everything and more than .NET Framework did.

In my personal experience, and that of colleagues, it was a pretty smooth experience. We mostly had issues due to some API changes here and there, and of course ASP.NET

It’s a different story when it comes desktop applications.

Outside of WCF it's not that different. I agree that the removal of WCF feels like a huge gut punch, but if you were following WCF tenets all along and had nice separation of your Data and Service and Operation Contracts it really shouldn't be that hard to drop all your WCF Binding wizardry and write new implementations of your contracts (interfaces) against HTTP REST or gRPC or GraphQL or Raw UDP Sockets or whatever your heart desires as your next communication tool, then dependency inject those implementations like any other dependency injection.

Are you going to do that for free?

Someone has to pay for the contracting project to do that.

Also Microsoft themselves have stuff that is .NET Framework only on VS plugins, SharePoint, Dynamics and SQL Server.

The point I was making was that WCF done well is a lot fewer billable hours to rewrite to use anything but WCF than people often think it is. I've done those rewrites before, and WCF is one of the few frameworks in existence that went so far out of its way to try to not leak abstractions that unless you were dependent on some truly baroque bindings, it's easier than most people seem to think. I've heard a lot of projects avoiding the .NET Framework to .NET 5+ transition solely because of WCF and how much work they think it would be based almost more on sunk "debts" feelings of existing tech debt from debugging WCF bindings/magic rather than maybe seeing it for what it is as more of a "unit testing DI exercise" where you've got existing test mocks (WCF) and just need a clean new implementation of existing interfaces.

Sure, but someone has to pay for that work, and many places don't have developers in-house, which means someone has to feel motivated enough to do a request to finance.

Reply on news.ycombinator.com