|
Just curios. For you ASP.net developers out there. If you were to start a new project, which would you use and why?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
To answer your questions, "it depends", and "because". 
Microsoft are pushing .NET Core as the future, and won't be making any further changes to the .NET Framework. It's not going away any time soon, but the features and performance will never improve, and any bugs which don't impact security will never be fixed.
You can get some C# 8 features to work in a .NET Framework project by manually editing the project file; others require additional NuGet packages; and some won't work at all. I think some of the new features are terrible - particularly the tangled mess that came out of "default interface methods" - but without upgrading to .NET Core, you probably won't be able to take advantage of any further improvements to the language.
But at the same time, we regularly need to display or export SSRS reports from our applications. I have yet to find a reliable way of doing that which would work in .NET Core.
We also occasionally have to interact with a third-party ERP system which uses a WCF interface with a custom closed-source message format. I have yet to see whether it's possible to make that work in Core.
I don't think we've yet reached the point where newer libraries are dropping support for .NET Framework. Microsoft tried it with EF Core 3.0, but changed their minds for 3.1, which caused a complete mess. Having said that, it's probably only a matter of time, especially with ".NET 5" allegedly slated for release later this year.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Sounds like it would be OK to use .Net Core for newbasic web apps. But anything legacy would probably require .Net Framework.
Richard Deeming wrote: I think some of the new features are terrible - particularly the tangled mess that came out of "default interface methods
I totaloly agree here. What a terrible idea.
Thanks for your input
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Yeah, why is 3.1 a long term support version if they are going to .Net 5 right away?
I haven't seen a new C# feature in a while that was much of an improvement and most of them obscure the readability of the code.
I find it funny that they are pushing WPF with no compelling reason. I tested and a WinForm app calls .Net Core 3.1 assemblies just fine.
|
|
|
|
|
Michael Breeden wrote: Yeah, why is 3.1 a long term support version if they are going to .Net 5 right away?
Because they need a version for customers who're unable/unwilling to upgrade framework versions every few month (3.1 LTS) while they work on the next version for early adoptersunpaid beta testers (5.0).
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
|
We have a butt-load of WCF services. We won't be switching over anytime soon.
".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
|
|
|
|
|
Given where you work, I'm amazed you've managed to drag them up as far as MVC. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Caveat - we *still* haven't started active dev work with the new template, so I'm not really counting it yet.
".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
|
|
|
|
|
Neither. I've been using ASP.Net Webforms for 15 years but am still learning lots. I've never come across anything I needed to do with it that I couldn't. I'm at an age where I'm not about to start learning a complete new paradigm, library, framework...
It's unlikely that I'll be starting any new projects at this point, other than "hobby" or personal projects, and for them WebForms will do the job admirably. However I do acknowledge that as Microsoft has declared there will be no further development on the WebForms front and that there will be no extensions to .Net Framework, it's inevitable that "the world" will move away from it to .Net core and MVC. I've just finished a task working on a Classic ASP site running on Windows 2003. Yes, it's in production and it is a core Line-of-Business application. Software hangs around for a lot longer than we might like, and that works in two ways. First it means that support for WebForms is unlikely to disappear any time soon; currently most Windows hosting companies support Classic ASP and ASP.Net Webforms, whilst only a minority have .Net Core fully available. So in one respect I'd have no worries about building a new WebForms application, on the assumption that "most" websites only last around 5 - 10 years or less before a rewrite. However my recent experience confirms that some can last a lot longer than that, and I'd be wary not so much about lumbering a client with a technically obsolete application, but rather leaving them with one that no-one could - or more to the point would - provide support for. And that is the crunch issue, really. There are lots of developers who know Classic ASP, for instance - but very few who are willing to take on Classic ASP projects, because they don't add to the CV, they don't build new skills, they don't give the buzz that being at the "cutting edge" brings.
So as others have said - "it depends". I don't know the detail differences between the options you give, but the same considerations apply. What is the realistic lifetime of the application? Is it for a 3rd party who might need to find alternative support in the future? Where is it to be hosted? Plus other commercial considerations - is choosing .Net Core at this time limiting the potential hosting options, and therefore a potentially more expensive solution? Is there a learning curve for the developer(s) that will extend development timescales and costs, potentially negating the project's benefits?
You're "just curious", but I suspect you have a potential project in mind. Just apply the usual technical and commercial criteria that you would normally use for determining the best implementation route.
|
|
|
|
|
Thanks
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Derek
It is quite refreshing to find someone else who is a Web Forms fan !
Tom M
|
|
|
|
|
There are dozens of us! Dozens I tell you!
My issue is that webforms is super easy to get going. If you are building a site for hundreds or maybe even just dozens (super common to have a $50MM company only have 2-3 AP people, 5-15 salespeople, etc) the performance issue of postbacks isn't really a concern in 2020 with 12-core processors and 4G. And if you have 1-2 programmers, they are probably responsible for all the code. So separation while nice, isn't as beneficial as many make it out to be. Testing too. Most of us coding for 100 internal users aren't running unit tests for the webpage I just created that contains a gridview and a details view. It's basically a glorified report. Rowbound processing is easy and fast. And javascript libraries are easy to add to the pages for additional functionality and reduced postbacks.
MVC seems like overkill to give my users a report of the past due invoices.
|
|
|
|
|
I've coded ASP.NET WebForms forever and find them to be easy to implement and expand. Turned over most all our front end work to 2 talented web devs, they make everything mobile friendly and I'm happy doing the backend, loading controls programatically, etc. Did a bit of MVC work and found it overly complicated with not much return on that investment.
|
|
|
|
|
.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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
