[deleted]
Understanding the .NET ecosystem: The evolution of .NET into .NET 7
61–70 of 357 posts
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#62My big problem with .NET is that a lot of line-of-business apps were written using ASP.NET Web Forms, but there is no upgrade path other than “rewrite most of it”.
It feels like the pain everyone went through upgrading from Python 2 to Python 3.
It also doesn’t help that .NET Framework has its support cycle tied to the OS, and hence is 10+ years. This means that businesses can be lazy and just leave these old apps to fester and still be technically “supported”.
As web standards evolve, I’m seeing these web apps slowly break.
It’s actually a big problem and Microsoft doesn’t seem to care much. It’s only in .NET 7 that they’ve finally introduced some incremental migration features, but they’re buggy and incomplete.
As a random example of the issues: .NET Core 1.0 broke DataContract deserialisation because of a missing thing in the BCL. A decade later this is present now but they still haven’t fixed the service client generator tool!
Every time I’ve tried to migrate an app, it’s one breaking issue after another with 3-year old GitHub issues that have no responses from Microsoft.
Talking about the awesome future of .NET is great and all, but you've got to give people a path to get there...
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#63I'd be curious to know what is the actual adoption of .net core. I.e. of all the actively developed applications (not just new projects), what is the .net core / .net framework split. I found that the upgrade process is not seamless. Asp.net core has little to do with asp.net MVC. Winform introduced all sorts of contraints. The BCL is full of small changes or features missing. People are less vocal than for the pytho…
> Not breaking your users used to be a laudable goal of the .net team. I miss it Is it that bad once you are on .NET Core? Asking as someone still on Framework. Framework -> Core ofcourse is breaking, what did you expect when going cross platform and totally rearchitected?
I am sure cross platform is useful to some users but not to me. So to me it's all breaking changes for little benefits.
I am not saying .net core is bad, just that the migration is a lot of work. And you need to disable all sorts of compiler warnings unless you are ready to rewrite pretty much all your code to make it nullable ref type friendly. And some day those warnings will be errors.
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#64Earlier quoted context omitted.
It really is like finding enlightenment after having to figure out which third party package is best for every little thing in Node. Visual Studio is a pretty powerful IDE as well.
It better be at a 30GB install size.
A 2TB nvme drive is less than $200. If VS is saving significant dev time, people would install it even if much larger install.
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#65Earlier quoted context omitted.
Northern Europe runs on C# and .Net. I am not joking. There are more C# jobs in Denmark than Python, Node.js, Ruby, and PHP jobs combined.
It is surprising to me that C# and .NET is comparatively under-represented in North America where it was born. Nothing but good experience in developing and operating software with it, both desktop apps (Win/Mac) and backend services (Linux).
I like .Net and C#, but I've had a lot of experiences that were not good.
I personally hated working with Visual Studio 2017. 2019 was an improvement, but one so small it was still awful. I recently used it again (2021?) and was cynically surprised that they FINALLY got scrolling that isn't forcibly line-based. Why did they even bother now?
This and some other small things that used to make the experience painful are now solved, but they still haven't really gotten on top of the freezes and crashes.
Visual Studio being bad is one thing, it being the only officially supported IDE is the other. They should not only officially support third party efforts like Jetbrains Rider, in the past I've gone as far as saying they should discontinue Visual Studio in favor of it.
Now for the nice part: Almost all "new .NET" announcements/tutorials focus on VS Code, an IDE that sucks a whole lot less.
On another note: Transforming a 20 line T4 template took 4-5x as long as the actual compilation on the last .Net project I've seen.
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#66Earlier quoted context omitted.
What would you like build-in db stuff to be like?
Well I mean DataTable and friends can handle master-detail for example, but you gotta do a lot of plumbing to set it all up, especially with autoincs involved. Was kinda expecting it to be less work. Ideally I'd like to supply some selects, fill up some DataTables with master-detail data, manipulate it and commit changes. But yeah, maybe I gotta check out the latest EF stuff and see if I can't convince the others...
DataTables are a construct from .NET Framework 1.1. You owe yourself (and would be doing your employer a massive favour) to check out EF Core.
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#67It’s a tired thing to say, but the “.NET” naming is so confusing on what’s what. Which is sad because there’s so much to like about .NET
1. .NET "Core" ... I tell myself "C is for Cross platform." This is usually what people seem like they mean now when they talk about ".NET". 2. .NET "Framework" ... I tell myself "F is for Former." This is the older, Windows specific version. 3. .NET "Standard" ... I tell myself "S is for Specification." This is just the spec which defines what Core and Framework must implement.
It's just .NET going forward (for now) if you don't need to worry about any old stuff.
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#68Earlier quoted context omitted.
>We're moving to .Net, and I was surprised by how poor the built-in DB stuff is Right now EF Core is probably the best ORM that has ever existed. What exactly is missing? Although for performance you would probably reach for something like Dapper but that is not an ORM.
Well that was my point, either you're writing a lot of code yourself ("assembly"), or you use EF ("Python"). We're not used to something like EF, perhaps it would work for us. But debugging generated queries due to performance issues is something we'd like to avoid. For now the decision was made to not use EF.
I think you might find Linq2Db[0] to be the right fit for you then, which brands itself on being typesafe SQL in C#.
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#69Earlier quoted context omitted.
What would you like build-in db stuff to be like?
Well I mean DataTable and friends can handle master-detail for example, but you gotta do a lot of plumbing to set it all up, especially with autoincs involved. Was kinda expecting it to be less work. Ideally I'd like to supply some selects, fill up some DataTables with master-detail data, manipulate it and commit changes. But yeah, maybe I gotta check out the latest EF stuff and see if I can't convince the others...
EF Core:
1. load order and related line items
2. edit anything
3. call SaveChanges()
Definitely check it out if you haven't recently!
Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7
#70I love the new dotnet ecosystem and use it professionally but am I the only one who thinks two years isn’t long enough for a “long term support” release? Obviously you’ll be able to run older versions of the framework so long as the underlying OS supports it but depending what type of environment you’re in this means you’re likely going to have to update perfectly working applications every two years. Do I think that…
> but am I the only one who thinks two years isn’t long enough for a “long term support” release?
No, I feel the same. It really is a completely different mindset compared to .net framework. And I believe it is recommended to keep upgrading, even in maintenance mode. I noticed that Microsoft removes target frameworks from their nuget packages as soon as they are no longer supported. That could be problematic if you need a security update and are on a no longer supported target framework.
An “enterprise” environment that is used to Microsoft products is not used to that.