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

331–340 of 357 posts

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

#331

Post by kcartlidge »

For anyone unfamiliar who just wants to see something running, then assuming the DotNet Core SDK has been installed (see https://dotnet.microsoft.com/en-us/download) the following creates a folder, a solution, a minimal web API (4 lines of code), and starts it running.

mkdir MyApp && cd MyApp

dotnet new sln -n MyApp && dotnet new web -n Api

dotnet sln add ./Api/Api.csproj && dotnet run --project Api

Many devs would want more features out of the box so they'd replace "web" in the "dotnet new" command accordingly (use "dotnet new list" to see the options, eg mvc, grpc, or react). But this is the minimalist option just to 'get something running'.

Edit: For background, new sln creates a new DotNet Solution and new web creates a new (minimal) C# web Project. Then sln add tells the new solution that the new project is part of it.

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

#332

Post by SgtBastard »

drdaeman wrote: post #244
SgtBastard wrote: post #223

Earlier quoted context omitted.

As a sibling commenter mentioned, there’s a minimalist functional web server available out of the box, that can later have other more complex components added on: https://learn.microsoft.com/en-us/aspnet/core/tutorials/min-... It’s .NET 101 stuff.

I'm sorry, I think I really must be missing something out and/or explained myself poorly, but I don't see how this is comparable... Doesn't `WebApplication.CreateBuilder(args).Build()` creates a whole web application type thing? In my understanding it's something comparable to `gin.Default()` or `flask.Flask(__name__)`, rather than lower level basic `http.Server{Addr: addr}` or `http.server.HTTPServer(address)` (whic…

>In my understanding it's something comparable to `gin.Default()` or `flask.Flask(__name__)`, rather than lower level basic `http.Server{Addr: addr}` or `http.server.HTTPServer(address)` (which still doesn't require any manual HTTP protocol parsing).

Its not. Keep reading.

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

#333

Post by jiggawatts »

sebazzz wrote: post #312
andix wrote: post #133

Earlier quoted context omitted.

Technologies don’t live forever. At some point you need to upgrade, and at some points there will be some major breaking changes. .NET 4.8 is still fully supported, and there is no end-of-life communicated yet. It is a part of windows server 2022, which will be supported until 2031, that’s probably the earliest possible end-of-life date for .NET 4.8.

.NET Framework will be supported for much longer than that. It is used in many internal Windows components including MMC snap-ins, ADFS, and other Microsoft technologies like Exchange and Sharepoint. Or maybe it will not be supported as in "we won't provide support for any applications needing .NET Framework, but they may or may not still work"?

Or to phrase it another way: Microsoft themselves failed to migrate off .NET Framework to .NET Core for the same reasons their customers are also stuck.

PowerShell Core has been available for years but still is not included with Windows.

Similarly, even new web UI components such as Admin Center are written using .NET Framework.

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

#334

Post by Jochim »

Loocid wrote: post #295
pjmlp wrote: post #280

Earlier quoted context omitted.

Why pay for half of the experience of IDE from the OS vendor, specially when having MSDN licenses already paid for?

What half is Rider missing? And of course you should use VS if you're getting it for free while having to pay for Rider. I find Rider a much more smooth experience than VS. It's faster in almost every way (loading solutions, searching, etc).

Rider is great. If you haven't tried VS in a while, VS2022 moved to 64 bit and the performance is much, much better than 2019. There appears to be a lot more coming, many of the preview features focus on making as many interactions as possible asynchronous e.g. loading projects/refactoring operations/Intelliense completions etc.

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

#335

Post by drdaeman »

WorldMaker wrote: post #318
drdaeman wrote: post #244

Earlier quoted context omitted.

I'm sorry, I think I really must be missing something out and/or explained myself poorly, but I don't see how this is comparable... Doesn't `WebApplication.CreateBuilder(args).Build()` creates a whole web application type thing? In my understanding it's something comparable to `gin.Default()` or `flask.Flask(__name__)`, rather than lower level basic `http.Server{Addr: addr}` or `http.server.HTTPServer(address)` (whic…

WebApplicationBuilder itself is mostly the base .NET Generic Host [1] (which is "bare" .NET and is used as a common host for dependency injection plus common utilities such as configuration and logging) plus activating the Kestrel hooks for HTTP middleware. Kestrel even at its most "raw" is always slightly higher-level and closer to Flask or Express (JS) as a middleware-focused HTTP execution engine. (This partly ref…

Thank you very much for your comment!

I don't have any issues with the IHost and builder patterns. I actually like those - although I've only used the very basics, so I don't really know about the intricacies and possible drawbacks.

Thanks for clearing my misunderstanding about the coupling. I really thought Kestrel was something different, have not expected it to be this high level. It being a replacement of HTTP.sys totally makes sense, of course.

I've found and read https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m... and it started to make more sense now.

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

#336

Post by bottlepalm »

banashark wrote: post #321
bottlepalm wrote: post #266

Earlier quoted context omitted.

Context tracking - selecting multiple entities, updating and pushing them back to the db. Selecting complex dtos, this isn’t query building. A lot of magic turns this into sql. TopPaidMayors = Cities .where(c => c.state.govoner.party ==‘dem’) .select(c => c.name, highestPaid = c.mayors .orderByDesc(m => salary) .take(10)) .orderBy(c => highestPaid.First().salary)

Well you put a fairly normal select query there, which is can be accomplished in Lucid as well. Additionally change tracking exists since it's an ActiveRecord implementation. It's not all magic as well. Looking into the internals of EF, ActiveRecord, Hibernate, or other ORMs reveal patterns that once familiarized can help reason about the behavior of complex queries. I only state this to try to work against the commo…

Query builders are a thin wrapper on raw sql. Real ORMs that understand the relations between objects are not.

There are a ton of joins and sub-selects in that query. 8 very succinct lines. Can you do anything close in Lucid? I don't think so.

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

#337

Post by gofreddygo »

cyral wrote: post #12

Been using .NET for years now for backend web development after having taken a break from C#. It is such an improvement over the old .NET framework. When I started building my first backend with it, I was surprised how much was included and "just worked". Need to add authentication? Few lines. OAuth? Also built in. Response caching? Yes. ORM? EF Core is pretty good. Need to use env variables to override your JSON con…

Coming from 10 years of spring and NodeJS development, last year of .NET has been incredible. I share that "batteries included" experience. So much useful functionality is just packed right in. And there's a lot of backward compatibility and support.

So much better than spring and NodeJS.

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

#338

Post by Loocid »

pjmlp wrote: post #301
Loocid wrote: post #295

Earlier quoted context omitted.

What half is Rider missing? And of course you should use VS if you're getting it for free while having to pay for Rider. I find Rider a much more smooth experience than VS. It's faster in almost every way (loading solutions, searching, etc).

Full stack Windows development, across all Microsoft products and various kinds of Windows SDKs, GPU debugging, hot code reload for .NET and C++, visual tooling for architecture workflows.

Rider does full stack (eg MAUI, Blazor, WPF, Xamarin etc for frontends and can publish to various cloud services) and has hot reload. What Microsoft products and SDKs does Rider not support?

As far as I can tell GPU debugging is C++ only, where I thought we were discussing C#, same with the C++ hot reload. However CLion does both.

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

#339

Post by osigurdson »

WorldMaker wrote: post #325
osigurdson wrote: post #181

Earlier quoted context omitted.

>> 6 to 8 If you are using BinaryFormatter you certainly will have some work ahead of you.

It's been suggested to avoid BinaryFormatter since well before WCF was built and WCF itself has since been deprecated after a decade or so of service.

It may be a self inflicted wound but a wound nonetheless.

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

#340

Post by seabrookmx »

shrubble wrote: post #311
seabrookmx wrote: post #247

Earlier quoted context omitted.

How relevant is Solaris these days? Does it even make sense for them to add support when such a tiny fraction people would use it?

It is still used by some, but most importantly it shows a lack of portability. In the past the view that "all the world's a VAX" hampered portability, now we have "Everything is MacOS/Windows/Linux"... yet lots of properly designed software is easily ported to all kinds of platforms, even the BeOS-derived Haiku...

> most importantly it shows lack of portability

If it already runs on two Unix-likes I don't see the absence of Solaris support showing lack of portability. I actually think Solaris usage is the _more_ important piece: software is made for users and if those users don't exist (or there's such a small number as to make the opportunity cost of development not worth it) then what is the point?

Post reply on HN