|
I think WPF is great
|
|
|
|
|
I forgive you child
|
|
|
|
|
Agreed. I've been using WPF for 10 years now, and vastly prefer it over any other UI technology I've ever used.
Admittedly, I've got some pretty vivid scars from the learning process, but still...
Software Zen: delete this;
|
|
|
|
|
I try to forget the learning process. It wasn't fun
|
|
|
|
|
I think the worst part for me was more of a .NET issue than a WPF issue. About three years after I started using C#, .NET, and WPF we noticed a chronic memory consumption problem in my application, which acts as the front end for our product. We bought .NET Memory Profiler from SciTech, and I spent ten weeks cleaning up dangling reference issues. Most of them were due to programming habits of mine that were best practices in the C++/MFC/Win32 world, but were inadvisable under .NET.
Software Zen: delete this;
|
|
|
|
|
Was expecting some pro WPF sounds, you people are so easily provoked
My colleague uses the SciTech profiler too, and is very enthousiastic about it, he's a bit more into low level programming than I am currently.
|
|
|
|
|
RickZeeland wrote: you people are so easily provoked I think WPF fans are a tad sensitive. WPF has a deserved reputation of a steep learning curve and some over-engineered features. Add Microsoft's lack of love on top of that, and I think you can understand our frustration with the unenlightened.
Software Zen: delete this;
|
|
|
|
|
Outside of navigation headaches and load times on complex pages and slower systems (I eventually wrote my own godclass to handle it), I mostly liked WPF. I recently did a UWP app and it felt like they'd smoothed out a lot of the crap I raged about a year prior with WPF. Too bad they don't seem interested in backporting enhancements to WPF, or fully unshackling UWP apps for non-store distribution and/or cases where the sandboxing precludes doing something the apps needs to be able to do.
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
|
|
|
|
|
What does any of this have to do with .NET Core or the survey?
|
|
|
|
|
Simple. Core is the .net "that runs everywhere".
And as I stated above, on backend only there is no need for something like that.
|
|
|
|
|
How could I miss that...
You could run your web application on Linux, of you're into that sort of thing.
I'm using .NET Core for web applications on Windows servers.
Overall .NET Core just works really great, sometimes better than .NET
Except for EF Core, which can be a real PITA
I'm mostly working with MongoDB now though, so that solves that problem
|
|
|
|
|
We're switching some old projects to core, and new projects are starting in core.
|
|
|
|
|
How easily are your migrations going? Mostly wondering how often you're running into API not supported, or library not available for .netcore type issues and how hard/timeconsuming they've been to resolve.
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're not using too much 3rd party libs, generally we prefer pure framework whenever possible. Entity framework, json etc they all supports.
In EF, some of code was using lazy loading, we had to make them include tables.
Understanding logging and ILogger interface took some time. At first, you feel uncomfortable without a web.config file.
Web api's are most easy one. Except using db context via DI, nothing changed.
Giving decision about what is a service, which part should I have to use as a service and bind them via DI, life time, etc. will be a problem.
Running projects directly from local IIS was a bit puzzle. In one project we have micro services so instead of opening multiple Visual Studios, they work directly from IIS. Figuring out how to prepare IIS took some time. We had to install hosting bundle for developing version.
DI is so cool. After switching to .Net Core, I started to write lots of unit tests. Without DI it was too hard. Yeah, I know DI was around before Core, but after it forced to use it, and after I understand how good it is, I don't want to go back to old projects for maintenance.
And also, AWS now supports .Net Core and you can deploy a Lambda for a serverless app. Not api gateway, Asp.Net Core app directly.
|
|
|
|
|