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

Understanding the .NET ecosystem: The evolution of .NET into .NET 7

andrewlock.net

Post reply on HN
Print view View original

161–170 of 357 posts

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#161

Post by starik36 »

Jochim wrote: post #135
starik36 wrote: post #48

Earlier quoted context omitted.

I think .NET "Standard" is deprecated. Per this article. https://devblogs.microsoft.com/dotnet/the-future-of-net-stan... Though reading through it, I am still confused.

.NET Standard specified a common API that was implemented by the .NET Core and .NET Framework runtimes, allowing library authors to easily target both platforms. .NET Standard solved a problem at the time but as elucidated in the article, it turned out not to be the right solution in the long term. .NET Framework is essentially in maintenance mode and won't be receiving new language features, so new .NET Standard ver…

So the bottom line is that .NET Core can't call a .NET Framework library. It must be converted to .NET Standard first. And despite deprecation (let's call it that), .NET 5, 6, 7, 8 will continue to support calling into .NET Standard libraries.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#162

Post by PerfectElement »

Any tips on how to migrate a very large ASP.NET MVC app (framework 4.8), that is still in active development, with tens of thousands of users, without a complete feature-freeze? Am I able to migrate to .NET 7 in small increments over a long period?

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#163

Post by Hawxy »

Kwpolska wrote: post #99
cm2187 wrote: post #63

Earlier quoted context omitted.

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.

> 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. Not really. Just disable nullability checking — you can do it project-wide by removing the Nullable tag from your .csproj, and you can continue ignoring nullability. > And some day those warnings will be errors. [citation needed]. A lot of code is written without nu…

> That includes the .NET Core BCL, AFAIK.

The BCL was completely annotated with NRTs for the .NET 7 release, minus some #nullable disable spots.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#165

Post by thenerdhead »

Jochim wrote: post #147
smcl wrote: post #36

Earlier quoted context omitted.

Another good question would be - if you were Microsoft and wanted to plan a roadmap to take the .NET ecosystem forward from a couple of separate implementations (Windows-only .NET Framework, Cross-platform Xamarin) how would you go about this in a way that doesn't cause a big furore like Python 2->3 did? Because I imagine you end up with what MS did - define a standard that can be used for building common code betwee…

The only frustration I've experienced in actually working with it is that it leads to polluted search results. Trying to find solutions to ASP.NET Framework problems usually requires discarding a whole bunch of irrelevant ASP.NET Core/.NET ones. It's the same with Visual Studio/Visual Studio Code.

This is a similar problem with ChatGPT and AI in general. While some things may not change much, you can't generally say "how do I x in .NET" without the chance of getting a really old answer.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#166

Post by capableweb »

waboremo wrote: post #102
brushfoot wrote: post #33

.NET has been doing a lot of things right. My startup's codebase is nearly all .NET 7: landing page, web app, Windows service, API. The main non-.NET code is vanilla JS in the web app. I've been keeping a close eye on Next.js, which is very well done, but I love how versatile .NET is. With one language, I can write all of the above, and my dependencies are minimal thanks to .NET's rich standard library - a refreshing…

Nextjs (and its contemporaries) work really well with .NET. Toss in your API calls into Next, write a beautiful front end, and now you've got separate front end and back end that works phenomenally together and can be tested separately using their strengths. I'm more shocked by you sticking with Javascript. Surely with your adoration of C# you would have moved to its closely related sibling Typescript. Although I gue…

> Nextjs (and its contemporaries) work really well with .NET. Toss in your API calls into Next, write a beautiful front end, and now you've got separate front end and back end that works phenomenally together and can be tested separately using their strengths.

Is it somehow different than using any other language for your backend? Seems to me you're describing any frontend/backend split, nothing specific to either Nextjs or .NET here.

> I'm more shocked by you sticking with Javascript. Surely with your adoration of C# you would have moved to its closely related sibling Typescript. Although I guess there is that slight initial hump to move to TS from a purely vanilla project.

Some people prefer to stick with vanilla JS because that's what the browser ends up running anyways. Personally, TypeScript tends to get more in the way than be helpful for certain type of projects, while for others, TypeScript helps a lot but tends to be when the codebase involves a lot of contributors of varying skill-levels rather than a small circle of contributors with relatively high knowledge of programming and JavaScript in particular.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#167

Post by Kipters »

osigurdson wrote: post #150
SiVal wrote: post #144

Earlier quoted context omitted.

Can you install it [edit: the .Net 7/8 platform that sounds interesting, not the IDE] for free on a Linux server and get the same benefits? (This isn't advocacy, it's a literal question about something I don't know.)

Yes, everything is completely free, open source.

Everything but the debugger sadly

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#168

Post by devmunchies »

noveltyaccount wrote: post #121
hdlothia wrote: post #6

I love c# and dotnet. I've been holding off on flutter and praying Maui becomes a real thing

I have high long term hopes for Maui Blazor. It's such a simple thing, a bridge between native-compiled .NET code and a platform-provided web renderer. There will always be a need for both of those things in .NET, always, so the bridge seems sensible to keep alive. Not sure about Xaml based Maui...that may well go the way of Silverlight.

Is that like Tauri except it’s dotnet instead of rust?

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#169

Post by Guillaume86 »

0xDEF wrote: post #26
magicalhippo wrote: post #21

Earlier quoted context omitted.

> ORM? EF Core is pretty good. We're moving to .Net, and I was surprised by how poor the built-in DB stuff is. It's like either assembly or Python, but nothing in the middle. That said I've also been impressed about how nice it is to get stuff going. I used C# back in the .Net 1.1 days and yeah massive difference in ergonomics.

>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.

> Right now EF Core is probably the best ORM that has ever existed. What exactly is missing?

Wish I could agree but they would have to fix the very slow time to first query when using big models (+500 tables in our case). Compiled models is not a solution for us since our model changes a lot and the compilation is just as slow. It's disappointing because it used to work fine under the ancient Linq2SQL library.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#170

Post by andix »

waboremo wrote: post #102
brushfoot wrote: post #33

.NET has been doing a lot of things right. My startup's codebase is nearly all .NET 7: landing page, web app, Windows service, API. The main non-.NET code is vanilla JS in the web app. I've been keeping a close eye on Next.js, which is very well done, but I love how versatile .NET is. With one language, I can write all of the above, and my dependencies are minimal thanks to .NET's rich standard library - a refreshing…

Nextjs (and its contemporaries) work really well with .NET. Toss in your API calls into Next, write a beautiful front end, and now you've got separate front end and back end that works phenomenally together and can be tested separately using their strengths. I'm more shocked by you sticking with Javascript. Surely with your adoration of C# you would have moved to its closely related sibling Typescript. Although I gue…

Frontends often have a much shorter lifetime than backends. A good example are banks, they change the online banking frontend approximately every 10 years, but a lot of backend systems are running since the 80s/90s without complete rewrites.

It makes a lot of sense to decouple them, and just re-write the frontend to whatever technology is the best for its time. It’s also not uncommon to have multiple frontends, for example a web application and also a native android/iOS app.

Post reply on HN