|
.NET Core.
I just really love the API, the startup class, the built-in DI, JSON based configuration, EF Core...
I recently needed some WPF application for an old SOAP connection with a third party, but .NET somehow felt clunky after years of .NET Core.
Luckily I could still use all of the .NET Core libraries I became used to, like Entity Framework Core.
.NET Core is also the future, with .NET merging with .NET Core in .NET 5.
|
|
|
|
|
.NET Core just suxx. LOO LATE try to "make things properly". Key is "late", not "properly".
And now, when I need adequate website with simple, upgradable code, I use ASP.NET 1.0; Yes, with all those "code islands" and "includes". It's guarantee ANYBODY come to my code and easy improve it w/o learning Blazors-shmazor, Node, etc.
|
|
|
|
|
I agree...
All this stuff about MVC and ASP.NET Core is juts a return to the days of Classic ASP but with far more complexity. And as a result, there are more errors and design mistakes in current web development. Most professional technicians find the web development environments of today overwhelming with all the frameworks and tools that constantly keep changing; especially for an underlying architecture that hasn't really changed since the 1970s.
If anyone really believes that the latest developments with MVC and ASP.NET Core is some type of evolutionary process, it isn't. The MVC paradigm was actually designed in the 1970s as well and has been the crux of the Java Community since Java appeared on the scene.
Its use by Microsoft was merely an adaptation of the .NET Monorails Project from Castle Software, which was freely available to everyone in the .NET Community. However, few developers left WebForms for it until Microsoft produced its own version as ASP.NET MVC.
Today's web environments in the .NET Community are predicated primarily on JavaScript; a language that was never designed to support what it is being used for and one that has never been refined to do so. VB Script back in the day was always a far superior front-end development language for web pages but since Microsoft never open sourced this excellent product, it lost its prominence.
Recently, Microsoft has begun to introduce C# for front-end development. However, again, this is just a reiteration of the capabilities of the original VB Script language but with more capabilities.
I developed web applications for close top 20 years in my career and nothing today can compare to the excellence of the WebForms model despite its flaws.
People who complain about it simply don't know how to design an efficient WebForms application and often complain about its bloated View-State. Well, you can simply turn it off if you don't want it but most don't since it is convenient.
Instead, with MVC developers write support code to maintain their web page states. As a result, in this sense all MVC does is shift the work load. A well designed WebForms application can compete with an equally well designed MVC application.
However, today, everyone is submerged with the details of writing fine applications instead of concentrating on the design of such applications. This has been a vendor produced mania to simply use more and more complexity when it is simply not needed...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
TL;DR:
Core, mainly for performance (start-up time is vastly reduced, Kestrel handles http requests really, really fast), but also for future-proofing, and, ironically enough (because others have stated !Core for the same reason): so other devs can deal with it.
For the more patient / bored: strap yourself in! Some of this is opinion, but it's opinion backed by experience, so there's that...
If you're still pumping out webforms, well, good for you (and good luck with unit tests -- the best strategy I had there was to move all my logic out into another assembly and have every webform callback call into that, so at least I could provide code with some level of testing over which I had confidence), but the truth is that all the new kids won't be writing webforms. So by yelling them off your lawn, you may secure your job and just cause pain for your company down the line. You're also wasting CPU cycles and bandwidth, making your sites only really work properly on low-traffic LANs where massive postbacks and slow page-loading aren't a problem.
Ugh, WebForms and the giant postback state. Should make any web dev shudder.
ASP.NET core also has a more sane startup routine than classic MVC, with the whole pipelined approach baked in from the get-go (yes, you can do filters in ASP.NET MVC !Core to approximate a lot of this, but it's way less elegant or simple). This will be familiar if you're hiring any Node devs who have dealt with Express -- so again, future-proofing your app against being trashed because no-one can work on it.
In addition, ASP.NET core is a breeze to get running on a Linux host (good luck with WebForms; I guess you can go with mod_mono and Apache, but really, why would you want to when Kestrel is fast, light and doesn't require all of Apache and that setup?). Running individual asp.net core apps and using something like nginx for reverse-proxying means you can isolate apps completely from one another and perform fine-grained control such as rate limiting above the application level.
Linux hosting is cheaper than Windows hosting, as well as arguably more performant (when comparing similar hardware, of course) and harder to crack than a Windows server. And doesn't perform performance-crippling updates during peak hours of traffic on that machine :/ (happened recently on our machines, and we can only block off 12 hours of the day as "peak hours", when we really need about 15; unless there's some hidden config I'm missing (probably am)).
I don't hate Windows -- I feel that the platform should be a choice that's made in spite of the application technology, not because of it. Choose Windows if it suits your org / budget / whatever. Choose Linux for the same reason(s).
And to respond to a few of the other comments here:
[1] C# != .NET.
C# features are supplied by Roslyn performing compile-time magic. Which is why you can get these features from any reasonable modern msbuild (read: 15.3+, iirc) and a nuget package: the deprecated Microsoft.Net.Compilers or the newer Microsoft.Net.Compilers.Toolset. If you target an older runtime (eg dotnet core 2.1) with a newer compiler (eg out of the dotnet core sdk 3.1 or via one of the aforementioned packages), your language features compile just fine. Roslyn is rather nifty /2c
[2] I'm not particularly fond of default interface implementations (aka traits, or, as the peeps in the js world have called them for ages: mixins). I think the feature will cause the confusion that was originally intended to be by-stepped by not allowing multiple inheritence (which made me sad when I came to .net from c++, but I got over it).
I'm waiting for the crash-and-burn stories to arrive. Or perhaps they won't, and we've all learned not to do multiple inheritence from a bazillion useful abstract bases? 
[3] DNC 3.1 is LTS (contains fixes and performance enhancements over 3.0 -- and a feature removal too!) so that 3.0 can be shelved and people can upgrade long-running linux boxes without having to chase dotnet 5.0 when that drops (allegedly at the end of the year). Some sysadmins are quite cautious and would prefer to wait for new tech to break on other people's machines first.
And, of course, the caveats (which make any answer boil down to "it depends"):
1. Are you sure that your deploy target has dotnet core? If not, can you install it? Some cranky admins will only give you an old box and refuse to install new tech.
2. Do you have to use some legacy nuget package (or, gasp checked-in-to-your-repo assembly!) for non-trivial or required functionality? If you have to, at some point, rely on using a Framework-based assembly, your options just got a lot slimmer.
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you don't like doing
In order to go on living
That is, to go on doing things you don't like doing
Which is stupid.
|
|
|
|
|
Seems that some people got stuck in the past with WebForms..
I have been working with ASP.NET Core from day 1. Had to upgrade my projects from ASP.NET MVC 5 to ASP.NET Core 1.0, 1.0 to 2.0, 2.0 to 3.1 and whatever in between, if there were any breaking changes you simply made updates according the documentation or folks who constantly blog about .NET Core.
I only work on .NET Core projects now.
I have no other single complain about ASP.NET Core. Obviously if you don't need to support any outdated technologies then .NET Core is a good choice.
People always complain if they don't know how to do the things and then they are comparing how it was before.
At this time, I would never start project on ASP.NET WebForms or ASP.NET MVC 5. I wouldn't want to work with this outdated technologies, please don't let me work on these projects but I am happy to upgrade anything from these to ASP.NET Core.
Once you start digging properly in ASP.NET Core then you would see the advantages and possibilities as mentioned by @"Davyd McColl".
|
|
|
|
|
Blazor. Period. It uses ASP.NET Core, and no JavaScript code need be written.
Blazor server-side (if latency is not an issue, such as users on the other side of the world), or (coming in May, and available in preview now), Blazor client-side. Client-side uses the webassembly engine, not the JavaScript engine, in the browser. You can change your Blazor application from server-side to client-side with a one line change.
For new projects, or adding new pages to an existing ASP.NET Core web app, I will choose Blazor.
|
|
|
|
|
The long and short of it is that it depends on your environment. We use WCF services - a lot. Our current code base is ASP.Net web forms, and is way to javascript-dependant for my personal tastes. Add to that the fact that they want to move to TDD, and...
I recently took on the task of creating a project template for new web apps, and had a choice between going with MVC5/DoNet Framework, or using DotNet Core. I was FORCED into MVC5 because of the WCF stuff. We actively avoid using Entity Framework (or any other ORM you might care to mention) because ALL of our database interaction is done with stored procs, and to be quite blunt, EF doesn't really care for that approach, not to mention its propensity for screwing up entities when something changes. Add to that the web server hosting the apps requires some significant configuration changes that, quite frankly, are probably beyond the abilities of our web admins.
I really don't know how all of this is going to work out, because we're migrating EVERYTHING to the cloud.
It's going to be a freakin mess...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
You mention "no orm", and the troubles with EF (I understand -- it's an 80% fit, meaning it fits well about 80% of the time). We also perform our database queries at the sql level (few procs, mostly statements, but the same idea) -- if you haven't already, check out Dapper, which will let you take a step back from pure ADO without losing the lower-level control.
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you don't like doing
In order to go on living
That is, to go on doing things you don't like doing
Which is stupid.
|
|
|
|
|
Our ADO stuff is almost as generic as EF. I'd like to completely get rid of EF but haven't found a decent guide that describes how to do it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Ok, I have a guide:
- Uninstall the EF nuget packages
- Fix compilation errors, getting all your tests to pass again.
Of course, if you're not into having an automated suite of tests for your code, you're probably going to find this more difficult than it has to be.
If you say that getting the money is the most important thing
You will spend your life completely wasting your time
You will be doing things you don't like doing
In order to go on living
That is, to go on doing things you don't like doing
Which is stupid.
|
|
|
|
|
There is nothing of value in EF if it requires me to use the rest of EF.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I like the way core does model binding better, but deploying changes is much easier with MVC 5. With core, I had to stop the IIS application pool, then deploy then start it again.
Also MVC 5 allows you to change the .cshtml on the server if there is an urgent change, and you don't want to boot everyone off the site for a minute or so.
All things considered though, I'd still say core.
|
|
|
|
|
If you are mugged by a rabbit, it it just a bad hare day?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
If you are mugged by a donkey, will he own your ass?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
[must be too tired to think, but] this came to mind: Monty Python The Holy Grail - The killer bunny - YouTube[^]
after many otherwise intelligent sounding suggestions that achieved nothing the nice folks at Technet said the only solution was to low level format my hard disk then reinstall my signature. Sadly, this still didn't fix the issue!
|
|
|
|
|
I think I need to silly walk away from this thread.
“The palest ink is better than the best memory.” - Chinese Proverb
|
|
|
|
|
That's a pretty bunny posting - a rabbit of humor.
Ears to you, lad !!
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
No, it means you need to get one of these[^].
I've got two, and no rabbits.
Software Zen: delete this;
|
|
|
|
|
If you get mugged by a giraffe, go for the throat.
|
|
|
|
|
That's a bit of a stretch!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
A snail gets accosted by a tortoise and when someone asked her what happened she replied; "the whole thing happened so fast I didn't have a chance to see anything".
Monday starts Diarrhea awareness week, runs until Friday!
JaxCoder.com
|
|
|
|
|
Not if it were a Rabbit Barber and it shaved ya bald.
The best way to improve Windows is run it on a Mac.
The best way to bring a Mac to its knees is to run Windows on it.
~ my brother Jeff
|
|
|
|
|
well we all know reviews are not worth wasting the pixels they are displayed on,
and sometimes it's good to seek serious expert opinions,
but when genuine experts are in short supply why not ask them clow folks in the lounge?
-------
we all know chrome is a CPU hog (this is where the folks with 8th+ generation CPU's claim otherwise)
- has anybody found (tried? tested??) if the new edge (the chrome versions with ms cool aide) same / better / worse?
after many otherwise intelligent sounding suggestions that achieved nothing the nice folks at Technet said the only solution was to low level format my hard disk then reinstall my signature. Sadly, this still didn't fix the issue!
|
|
|
|
|
I have both installed on a system (not the one I'm currently writing this on). I just launched both side-by-side, without loading any page (both are essentially showing about:blank).
Task Manager shows 8 instances of chrome.exe were launched (ugh!) vs msedge.exe's 7. Initially Chrome had 10, but after a few seconds that dropped down.
Given this, how do you even propose to come up with representative figures for a decent benchmark? FWIW, Task Manager's Process tab shows Chrome eating up 205MB of RAM, and Edge is at 110 (and as I'm writing this, I've just watched those figures drop to 180 and 78, respectively).
I don't know if anything meaningful can be extracted out of this.
Between that, the 12 instances of RuntimeBroker.exe and what must be 70+ instances of svchost.exe Task Manager is currently showing on this Windows 10 machine...is it any wonder that a system with 4GB of RAM is constantly paging nowadays? This particular system--an Intel NUC--has 16 and is snappy and responsive, but I know plenty of people who are still using systems with 4GB or even less.
I realize I haven't answered your question in the least. I'm just relaying what I'm looking at right now and shaking my head. "Throw more RAM at it" needs to stop being the solution to everything.
|
|
|
|
|
dandy72 wrote: I don't know if anything meaningful can be extracted out of this.
Really not. The way windows works now, they might as well use random program names and numbers, for all the good Task Manager does you when you're trying to diagnose problems.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
