Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons Learned while Converting from ASP.NET to .NET Core

stackify.com

Post reply on HN
Print view View original

61–70 of 79 posts

Re: Lessons Learned while Converting from ASP.NET to .NET Core

#61

Post by blitzd »

cm2187 wrote: post #28
awestroke wrote: post #25

Earlier quoted context omitted.

You typically still use IIS but only as a reverse proxy

So you set up the self hosted webservers on some non routable local IPs / ports, and set up IIS to map these IPs / ports to the external IP / hostname? Sounds complicated. You have two states to maintain and keep synced. The .net core servers and IIS.

It's done with Node.js and nginx all the time. Other than the initial configuration nginx is essentially stateless, and there's simple setups out there to automate the nginx config as well, with docker for example: https://github.com/jwilder/nginx-proxy.

Re: Lessons Learned while Converting from ASP.NET to .NET Core

#62

Post by DonnyV »

Hondor wrote: post #57

It's depressing to me that no talk about .Net Core even bothers to mention desktop apps. Winforms and co aren't even on the radar. I guess I'm stuck in the past.

Honestly if I had to do a new desktop app project. I would probably go with nodejs + chromium + html (front end) & C# + .NET Core (backend). You get total control over the UI without having to deal with WPF, plus it runs cross platform.

Re: Lessons Learned while Converting from ASP.NET to .NET Core

#63

Post by oblio »

sjellis wrote: post #47
oblio wrote: post #34

Earlier quoted context omitted.

.NET Core is slowly reimplementing/integrating all truly cross platform .NET classic APIs ( https://github.com/dotnet/core/blob/master/roadmap.md ). My guess is that at this point they didn't have the bandwidth to include what you're talking about in the first version but they will include it later on. Long term Mono is probably just going to become a sort of .NET "distribution" on top of .NET Core, it will include t…

In the last presentation that I saw, the line was that Mono would continue to exist as a full .NET implementation to support Xamarin mobile apps. The reason given was that .NET Core was scoped as a run-time for server applications, so no work had been done on making it run on mobile devices, whilst Mono has been used in production on those platforms for some time.

That seems valid now. But developing two runtimes in parallel doesn't seem that great of an investment. Plus there are already dotnet core contributions regarding portability, for example from Samsung, it seems reasonable to think that 2-3-5 years from now dotnet core will power Mono as well.

Re: Lessons Learned while Converting from ASP.NET to .NET Core

#64

Post by joneholland »

tonyedgecombe wrote: post #18
cm2187 wrote: post #15

For a website, not being able to manipulate files (no System.IO.File) or images (no System.Drawing) is a bit of a problem unless all you are doing is serve a database.

Using System.Drawing from ASP.Net was never supported anyway (although much of it did work). From https://msdn.microsoft.com/en-us/library/system.drawing.aspx "Classes within the System.Drawing namespace are not supported for use within a Windows or ASP.NET service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and ru…

System.Drawing actually wraps GDI win32 calls, so while it works, running it on a server would be iffy, and running it on non Windows would be impossible.

Now, they could reimplement system.drawing using a different backend per platform, but I don't think the demand is high enough.

Re: Lessons Learned while Converting from ASP.NET to .NET Core

#65

Post by jsgo »

Hondor wrote: post #57

It's depressing to me that no talk about .Net Core even bothers to mention desktop apps. Winforms and co aren't even on the radar. I guess I'm stuck in the past.

I could be totally wrong as I haven't really messed with it beyond dabbling, but from what I've heard, ASP.NET 4.? (6?) to ASP.NET Core is a pretty big shift which is why there's a lot of conversation around it. In fact, ASP.NET Core has a lot of changes vs the RCs (dipped toes into JSON configs, reverted back). Nuget has given up front end to bower now as well.

Perhaps that means desktop .NET Core is a more familiar experience? I'm not sure. But unless it is UWP or ASP.NET, I don't know how much we'll see coming as far as talk goes.

Re: Lessons Learned while Converting from ASP.NET to .NET Core

#66

Post by sjellis »

oblio wrote: post #63
sjellis wrote: post #47

Earlier quoted context omitted.

In the last presentation that I saw, the line was that Mono would continue to exist as a full .NET implementation to support Xamarin mobile apps. The reason given was that .NET Core was scoped as a run-time for server applications, so no work had been done on making it run on mobile devices, whilst Mono has been used in production on those platforms for some time.

That seems valid now. But developing two runtimes in parallel doesn't seem that great of an investment. Plus there are already dotnet core contributions regarding portability, for example from Samsung, it seems reasonable to think that 2-3-5 years from now dotnet core will power Mono as well.

You could be right, the current situation is unsettled, so I'm personally reluctant to predict anything much. The argument for Mono seems to boil down to the MS teams not having enough capacity to get .NET Core production-ready for mobile whilst doing everything else.

I'm going to be learning ASP.NET Core, but not even think about possible production use until after the next release. We will probably continue to avoid .NET for mobile, and I would not consider Mono for any other use case.

Re: Lessons Learned while Converting from ASP.NET to .NET Core

#67

Post by shanselman »

jasonkester wrote: post #38

Just from the examples on this list, it sounds like the only winning move is not to play. I have a handful of sites running ASP.NET 4.5. Migrating them would cost an unknown amount of time and require substantial rewriting of major components (such as all data access). It might not even be physically possible to do, given dependencies on libraries that are still 4.5 only. It sounds like it would also kill our build p…

I feel like you're conflating .NET Core and ASP.NET Core. You can use ASP.NET Core 1.0 on .NET 4.6.x today. If you don't need cross-plat, that's cool. But you have the full API surface area you have today, plus some significant new features and perf improvements.

Re: Lessons Learned while Converting from ASP.NET to .NET Core

#68

Post by shanselman »

Hondor wrote: post #57

It's depressing to me that no talk about .Net Core even bothers to mention desktop apps. Winforms and co aren't even on the radar. I guess I'm stuck in the past.

Because Core is a server-side framework. WinForms and friends run on full framework.

That said, check out Avalonia and some other OSS experiments.

Re: Lessons Learned while Converting from ASP.NET to .NET Core

#69

Post by blakeyrat »

taspeotis wrote: post #13
blakeyrat wrote: post #9

Earlier quoted context omitted.

It's only "wed to GDI+" because the current implementation is. Nothing's preventing them from implementing a cross-platform System.Drawing. There's no magic involved in what it does that requires GDI+. I find it unbelievable that they would even consider releasing this without System.Drawing or equivalent being available.

.NET Core has neither WinForms nor WPF. It's very much focused on web applications. System.Drawing might be useful for ... one in ten? web applications. And they have released it, and it's getting plenty of traction. Take a quick scroll through here: http://referencesource.microsoft.com/#System.Drawing/commonu... To re-use System.Drawing Microsoft would need to re-implement all those methods in a cross-platform, bug-…

I have not worked with a website yet that didn't have a need for image-handling code, either to resize uploaded images, handle avatar generation, draw charts (although I suppose that's moving to client-side for newer apps), etc.

