Hacker News Reader

Comment by mjfisher | Hacker News Reader

Can anyone closer to the .NET community than I am comment on the wider adoption of .NET core on standard line of business applications?

The few places I know that work with .NET are a long way from migrating yet. Are there any similarities with the Python 2/3 port? I imagine language level compatibility makes the transition much easier.

View on HN

Last 5 startups have used .NET, all of them have migrated and all new projects are on .NET Core. Every major dev shop I know starts new projects on Core.

It's mostly legacy and enterprise apps but it wasn't until .NET Core 3.0 (released last month) that it was viable to migrate everything perfectly anyway so it'll take time for that to filter through.

This is nothing like Python 2/3. .NET Standard has been out for a while and all the major libraries are compatible with both runtimes, and that now includes desktop APIs too.

If you have one product (like startups) it is easy to port. You have, in relative terms, nearly unlimited budget and incentive to stay on the latest and greatest.

If you work in a place where you develop many products for many clients, budgets are lower and you have much to maintain and develop. Porting is in my experience almost never done, because there is no business case to justify it.

> adoption of .NET core on standard line of business applications

This is rather anecdotal but in my little area of the world there is little. .Net is moving too fast and too impractical to really be worth it on enterprise these days. The main problem for us is the libraries for handling thing like data-formats.

Linq-to-sql is still better than Entity Framework from a time to market perspective, but both of them are really, really slow. XML interpreters reminds me of learning JAVA back in the early 00’s, they execute well enough but you need two million lines of code to do what Python does in 20. Working with SOAP and SAML often requires you to build additional parts on top of the fairly terrible APIs and some older stuff, that used to be in .Net has simply disappeared into unmaintained third party libraries. Connecting up Microsoft’s own System Center (2012) has gone from being a simple service reference to you having to build your own library because Microsoft moved to Azure. Even official libraries for AD integration are half finished and require you to build your own service APIs to look up stuff like unique IDs.

.Net Core is really good at building CRUD services and really bad at everything you actually need in Enterprise situations because almost nothing in the real world actually requires that.

Luckily both Microsoft and Azure are treating things like Python as first class citizens both on Windows Servers and in Azure. Their own Powershell has become a much more powerful tool than C# has as well, so it’s not like I dislike Microsoft at all, it’s just that .Net has spent the past decade becoming less and less useful for what we need it to do.

I work in a .NET shop that has done a massive push to port all of their .NET Framework code to .NET Core. I joined in at the end of it, and only helped out porting 1–2 of the central applications, so I don't know what the internal struggles were like during the main effort.

What I do know is that everyone is relieved now and incredibly happy that they did it. Hosting the applications on Linux is so much easier, and they appear to have twice the performance as well. Still not sure why, but it's definitely correlated with hosting them on Linux.

I've been using .Net Core in production since its initial release. First company was a well known AAA games studio running backend micro-services in docker containers using .Net Core. Currently at a unicorn FinTech (2B valuation) where literally every backend service is .Net Core 2.2 (soon 3) running in docker containers and the containers are orchestrated in AWS ECS. Works amazingly.

For our customers, we still don't bother with it beyond a couple of toy projects.

Most of our customers are doing transitions to .NET Framework 4.7.1 and 4.7.2 from 4.5 and such, .NET Framework 4.8 still isn't a viable option for them, and plenty of in-house, and third party libraries they depend on aren't yet on .NET Core.

By .NET 5, they might start moving into Core infrastructure.

And for those teams the multi-platform part of .NET Core isn't that appealing, because UNIX deployments are already covered by the Java teams anyway, with products whose .NET counterparts are yet to be 1:1 available.

Serious question, what makes 4.7.1/4.7.2 viable, but 4.8 not? Major breaking changes?

Validation through IT images.

Until IT certifies server images with .NET Framework 4.8, it doesn't get green light for new projects.

So is the nature of enterprise computing, I know a couple of customers still using Red-Hat Enterprise 5 on their servers.

Ah gotcha! Fun times!

I recently switched companies from one .Net shop to (kinda, sorta) another.

The previous one had a big product based on a COM-turned-WCF architecture for years. WCF is dead/not a thing on .Net core.

The one I'm currently looking at just recently (last year-ish?) migrated from idk what to .. a big pile of WCF. I don't think that will every migrate either.

(yes, there are ways to replace WCF if you - and these examples don't require that - ignore transaction support, but it's a nightmare to migrate as far as I can tell .. and you end up with a product that looks exactly the same to the customer)

I've dabbled in .Net core since its inception and would love to use it more, but the whole WCF story was usually a deal breaker for usage at work unfortunately.

We went from NetFramework->NetCore 2.x->NetCore 3.x with very few difficulties. The hardest phase was NetFramework->NetCore 2.x because of the differences in dependency resolution rules (e.g. no binding redirects allowed).

We ultimately restructured our projects a bit to dramatically simplify the number of points of touch for managing 3rd party nuget versions. We now have a common platform core (targeting NetStandard 2.1), with specific application implementations consuming it and targeting NetCore 3.0. Mercifully, we were able to capture 100% of our 3rd party dependencies into this common platform core project, so we no longer have to worry about mismatches between our own internal projects or nugets. The picture for us is: (3rd party libs)=>(shared platform library)=>(specific application). This seems to work out really well, and with the newer AOT/linker capabilities, we are resting easier knowing that we can shake off some unused bytes if our distributions start getting a little chunky due to this approach.

