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

301–310 of 357 posts

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

#301

Post by pjmlp »

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

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.

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

#302

Post by smcl »

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.

It sounds like the issue you have is introducing breaking or backwards incompatible changes at all while retaining the a similar name. Which is a fair point.

I’m not sure what would help in that case other than using something else than “.NET” to identify it.

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

#303

Post by twodave »

donny2018 wrote: post #219
twodave wrote: post #71

Earlier quoted context omitted.

Fortunately NextJS and .Net isn’t strictly an either/or proposition. I’ve moved most of my new front-end development to NextJS at this point and use C# for most everything behind it.

A few years ago, the authentication/authorization story was quite tough to configure in this setup. Did things change recently?

It really just depends on what you're trying to do I guess. The main auth boundary for my projects is typically the server gateway/api, and that's very straightforward to set up, whether you want simple auth or role-based or to inspect JWT claims or whatever.

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

#304

Post by Merad »

Mavvie wrote: post #230
Merad wrote: post #211

Earlier quoted context omitted.

Configuration is applied in layers. If you’re using the default setup you get the following layers applied in this order: 1. appsettings.json 2. appsettings.{env}.json 3. user secrets (only in Development environment) 4. environment variables 5. command line args You can full customize the setup if you desire, there are packages to support things like external secret stores. If you Google ‘Asp.Net core configuration”…

Awesome overview, stuff like this is often hard for newcomers to find/figure out. I'm sure it's in the docs somewhere but people often miss it. One nitpick: environment vars don't have to be capitalized. You can do ConnectionStrings__MyConnection so the casing matches what you see in appsettings.json. And a word of warning: make sure to understand how the configuration overrides work. If you have appsettings.json def…

Yep, it really just works with key/value pairs, so config overrides happen to individual keys. The config system itself doesn't really have a concept of nested objects or arrays. The config provider that reads the json file takes the path, like JobSettings[0].JobName, and transforms it into into a key like JobSettings:0:JobName (IIRC).

I tend to avoid using arrays in config because of the unexpected behavior, and the risk of overriding something you didn't mean to. Anywhere you'd use an array you can usually use an object and bind it to a Dictionary, then ignore the keys.

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

#305

Post by bigtex »

magicalhippo wrote: post #37
tester756 wrote: post #24

Earlier quoted context omitted.

>It's like either assembly or Python, but nothing in the middle. Dapper seems to be in the middle and it is pretty popular

Yeah, but from what I saw it doesn't help much with master-detail setups? Like, inserting or updating an order with order lines etc. We rely heavily on those.

I use the ORM with Servicestack, OrmLite, and it seems to handle those 1 to many references well.

https://docs.servicestack.net/ormlite/

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

#306

Post by Merad »

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…

WebApplicationBuilder is the mechanism for configuring the kestrel web server. Kestrel is the foundation of Asp.Net Core, there's no separating the two. But Kestrel is a totally modular system. If you configure your request pipeline with a single custom middleware then that is literally the only thing the server is running. If you use only minimal APIs then the middleware that handles their routing is the only thing running. Asp.Net Core has dozens of bells and whistles but none of them affect your app if they aren't part of your request pipeline.

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

#307

Post by noveltyaccount »

devmunchies wrote: post #168
noveltyaccount wrote: post #121

Earlier quoted context omitted.

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?

https://learn.microsoft.com/en-us/training/modules/build-bla...

"In a Blazor Hybrid app, Razor components run natively on the device. Components render to an embedded Web View control through a local interop channel. Components don't run in the browser, and WebAssembly isn't involved. Razor components load and execute code quickly, and components have full access to the native capabilities of the device through the .NET platform."

I'm not familiar with Tauri but skimming it seems similar. Except that Razor syntax allows C# inline with HTML so you can avoid JavaScript altogether. Maui Blazor also uses Xamarin to support mobile, and can compile to WASM to run in a browser.

(What i skimmed) https://tauri.app/v1/references/architecture/

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

#308

Post by Merad »

pjmlp wrote: post #280
Loocid wrote: post #137

Earlier quoted context omitted.

I strongly recommend Rider, even for those using Windows. It's a great piece of software.

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

Modern .Net is pretty focused on web apps. Many of us never need to touch C++, GPU, or the other things you mentioned. I've been using Visual Studio for almost 20 years and IMO Rider is simply a superior C# IDE. It's been my daily driver for going on three years. Of course I keep VS installed because of legacy tools like the WinForms designer that aren't supported in Rider, but that's something I need maybe once a year on average?

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

#309

Post by starik36 »

NicoJuicy wrote: post #256
starik36 wrote: post #156

Earlier quoted context omitted.

> 101 projects Yikes. This is in C# I assume? If in VB, I'd run one project through Instant C# and see how many problems you encounter. There are lots of VBisms that are simply not in C# (like statement for one, xml literals, etc...). Run the simplest project through the `upgrade-assistant` tool. It'll convert it to .NET Core. I saw the sibling post recommend .NET Standard, but if you don't plan on using anything leg…

Hey, that's not nice. Let's bite ;) . It's c# yeah. But I believe the project is much cleaner and frankly better to understand than all other projects i've encountered for this size. I'm using DDD, so DDD knowledge is a requirement to navigate this in a breeze :) : - https://snipboard.io/D03VWg.jpg - General overview of the architecture. Small fyi: Connectors => Autogenerated nugets to call the api's - https://snipbo…

It looks very nicely organized. Looks like your biggest challenge will be converting UI projects.

I even hate to suggest it because it's double the work, but I'd convert all your libraries first to .NET Standard 2. And then make sure they will work fine with your .NET Framework 4.x UI projects.

The reason this sucks (I didn't realize it at the time) is that .NET Standard 2 is stuck with C# 7.3. Which means you are missing out on all the C# cool toys. You can't even use .NET Standard 2.1 (and C# 8) because it's not supported by the .NET Framework 4.x.

Then go on to the UI projects. Automated conversion may or may not work. Probably not if it's complex. The middleware won't simply convert, particularly if you had routing, filtering, etc... You may have to create new projects. I was able to copy/paste lots of code (routing for instance) but how it was wired was different.

If you are successful, you can go back and upgrade the library projects from .NET Standard to .NET Core.

Good luck.

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

#310

Post by pjmlp »

Merad wrote: post #308
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?

Modern .Net is pretty focused on web apps. Many of us never need to touch C++, GPU, or the other things you mentioned. I've been using Visual Studio for almost 20 years and IMO Rider is simply a superior C# IDE. It's been my daily driver for going on three years. Of course I keep VS installed because of legacy tools like the WinForms designer that aren't supported in Rider, but that's something I need maybe once a ye…

I bet WinDev and MAUI teams have other point of view regarding that.

Also, again why pay twice.

Maybe when I start seeing Rider demos done at BUILD.

Post reply on HN