Frankly, the thing I liked best about the whole .net ecosystem is that it didn't go for the open source "release early, release often, release incomplete and buggy" philosophy. I'm just very disappointed to see Microsoft going in this direction.

If Microsoft isn't providing a rock-solid, feature-ful framework with impeccable backwards compatibility, who will? Nobody will.

Re: Lessons Learned while Converting from ASP.NET to .NET Core

#70

Post by blakeyrat »

jamessouth wrote: post #12
blakeyrat wrote: post #11

Earlier quoted context omitted.

That's great, but it belongs in the framework. I'm incredibly disappointed by that decision.

I do agree. When I spoke to one of the guys there a while back though they said they simply had too much on their plate at the time and were hoping the community would kick in and help.

Look. People are voting me down, probably because they disagree with me. Let me explain where I'm coming from.

There's two types of programming ecosystem:

1) The wild west world. where there's no good tooling (IDEs, debuggers, etc), all libraries are provided by hundreds of random individual developers and of varying quality, vital tools (such as build systems) are a constant juggle of whatever's trendy at the moment, etc.

2) The world where there's a single comprehensive framework of extremely high compatibility managed by a single party, where tooling is excellent, where backwards compatibility is of paramount importance, and where everything you write is on a solid foundation that's not going to move out from underneath you.

If you want environment 1), you have a ton of choices. You can use Node.JS, you can use Python, you can use Ruby, you can use GoLang, Java, etc. If you want environment 2), you have exactly one choice: .Net. And in a year, based on everything I'm reading about .Net Core, you'll have zero.

The only saving grace is, being Microsoft, I can be confident that the .Net 4.5 stuff will work for at least another decade. Even if it's not the "trendy new hotness".

Maybe I'm a freak outlier, but I much much prefer the old Microsoft that wouldn't even think about releasing the product until it was 100% complete, tested, stable. I think they're moving in the exactly wrong direction, and driving full speed away from everything that made .Net such a great platform in the first place.

-----

Every time I've had to use a language where a lot of functionality is provided by "the community", it's been a constant cascade of buggy and badly-designed libraries. "The community" doesn't test their stuff before releasing it. Or the library works for the one tiny purpose it was written for, but isn't generic enough to be useful to anybody else. It's nobody's job to ensure quality or completeness, so it simply does not happen.

I'd rather have good code, even if I have to wait longer, than code from "the community".

Post reply on HN