Also, the .NET compatibility pack is a life-saver for anyone stuck using System.Drawing or DirectoryServices. Those are our only 'difficult' windows dependencies, and we expect to be able to replace these with cross-platform alternatives next year.

We're using it for a game server that interfaces with a Unity client. Works damn well. As someone who makes games, that's a standard business application for me, but YMMV.

Have you run into any difficulties with the GC, or are you already playing around with some of the configuration options here?

No issues but the use case is an internet hosted dedicated server so as far as the client is concerned network variance mask any GC concerns.

Here's the customer showcase on the .NET site (with links to more at the bottom of the page). It lists some of the biggest enterprise adopters: https://dotnet.microsoft.com/platform/customers

Of course, lots of Microsoft services run on .NET Core. Last year, the Bing team talked about how their move to .NET Core 2.1 gave them big performance jumps here: https://devblogs.microsoft.com/dotnet/bing-com-runs-on-net-c...

(disclaimer: Microsoft employee, .NET team)

I've been using .NET Core since RC1 and first deployed to production when version 1 was released.

From what I've seen, all new projects are being done in .NET Core, and legacy apps are not really being migrated over. .NET Core 3 might fix a lot of these issues, but in the past there were a lot of library unavailable in Core that you could only use in Framework.

I haven't had a recruiter mention Framework in over a year now, I don't believe. It's all Core now.

We are mostly a web SASS that was traditionally written in C# .Net Framework/ASP.Net MVC. All of our new code is .Net Core/React we are trying to move toward Docker and Fargate (AWS serverless Docker). We really want to get off our dependency on Windows.

In general, .Net framework is legacy. I see very little green field development being done with .Net framework.

Language level compatibility doesn’t help. There are so many differences between ASP.Net and EF6 between .Net framework and .Net Core that it isn’t an easy lift. But, MS did the right thing by not worshipping at the alter of backwards compatibility for a change.

We're using .NET Core for a few new projects. Our situation is a bit different as we build bespoke software for a wide range of clients. We're pretty satisfied with it.

We have 3 .NET Core apps already in production in an enterprise environment but all were new projects.

We have not migrated the 4-5 .NET apps we have and don't see a pressing need yet.

We are currently working on a social game app and proptech for a startup, both in .NET Core.

The game is Unity so C# on the app and .NET Core on the backend is nice to match up, common code.

The client on the proptech is Microsoft focused so they chose Azure/dotnet/C#/Xamarin.

Initially the proptech drawing/document app was on .NET Framework 4.6 and had the app running with Xamarin on Android + iOS when the app was to run on Android or iOS tablets/pads.

However, now the project uses Surface Books with touch/pen and Windows Ink so we went to .NET Core for UWP and that is the main app target now though it still runs on iOS/Android. Xamarin is quite nice for business apps that have to integrate to dotnet or any backend really. Lots of great developing and testing tools.

We have updated from .NET Core 1 to 2 to 2.1 and 2.2 and will be going to .NET Core 3 soon, by end of year.

The web app, apis and app are all .NET Core + Xamarin and it is nice. I have been doing .NET apps since 2000 along with Python, PHP and Node apps for interactive / promotional / game / drawing / rendering products and .NET Core is pretty clean and I love the nix implementations as well.

.NET Core 1 + updating to .NET Core 2 was a little rough reminiscent of the .NET 1.0 to .NET 1.1 and 2.0 initial start, lots of breaking changes, but .NET Core 3.0 is pretty solid and slowing down on massive changes, libraries and frameworks are almost all on it for what we use including IdentityServer4, SignalR, Xamarin (Standard) and more. The list of breaking changes is small this time [2].

There is the typical .NET base library depth that random deep errors you have to hunt down, and the thousands of libs/packages, but for the most part it has been not much more than speedbumps. .NET Core comes with lots of great security features for APIs/apps as well which helped us with compliance/security scans [1].

Now that .NET Core is pretty solid, and the linux/nix implementations and tools are far along, I expect with the ease of Azure, for Microsoft to really take some ground.

Microsoft ecosystem is a complete setup, from Visual Studio/Code to Azure to dotnet to Xamarin and UWP to Teams/Office and Surface Books with Windows Ink and even CI/github. They have retooled quite nicely, I left .NET in 2007-2010ish when developers took a backseat and they got it handed to them with mobile, but they are developer focused fully again.

Side note: I also love the Surface Book with the disconnecting screen and Windows Ink. My current machines are massive custom PC, massive Mac Pro (cheesegrater from 2013 that I love) and Macbook but seriously considering going Surface Book and probably just going to be updating/building on a Mac Mini for our Unity games instead of upping to the new cheese grater as it is the cost of a car or major home renovation project for the specs I want.

[1] https://docs.microsoft.com/en-us/aspnet/core/security/?view=...

[2] https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core...

Reply on news.ycombinator.com