.NET 6 Released | Hacker News Reader

.NET 6 Released

devblogs.microsoft.com

502 pointstonicbbleking416 comments

For me Hot Reload is the most important feature, which will very likely be a reason for me to move a bit from Python over to .NET, which I haven't touched for 10 years. Back then I really used it a lot (after moving away from OLE/DCOM/ActiveX), in C++, Managed C++, C# and IronPython (no GIL!). I absolutely loved it, but it was limited to the Microsoft ecosystem.

Yesterday, while randomly googling for "hot reload" I got aware of the drama which went down around two weeks ago, when Microsoft decided to remove this feature from the release, even after including it in the previews.

Here is a good summary https://www.youtube.com/watch?v=L9_pzDjw9HQ

Good catch!

Looks like they have walked this back, and Hot Reload for CLI (and thus, tools outside full the Visual Studio IDE) is here to stay. For now.

https://devblogs.microsoft.com/dotnet/net-hot-reload-support...

I think the Hot Reload stuff is still in its infancy.

From what I read, it doesn't yet support stuff like async/await, LINQ, lambdas (and few other things). And those are used a lot in modern .NET apps.

Still a great improvement in the right direction.

> In .NET 6, in-memory single file apps have been enabled for Windows and macOS. In .NET 5, this deployment type was limited to Linux. You can now publish a single-file binary that is both deployed and launched as a single file, for all supported OSes. Single files apps no longer extract any core runtime assemblies to temporary directories.

This is a great! Now I can publish statically linked executables and run it everywhere. I don't have to tolerate Golang and its quirks just to have cross-compilation and static binaries, even though they will be larger in size.

>> Single files apps no longer extract any core runtime assemblies to temporary directories

I might be ignorant here but if you're not specifically pointing out what version DLL's you want, aren't you in fact publishing a dynamically linked executable instead of a statically linked one?

Doesn't these single-file apps rely on the GAC?

The whole runtime gets included in the binary.

Does this mean you need one binary per OS so that the runtime matches, or do they do some magic so that one single binary can run on all Oses ?

You create one binary per OS.

You create a single binary which has the runtime and dependencies self contained within.

You of course have to choose your target platform for this as it makes .exes for Windows, ELFs for Linux, etc.

If you want you can still choose to distribute IL DLLs and users then use their already installed dotnet on their machine to run them.

> You of course have to choose your target platform for this (...)

https://github.com/jart/cosmopolitan

(but, yeah, you probably want one version per target, even if hacks are cool)

This actually makes sense in 2021 since we have the resources to allow things like this. 20 years ago this might have seemed insane.

30 years ago we used DOS and DLL Hell was a completely unknown concept. We did have to deal with himem.sys though.

On the contrary, 30 years ago we were using Windows 3.0, which is about when dll hell started being a real thing.

(DLL hell stopped being a problem a lot sooner than you probably think, too...)

>DLL hell stopped being a problem a lot sooner than you probably think, too

Does not match my experience at work unfortunately.

If you're seeing this on any version of Windows made in the last 22 years or so, it's because a software developer fucked up in a really creative way. My condolences.

Sometimes the issue is that people have tended to conflate "dll hell" and "dependency hell." That's an old pet peeve of mine and I realize it doesn't matter...

"Insert floppy disk 435 of 880 and press [Enter] when ready..."

Invalid media type

Abort, Retry, Fail?

FFFFFFFUUUUUUUUCCCCCCKKKKK!!!!!!

Keep in mind that it's just one option. If you want, you can still deploy your app separately from the .Net runtime.

Also, to keep the size at least somewhat in check, unused parts of the base library are not included in the single-file mode.

Keeping in mind it's also a double edge sword. TLS deprecations alone will ensure your app will die after a few years if it doesn't run on an up-to-date CLR.

This sounds quite the argument for basing critical workflows only on software for which the user has both access and permission to modify the source code.

Timezone and DST fuckery is another, I assume?

How much does this add to the binary's size?

In my case about 60MB

Something like 60MB if the application is not trimmed. Closer to 10MB if the application can be trimmed.

There is no GAC.

> .NET Core and .NET 5 and later versions eliminate the concept of the global assembly cache (GAC)

Interesting. I haven't worked in .NET for several years now, but the GAC was always an absolute headache to deal with.

Thankfully they did not port this hell to Linux

Surely the binaries generated by the JIT still get cached somewhere?

you can set a ReadyToRun flag on publish which pre jits your dlls https://docs.microsoft.com/en-us/dotnet/core/deploying/ready...

For an internal tool that reformats our code base, I've used that to pack the `dotnet format` (although technically, not allowed case, since it's a tool, and need to be run from an "sdk" environment). It works for what we use it (whitespace formatting, but not for msbuild/analysis - which is clearly understood).

One thing though, is that native .dlls are still outside (DetoursServices.dll for example in BuildXL). But still pretty impressive what it can done. That, and the new embedded .pdb (for .NET only, e.g. not native).

I wish "publish" was used more by the place I work for (most of the folks would simply Release (F5) and store what's there in p4). I've only recently discovered about "publish" and that is after haven't worked with .NET for so long...

Yeah "publish" is magical, I specifically jumped from .net 4.8 to 5 just for this feature.

msbuild had publish since at least .net 3.5 (when I started to use the platform) it was just a little bit akward to use tough. and of course dotnet publish is 1000x better than msbuild with it's obscure syntax (which got way better in .net5 and 6 with -p: syntax, etc.)

-p:Property=Value (or /p: Property=Value) has existed in Ms build since the beginning. That's not a .NET 5 or 6 thing.

Also If I'm not mistaken most of the properties (if not all) can be set through the command-line (for good and bad :)), e.g. `set Property=Value && msbuild` or `Property=Value msbuild` (on unix systems)

I don't remember what changed, but I wasn't able to use it on my old .NET projects.

You should also be able to do this in Java with jlink.

yes but then you have to write your program in java

and now you have two problems

Three problems, since POM.XML is probably involved somehow.

I rather have a pom.xml than build.xml or gradle spaghetti.

Yes, arguably a better decision than writing it in golang to begin with.

Go is better than Java any day of any week if startup time or memory footprint are of any concern to you at all.

Also Java is OO which is... terrible to say the least.

Java has had AOT compilation since around 2000, just not as free beer.

In 2021, the AOT free beer exists, as do JIT caches.

As for OO model, I rather be able to understand which interfaces a type implements by looking at it, instead of producing compiler errors, or have a type by accident supporting a single method interface with complete different semantics.

GraalVM is a thing (see: www.quarkus.io for an example) if fast startup and low memory usage are a requirement.

Not sure what the OO rant is about, it's awesome. It's not like golang isn't (poorly implemented) OO as well (minus explicit inheritance, which embedding is somewhat similar as well).

What do you mean by golang quirks?

No passable debugger, weird typing system, verbose error handling, lack of exceptions, generics, syntactic sugar ...

I'm a novice at Golang, and I dislike much of the language, except that it's fast and can produce small binaries.

"verbose error handling, lack of exceptions"

Exactly why I prefer Go to Java and C#.

Understandable, but it's a matter of taste. For people who prefer a language with exception, it's good that there now exist a viable solution other than sticking to a language that might not fit their taste so well.

It seems to me that F# could get a bit more love from HN-style nerds. Obviously, it's more similar to C# than Golang, but specifically error handling can be done in much nicer way using the Result type.

But Go has no sum types either!

I can live with many things, but no generics in 2021? Over my dead body!

Sounds like you want nim.

Yeah, nim ticks all the boxes, but the ecosystem around it should grow a bit more until I can develop comfortably with it.

vlang[0] also seems like a nice golang "fork" that I'd be willing to spend time on.

[0]: https://github.com/vlang/v/blob/master/doc/docs.md

Not wanna bring down that project, but be wary of V, as in the past it has made plenty of impossible to live up to “features” and indeed, never delivered. But I haven’t followed it since then.

I'm aware of the controversy, and I've been following its development for some time now. It seems to be developed at a neck-breaking pace, but I'm still waiting for an official "go!" license before I start playing with it.

I hope they succeed because it has/promises a really attractive set of features.

As a personal choice, would rather use Vlang than Nim. Like the potential and what I'm seeing from Vlang, though was hoping the cross-platform UI would be further along. As it is, they are developing quite quickly.

Kind of curious that Microsoft had a feature that was available in Linux but not Windows, no?

Yea, funny :D However, the problem was mostly deploying dotnet apps on servers which did not have dotnet installed. Windows has .NET installed anyway, so there the problem did not really exist

.NET (Core) 5 is not installed on Windows. Windows comes with .NET Framework 4.x.

I think the user interest was startup times of lambdas and containers. Therefore Linux was a priority.

Seem to recall this happening several time with Microsoft Office for Mac getting certain features before Office for Windows did.

Wait, wait… .Net can build “static linked” executables that doesn’t require that I install .Net to run? I had no idea, I guess it’s time to revisit .Net

That's exactly what it is. You can even cross-compile for all supported platforms.

    $ dotnet new console -n HelloWorld
    $ dotnet publish --project HelloWorld -r osx-arm64 --self-contained -o out -p:PublishTrimmed=true
    $ du -sh out
    10M

Wow... I didn't know. Since when can it do this?

I believe it was introduced around .NET Core 5? or 3? so at least 1 year ago

Since .net core 3.0

I've been using this for at least a year or two. With their stripping, my binaries (which use very little other than system.* and math.*) are 12M in size on each OS. I tested with today's release of version six, the binaries are about 1M smaller each.

I haven't used .net. But how memory management happens when you are running a binary executable? Does it have a builtin CLR (Common Language Runtime[1])? Because CLR provides the tools for managing memory & security?

[1] https://en.wikipedia.org/wiki/Common_Language_Runtime

Yes, it embeds the CLR in to the application see the PR at https://github.com/dotnet/runtime/issues/43072

This, combined with linker stripping below even assembly level for smaller static binaries.

.NET 7 will work on NativeAOT for instantaneous startup of especially smaller apps, but I think they’ve already optimized JIT warmups or something — I was pleasantly surprised when I just wrote a .NET 6 console app that read JSON from a server.

After almost 18 years, Joel finally got his wish:

https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-h...

If it's like v5, you can. They're big (since they include .NET, though it looks like v6 will strip out more than v5). And they won't run on Windows 7 without an administrator installing a system component first.

Last time I tried it, single-file binaries were super slow on first load. It was one of the reasons we went back to .NET framework. Has this improved?

I wish that I knew about this earlier. I'm a Linux user but I love C#. I suppose that VS Code is the canonical IDE for C# today?

No visual studio or rider, vscode support isn’t great from my experience.

Thanks. I love the Jetbrains IDEs.

For Linux you can use either VS Code or Rider.

Terrific, thank you.

.NET 6 seems like a pretty good release with a few cool new features.

But it's funny how the infographic in the post mentions MAUI for desktop development, but the "desktop" keyword in the text is referring to the WinForms github repository. I can't think of a more concise statement about the state of GUI development on .NET. I would really wish for less fragmentation and churn in that space.

Replace ".NET" with "Windows" maybe?

AS a longtime original VB/Winforms developer - MS lost their mind on desktop development and didn't look back.

They chased EVERY fad that could be chased. Silverlight, UPF, XAML, WPF, Islands, MAUI. This is one of those things - imagine if they'd focused on building an amazing and cross platform (ultimately) toolkit with just a basic drag and drop designer? Who cares about "styling" your app and all the rest of the garbage.

How many lost years and peoplehours?

This has been their modus operandi forever.

I've got to the point where I don't trust them on any of this stuff. I target WinForms and if they ever decide to kill that then I'll abandon the platform completely.

>Who cares about "styling" your app and all the rest of the garbage.

One of the problems with WPF is the lack of styling of the standard controls. It takes a lot of work to ensure your app doesn't look like a turd.

Why would you want to style standard controls in a desktop app? They should look the way they look everywhere else in the OS.

Windows has multiple competing standards in the same OS, even from their own software distributed with the OS. It’s embarrassing.

It is, but there's still a standard system style that the majority of the apps are expected to use. Which is exactly what WPF uses - it's fairly easy to see if you take a WPF app and observe the differences on Win7/8/10.

In any case, surely, adding yet another different style only makes the problem worse.

Right now if i open a Sysinternals app I’ll have the text in the UI rendered in one way and the title bar rendered in another. It’s jarring.

Not to mention they behave differently with respect to HiDPI.

Remember how much criticism Linux and other unixes got by people complaining about apps created with KDE on Gnome desktops and vice versa?

I'll never forget ;-)

And that’s a disaster too.

Really the only one that’s done it correctly is Apple.

Apple also did this whole "our apps are special" thing more than once.

I don't know why, but there's this weird temptation for every app to try to present itself as some kind of unique work of art, when it comes to UX. But I don't want art, and I don't want branding. I just want ergonomic tools - and part of ergonomics is not to have to re-learn everything every time you pick up a new thing.

https://www.reddit.com/r/Windows11/comments/o2a0kp/there_are...

Every once in a long while (very long now) you'll stumble across a dialog box that looks like it's from Windows 3.1. ODBC is one of them that's still that old.

Nobody mention the gui toolkits for Java or desktop window managers for Linux…

WPF has no such concept. Even if you don’t use a library for this, it’ll then just use the built in style after detecting your OS version and adapting to that. But it does this by pulling out hard coded resources shipping with WPF. If you wish, you can override and tell WPF to look like XP on Windows 10 instead… It’s all just a good try, but still a facade. It does not and can not (per design) rely on “native controls”. I suppose because it’s DirectX based rather than GDI.

I've been using MahApps.Metro[1] and MaterialDesignXAML[2]. Those two libraries have made me feel like sticking with WPF until I retire in 5 to 10 years. I'm constantly getting feedback from clients that the applications look so modern. It's been a nice selling point as my niche is rewriting VBA/VB6 engineering software.

[1]https://mahapps.com/

[2]http://materialdesigninxaml.net/

Same. WPF in an MVVM pattern is so comfortable to use once it clicks. It has its quirks but for everything there is a workaround once you stick to the pattern.

For the creators of Mahapps I have eternal gratitude.

Also if you still need to support XP (even back when it was still getting patches), forget it, Microsoft has no interest in supporting you.

Even if you want to use the latest and greatest UI, your customers need to keep up too. Completely unworkable.

XP is 20 years old, its older than invasion of Afganistan.

I recently ran XP in a VM inside Windows 10 and was amazed at how much faster everything ran, how quickly programs start, and how responsive they are. Feels like we lost something along the way...

Not only lost productivity, but getting executive buy in to invest in WPF was difficult after Silverlight.

Kinda joking, kinda serious, but all the Microsoft UI changes in the last 10-15 years have definitely helped enterprise IT adopt internal web applications. :)

Very true. I used to be a desktop dev but since Windows 8 MS has convinced me it’s better to do web stuff.

It’s fun to think that, after all these years, we are back to screen-oriented terminals (browsers) accessing mainframes (cloud apps)…

I loved the 3278.

And now we write “screen scrapers” to get information from html instead of the terminal emulators. Rinse. Repeat.

<sarcasm> True. Frameworks to build web applications only come out every few months.

And the crazy thing is that all these frameworks were basically incompatible variations of the same thing. Since WPF nothing has really gotten better. Just different for no good reason.

I will never bet on any new MS desktop development framework anymore . It’s either WPF or preferably web (even Electron) for me.

To be fair to UWP XAML, it's more efficient than WPF.

I don't mean because it's written in C++ instead of C#. The render pipeline of WinUI is more efficient. It's really interesting, but unfortunately I can't find the technical blog I was thinking on.

It’s more efficient but much less reliable. Like if you change from light to dark mode, there’s a 20% chance all UWP apps that are open crash.

And as efficient as it is, it still can’t resize windows without flickering. It’s worse than WPF or Win32. And there still aren’t proper APIs for configuring the titlebar area.

I wish they focused on getting their vendor partners to make efficient processors, rather than try to get all windows developers to rebuild software to run on hobbled ARM hardware.

That doesn’t explain why they had to roll a new framework instead of improving WPF. It may have been ok if they provided an upgrade path but since Winforms they haven’t bothered with that either.

Politcs, driven by the same group that botched Longhorn in name of C++ and COM.

https://arstechnica.com/features/2012/10/windows-8-and-winrt...

are you still doing desktop work? if so, what are you using?

I actually moved away from desktop.

Lightweight web apps mostly in python (Flask).

Slack apps / bots with a bunch of commands (backend does lookups, generates PDFs)

People don't fully realize what we gave up dumping desktop development, you used to be able to build our nice biz specific crud apps (customers, projects, scheduling etc) using a bunch of tools. These things were usually darn fast if you were careful and you could make them very keyboard driven (ie, put the keyboard shortcuts on button labels etc).

>"They chased EVERY fad that could be chased. Silverlight, UPF, XAML, WPF, Islands, MAUI"

Being a wise man I spared myself from this madness long time ago;) When I need Windows Desktop App I use Delphi or lately Lazarus that can do both Windows and Linux GUI from a single source and produce native standalone executables.

WinForms is still around, and works as well as it always did. That or WPF are still the sanest choices for desktop apps in .NET, IMO, so long as you're only targeting Windows. And WinForms specifically resembles VCL a lot.

I skipped .NET bandwagon for desktop completely. Comparatively to Delphi there were exactly zero business reasons for me to move my code or use .NET for new apps.

On a technical side there were no gains and numerous limitations.

On the technical side, the biggest productivity gain is from having a garbage collector. Beyond that, language features: while C# 1.0 started in a spot very similar to Delphi (+GC), it evolved much faster - e.g. getting generics in 2005.

But, yes, if you looked at it in 1.x days, it really looked a lot like Delphi libraries with Java-like syntax. So if you were already using Delphi, there wasn't much point.

>"On the technical side, the biggest productivity gain is from having a garbage collector."

1) I use leak detection tool so no productivity gain in that area. Besides it is burned into my brain to always write deallocation code first before doing any allocations. That is when my classes are not using interfaces that are reference counted. In reality I could hardly remember any instances when memory / resource leak tool showed any. Also I did not have to dance around IDisposable, Weak and object caches shenanigans.

2) Generics - this is great feature but in my opinion it is mostly geared towards libraries writers. Being more of a product / application oriented bar few exceptions I personally do not use it much neither in C++ nor in Delphi (Delphi has generics since 2009).

> 1) I use leak detection tool so no productivity gain in that area.

These are never as good as garbage collection. In some cases, not even close.

I consider this statement false

Consider it false all you like, the proof is in the pudding:

https://www.forbes.com/sites/gordonkelly/2021/11/16/google-c...

> Replace ".NET" with "Windows" maybe?

There's Uno, Avalonia, Xamarin Forms, and MAUI, all cross-platform. I think it's a mess no matter what.

In all fairness, at one point you could actually make sense of things.

Unless I'm misremembering, until recently Avalonia was still being touted as primarily a replacement for Desktop WPF. I was shocked to see they're talking about mobile now too. I guess it's somewhat expected.

Uno basically does what MAUI does. The main difference being, Uno has been around for a while longer and something you've been able to use for some time. I'm pretty sure they had usable versions for well over a year before MAUI was even announced.

In any case...

Microsoft's UI story is a non-starter until they get back to the point that a user can:

- Click new project - Fill out the form - Get a Design window, - Drag a 'Textbox' into the design window, - Drag a 'Button' into the design window, - Double click on the button, get taken into a generated event handler, and the user can intuitively put in the right code (i.e. updating the viewmodel with 'hello world'.) - Click 'run'

That's the Story that got an untold number of new developers -enamored- with VB6, a language that got so entrenched Microsoft had a hard time killing it. It brought a number of developers into the world of C#, making it easy for to write applications used at work that a whole team could use. That's actually how I 'eased' into programming at my first workplace; I wrote an app with a big ugly panel and a bunch of big buttons with labels that would automate tasks. Need a variation on a theme? Drag a new button over, maybe do some light refactoring, test, publish, tell the guys to restart the app. 10-15 minutes tops.

Sure, Eventually I had to go through a spaghetti mess of callbacks and crappy generated code, but it was good refactoring practice ;). And when I left the company, someone else took over the code and now they are a software developer too.

And you could really evolve it. Databinding was surprisingly good and easy and fast - still beats web in my view - autocomplete, panels / options groups / tabbed windows etc all worked well (and were fast).

> - Click new project - Fill out the form - Get a Design window, - Drag a 'Textbox' into the design window, - Drag a 'Button' into the design window, - Double click on the button, get taken into a generated event handler, and the user can intuitively put in the right code (i.e. updating the viewmodel with 'hello world'.) - Click 'run'

Its been a while since I looked at these and I was having a look for a designer like WPF for Win UI/Uno etc - does this not exist?

When I played with Uno, There was a UWP designer (At the time Uno relied on UWP for the API/Translation, IDK if that's changed.) It worked mostly like the WPF designer but I think it was slightly more limited.

> - Click new project - Fill out the form - Get a Design window - Drag a 'Textbox' into the design window, - Drag a 'Button' into the design window

Non-starter these days. Building a form graphically doesn't take into account multiple screen sizes and screens that can change dimensions on the fly, which are now far more prevalent than the heady desktop UI days that you're talking about here. Unless you have some novel idea for how to design graphically for all sorts of screen sizes.

I personally think it's a mistake that frameworks try to be all in one by trying to target mobile (phones and tablets), desktops, and even web. It just doesn't work, and I don't know of a single platform that actually accomplishes it without major limitations on one or more platforms.

> Non-starter these days.

It's about the species; Remember that I mentioned that in the context of 'someone getting started'. I say what I say because it would be the best thing to help new users get 'hooked,' not necessarily because it's the best way to make a maintainable app. (IDK though, some of my one-team winforms stuff was actively maintained for years after I left)

> Building a form graphically doesn't take into account multiple screen sizes and screens that can change dimensions on the fly, which are now far more prevalent than the heady desktop UI days that you're talking about here.

There's no reason you couldn't handle such a thing in WPF. Sure, it may be more -work- to check representation in both formats, and some form of helper (that would handle certain scaling factors of buttons/etc) would be a boon to developers. That's not the way I look at it though, see below;

> Unless you have some novel idea for how to design graphically for all sorts of screen sizes.

It's not necessarily about making a 'single' UI that works on both mobile and Desktop. If you can even get to the point where a user can make separate Mobile -and- Desktop 'form-style' built screens for their app, all in one happy framework/language... Frankly that would be the best thing overall, since you can provide optimized Desktop -and- Mobile UIs, and not have to have a bunch of disparate technologies used to build each.

> Microsoft's UI story is a non-starter until they get back to the point that a user can:

Why do you care about this stuff? I don't understand. Surely most developers can build a simple app with a few buttons easily in whichever framework they're using. This stuff doesn't really matter for I'd dare to say 90% of developers. What matters is how hard it is to build and maintain complicated stuff. And there WPF blew WinForms (and VB6) out of the water.

Not sure why you think how difficult it is to put a couple buttons on a page and make them do something would have any effect on the success of a UI framework. That's literally not even a consideration when we make decisions on what to use for a project.

If WPF ran on other platforms, we would use it for everything. We use Avalonia instead, and it's pretty great.

But there are 2 basic types of multiplatform UI frameworks - the ones that wrap native controls and look like most other apps on the platform, and the ones that do their own rendering and look the same on every platform. Avalonia is in the second group, so if the former is a hard requirement then it is not a good choice.

> What matters is how hard it is to build and maintain complicated stuff.

What matters is how hard it is to deliver a product to the end users. As I gave in my personal user story, yeah, I had to eventually pay the piper and refactor significantly to make sure things were maintainable. But it was a good lesson learned, and I've met many other developers over the years who got hooked on C# in a similar way.

> And there WPF blew WinForms (and VB6) out of the water.

WPF would be fine for this scenario. If we could do things like this at a WPF level of designer I'd be happy. It's got a little more of a cognitive load to get started but long term is easier to reason about long term and from a conceptual standpoint is more transferable to other contexts (i.e. Web MVVM Frameworks.)

I haven't looked at Avalonia in it's current state (last time I gave it a peek, it was still in a 'almost-ready' status) but if they really are able to do multiplatform as I see they say now then perhaps that's what I'm saying is needed. (Which may be more of a statement on the state of Real OSS Awareness in the .NET community.)

Definitely will give it a go, since I know it's supposed to be a replacement for WPF so I'm hoping(?) that the existing tooling out there is usable

IMO they need to realize the common denominator of all these failed and deprecated frameworks is the very thing they've desperately clung onto over all these false starts... and that is XAML.

Get rid of it.

XAML is good. It's very easy to build interface by nesting components then styling it if needed, and doing data binding. All the web alternatives are harder to use and came 10-20 years later.

XAML is why I’ll never write a Desktop App with .NET, who’s been unable to rid themselves from it.

React, Vue, Svelte as well as Flutter & SwiftUI all implement different but vastly more productive reactive dev models.

MAUI will not be resurrecting .NET Desktop Apps which have been on decline since WPF. Blazor Desktop Apps might, anything XAML won’t.

XAML is the only thing I was ever able to write a complex layout in, run the app, and see it look exactly as what I intended on the first attempt. That would meet my definition of productivity.

For example, my experience with CSS has been the opposite of that. F5 a million times before the layout works the way I want it to. Sometimes even googling how to do create some type of layout because I can't think of it on my own.

XAML is good for structure, same way HTML is. But by god is styling it a major PITA of boilerplate nesting hell

WPF compiling to WebAssembly would be ideal.

Note that Maui is the name used by an older ui toolkit https://mauikit.org/ and you probably should refer the one by Microsoft to .Net MAUI to avoid confusion.

Instead of chasing the next Microsoft fad, I've decided to try AvaloniaUI for my next graphical app.

It looks mature enough now, and has a better chance of being still useful in 5 years from now than WinUI or MAUI or whatever is the latest GUI tech MS wants us to use.

It still has some rough edges, but I really like it since it seems to be only .NET GUI choice compatible with Linux. I'm bit sad that MS might suffocate the project with the Multi-platform App UI (MAUI) which does not work on Linux :/ Fortunately, MAUI seems to have much more glitches than Avalonia ATM

Since MAUI works on Android, I assume MAUI will eventually support Linux.

Same here, I least I know this will consistent across platforms.

They just keep recognizing that WinForms is the best. And you can still use it

Do they have full support in .net 6? I believe in previous version it was a partial/beta implementation. Hardly any mention of winform in the announcement.

I am basically stuck on .net 4.8 because of that.

I just ported a WPF app where the story is similar. Yes, I'd call it "full support". It's not a drop-in replacement, though, except for really simple apps. Check the Breaking Changes List for .NET 6[0], .NET 5, and .NET Core 3.1. Some more niche APIs like `System.Runtime.InteropServices.RegistrationServices` are not supported on .NET 5+ at all. If you have NuGet packages that haven't been updated since 2011 you may need to find modern replacements. There is an Upgrade Assistant tool[1] which can do much of the work. You'll probably have to spend a few annoying hours googling and editing .csproj files by hand.

[0]: https://docs.microsoft.com/en-us/dotnet/core/compatibility/6... [1]: https://docs.microsoft.com/en-us/dotnet/core/porting/upgrade...

WinForms support in .NET 5 and 6 is great. It's getting a lot more attention than WPF (which is owned by the Windows team), and it's likely that in .NET 7 it will be trimmable and maybe even AOT-compatible.

My strategy for dealing with Microsoft's regrettable desktop GUI roadmap is to use the web as much as possible. .NET has an incredible suite of features for pushing functionality to the browser. Kestrel is one of the fastest web servers available today. Developing directly against the AspNetCore pipeline has a bit of a learning curve, but it becomes very intuitive once you get over the DI/startup hard bits, and the performance you can get with low level middleware is staggering (to me).

There are very few applications that simply cannot work in a web browser in 2021. Even accounting for all the inconsistent bullshit between browser vendors, you can still arrive at something that works as far back as IE6 if you are conservative with your footprint.

Do you really need flexbox, webgl2 and GPS navigation for that warehouse inventory management application? Does everything have to live the various app stores? Will your users revolt if there isn't some ceremonial download & install phase of using your product?

I would go so far as to argue for deployment of a self-contained webservice to the end users that could be accessed via any arbitrary localhost browser before succumbing to the Microsoft Desktop GUI framework du jour.

For "regrettable" substitute "tire fire"

"I would go so far as to argue for deployment of a self-contained webservice to the end users that could be accessed via any arbitrary localhost browser"

Might as well use Unity game engine and write your app inside one.

There seems to be some people writing UI applications with the Godot game engine. Given the dismal state of desktop UI frameworks/tools, this seem to make more and more sense (very light binaries, solid cross-platform support, a WYSIWYG toolkit with good scripting functionality, a high-performance 2D renderer, access to C/C++ if you wan to go low-level, you name it.)

Examples:

https://www.wonderdraft.net/

https://github.com/Orama-Interactive/Pixelorama

This is an accessibility nightmare. Please think hard before doing this.

Well, the two applications I’ve linked above are very graphically intensive (the first one is a map designer, and the second is an image editor), up to the point that it will be meaningless to add any screen reader or dictation support. In some cases you’ve got to admit that it’s close to impossible to bring certain features to people with certain disabilities (although I think this should be its own field of HCI research, maybe it can be possible someday?)

> Supported for three years as the latest long term support (LTS) release.

This is the first thing I look for in these announcements. .NET 6 is the successor to .NET Core 3.1.

I've been waiting for .NET 6 for the past year for the long term support. As much as I wanted to use .NET 5, I figured it would be best to only use LTS releases in production.

I never run anything else than LTS in production. The in-between versions have basically been beta quality since .NET 1-preview.

Crazy how bing.com seem to not care for "beta" software :D

Bing.com developers are "first-party customers", they can raise issues internally, and these issues are prioritized

They literally don’t. They run actual preview versions in production to give the .NET team a chance to test new releases in high-traffic production scenarios. Though IIRC preview is a bit past beta ;)

Right… So if such a massive site uses it whats the excuse for the next CRUD app?

I don't agree personally. I've written production services in all versions from 2.0 up to 5.0, including the minor point releases and had no issues (especially most recently).

I know there have been some quality issues on the EF Core side, but on the Framework side everything has been pretty rock solid for me, with easy upgrades between versions.

Disclaimer: I work on .NET

What makes you say that? All versions of .NET - including non-LTS versions - have had an extremely high bar for quality before releasing.

I worked with all .NET versions. The most none-code related .NET bugs I had to hunt down in modern time has been in .NET Core 1.0 (clear leader) and .NET Core 2.2. The thing I like about the LTS versions is that they always work in and with any part of the ecosystem. Actually, one of our clients had to downgrade from .NET 5.

Disagree. .NET 5 and 6 previews have been remarkably solid+stable for me.

not the best idea. because between .net 5 and .net 6 not a lot has changed. while 3.1 to 6 is waaaaaaaay more work than just 5 / 6 (which prob is just changing the version) especially on aspnetcore

Three years doesn't seem very "long".

True, but it requires way less effort to upgrade to a newer .NET.

Indeed, but it seems to be close to the current "industry standard" at this point, for instance: Node LTS is 12-months support plus 24-months "extended security support". (Three years total)

Which is not far from say Ubuntu LTS at five years. (Python and Ruby have more confusing security fix policies than LTS/stable designations, but both are relatively close to the 3-5 year mark for security fixes.)

Definitely not "long" from the perspective of classic Enterprise development (or Windows "LTS" lengths), but from modern viewpoints it is "long". Interesting how such things shift culturally.

If you pay Canonical you get 10 years for Ubuntu LTS, about the same as paying Microsoft for Windows Server/Enterprise.

> System.Linq — DistinctBy/UnionBy/IntersectBy/ExceptBy

I'm excited by having these built in. I always found it awkward to need to do: `.GroupBy(item => item.Property).Select(group => group.First())`.

Whole bunch of other good stuff for Linq users!

https://devblogs.microsoft.com/dotnet/announcing-net-6/#syst...

I have been using https://morelinq.github.io/ for a long time for all the above and more.

Is there any reason I should care about .NET today if I'm not already in the ecosystem? I've done C# professionally in the past, and C# is a good language. I wish Microsoft focused on open source and wider industry adoption for C#/.NET sooner so that it could have taken some share from Java. Now .NET is finally open source but Microsoft is a bad steward of the open source ecosystem for .NET, and I certainly wouldn't feel comfortable to say to my team "let's do this next project in C#". I don't see any particular reason to make my own tools in C# vs anything else.

So without already being in an existing Windows-based Microsoft shop, is there any reason I should be interested in .NET today?

F# is the reason I'm investing in .Net. So far it's been an amazing developer experience.

For internal admin tools I can throw together a windows form app in C# much quicker than any other system I've worked with. I'm pretty new to the eco system so to it's amazing how fast you can get up to speed.

Outside of a few very small stumbles, I don't think that Microsoft is a bad steward of open source .NET. Especially if you use Java as the alternative example where there were decades of Sun/Oracle shenanigans around open source Java.

Microsoft has done an amazing amount of work writing and rewriting code to make cross platform open source .NET a real thing. All open licensed and developed in the open.

> Microsoft has done an amazing amount of work writing and rewriting code to make cross platform open source .NET a real thing. All open licensed and developed in the open.

It's fitting you mention all the work Microsoft has done rewriting code. You're talking about .NET itself but I'm talking about the ecosystem, where Microsoft often does take others' projects and release their own version (the Windows package manager comes to mind), training the community to only trust things that come from them. Of course there was the recent famous example of Microsoft deleting public code so they could feature it in Visual Studio, but this tweet is typical of the attitude I've seen from the community: https://twitter.com/GeoffreyHuntley/status/14540569884432179...

This reply doesn't really have anything to do with your original comment. If Microsoft is producing a solid language / framework in the open and improving their product such that 3rd party "light-weight" libraries like Nancy are no longer necessary, why is that a bad thing?

In my opinion, while other ecosystems have exploded in complexity in recent years, the increasing simplicity and batteries-included nature of .NET is an appealing contrast.

That's my answer to your question about why you should be interested in .NET if you're not already in the ecosystem.

> If Microsoft is producing a solid language / framework in the open and improving their product such that 3rd party "light-weight" libraries like Nancy are no longer necessary, why is that a bad thing?

Because they are killing community made solutions by reimplementing the same solution and utilizing community's habit of favoring only MS software that they themselves engraved into that community throughout the years, even if original solution was better, thus closing the circle. They essentially kill the community around .NET themselves because instead of supporting projects like Avalonia, they reinvent the wheel(often ineptly) to ride on that 'Microsoft ecosystem' wave. The only exception to that that I know so far has been Polly that they pulled into .NET Core.

If it's all open source, why does it matter? My node_modules folders are a good example of why having thousands of individual open source fiefdoms is not always a good thing.

I don't think the Avalonia example is a good one either. Nobody talks about why Ruby on Rails doesn't support Sintara. In other ecosystems, every project is in competition. Why should .NET be singled out.

I think the argument that open source software can't compete with Microsoft is total bunk. If the alternative is competitive, it can succeed. Dapper has been around for over 10 years. Avalonia is "used by >170,000 companies, including 431 on the Fortune 500 list" according to their own website. Xamarin joining Microsoft is pretty much why we're talking about .NET 6 right now. Microsoft's first party solutions are really very good (in house or acquired). This is again why you might choose .NET over a more chaotic ecosystem.

Probably not.

I've heard the more recent releases of .NET have been pretty good, but I don't see any real reason to be interested in it. There are already plenty of good options out there.

MAUI, maybe?

https://github.com/dotnet/maui

Based on past experience it’s a very very very bad idea to rely on anything that MS does in the desktop development area. I would be shocked if MAUI wasn’t dead in five years.

Low/No code solutions are really eating the lunch of where C# was useful in large internal apps. I use it because F#, but it’s getting harder to sell that.

Depends what you're after. The only correct advice for "what to do a project in" if you're looking to ship and/or make money is "use what you know" so any advice beyond that is heavily contextual.

There is no killer feature for .NET I think. That's why it's a hard sell. I think its sales pitch is more or less parallel to Java (though I prefer C# to Java and VS to IntelliJ).

Do you want a statically typed, extremely fast, cross-platform language with a comprehensive standard library and huge ecosystem of 3rd party packages with almost unrivalled devX (Rider on non-Windows OSes) and streamlined packaging and deployment that allows you to scale from single person PoC to large team development within the same codebase with no additional overhead?

I'd note that it's a bit of a jack-of-all-trades when it comes to desktop and ML. The ML.NET package keeps getting better but for those areas where there's an obvious standard, e.g. Python for ML, you may as well use the standard for that thing. The desktop story continues to disappoint and I'd advise people to steer clear of desktop unless they want a nasty surprise. But for web applications I'd not want to use anything else.

>I'd note that it's a bit of a jack-of-all-trades

And that's why developers and companies like it. It is a good, easy to use, well supported, well documented, sane jack-of-all-trades.

C# is fast and .NET core is cross-platform. It's good for games, web, and mobile development. F# is a great functional programming language. There are fun tools like SignalR (easy websockets), Blazor (write C# and run it in the browser through WASM), and LINQ (built right into the language and allows you to query objects like a database).

Toplevel programs should make it easier to experiment with C# if you're interested. We also have first-class support for C# commands in https://ab.bot if you just want to play around with the language and make a fun Slack bot or something, although it might take us a week or so to get move up to .NET 6.

> and LINQ

Shudders at memories of coworkers writing giant, ridiculously inefficient LINQ queries without understanding how it's actually using the database and what it's doing server-side

> Toplevel programs should make it easier to experiment with C# if you're interested.

Definitely interested in that small feature :) If I had extra time I'd like to see what it takes to brew install dotnet and write a simple CLI program. Can .NET deploy a static binary nowadays?

True of nearly all ORMs really. LINQ on objects basically makes C# a very nice functional language. Dapper is arguably better for database but then use LINQ in those results is very nice.

I almost wish they hand't wrapped IQueryable and IEnumerable under the same branding. I get that there's a lot of overlap at the interface level, but, in terms of what they're doing under the hood and the effect on how you use them, they're really quite very different.

> True of nearly all ORMs really.

I disagree in a respect. I think with an ORM it's clear when you're hitting the database, though it makes it easy to write loops over (related) rows ("n+1 problem"). I think with LINQ using the same syntax/expressions across local and remote operations it can be more blurred what's happening.

> Can .NET deploy a static binary nowadays?

You can bundle everything in a single file but that file contains the runtime, so even small Hello World apps are 50MB+ last I checked, though there have been some improvements recently with trimming and AOT is hopefully coming next year with .NET 7.

Very cool, thanks for answering. Yeah I understand they'd have to bundle the runtime so that makes sense. Glad to know they're working on improving that use case as well.

They're really working on reducing the compiled (app + framework) size in order to make the WASM target in browsers more viable for Blazor.

Yeah, starts closer to 12MB for a trimmed console app in .NET 6. It works really well (I've been distributing one for a few months now).

LINQ is best when used on in-memory object graphs, partly for the reasons you brought up, and partly because then you're not dealing with weird limitations or deviations from how functions normally work etc. For in-memory queries, it's basically just a very advanced form of sequence comprehensions.

(I also suspect that the vast majority of LINQ code in the wild is of that variety, rather than Entity Framework etc.)

> Can .NET deploy a static binary nowadays?

You can, as sbelskie mentioned below. In .Net 6, it's available as a Preview [1]. But it's going to ship with the main framework in 7.0 [2].

The preview works quite well. You can build self-contained, smaller executables, and shared libraries callable from say, C code.

[1]: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/...

[2]: https://github.com/dotnet/runtime/issues/61231

I've spent much of my money-making programming time doing CRUD web apps in PHP. Several years ago, when .NET Core was in its infancy, I had the chance to try a different language for a new/different CRUD web app.

The .NET Core ecosystem was a lot sparser back then but picking up the language was actually the most pleasant "learn a new language and be productive in it" experience I've ever had, and I don't think I'd ever turn away from it now. YMMV, of course, depending on how much you like whatever you're writing in now.

C# is good for game development, building applications with sockets or creating small GUI applications. Though I admit that I have a bias since C# was the first language that I learned to program with. Plus C# has garbage collection and multithreading!

* Runs great on Linux in my experience & others

* Great performance - https://www.techempower.com/benchmarks/#section=data-r20&hw=...

* Open source - Microsoft has made a lot of missteps but they have came a very long way. The bright side is both how far they've came & the outcomes of the recent missteps.

* Very productive toolset imo. I focus mostly on web based tech though. I really like the syntax & type system.

* Swiss Army Knife in that you can use .NET to do just about any type of project - Web (front & back end), mobile, games, IoT, desktop, machine learning, etc.

* You can use C# & F# syntax, both very popular (though let's all be honest, F# is a 2nd class citizen in .NET but it's got a great fan base)

I don't think F# is that second class anymore especially if you are developing on Linux/Mac OSX. The more concise language/syntax is a big plus when you don't want the heavy IDE and want to be cross platform. The VS Code plugin for example seems more mature than Omnisharp and while like any other Code plugin less flaky than many of the others.

It seems to be keeping up with the broader .NET ecosystem pretty well I think - (https://devblogs.microsoft.com/dotnet/whats-new-in-fsharp-6/). In some ways it is ahead of C# as well so I wouldn't say it is behind at all.

I think there's at least one way in which F# is a second-class citizen: documentation. The documentation for anything in .Net will contain code in C#, but code in F# is quite rare.

So if you want to use F#, I think you still need to be able to read C# code.

It might not be full second class but I dunno I'd go all the way to first class. For example F# doesn't support the source generators feature that came with .NET 5 (unless they added it in 6 and I missed it but when I looked at that post you linked I didn't recall seeing it).

They got type generators which somewhat influenced and predates the Source Generator feature by a few years. Not the same thing of course, and from what I've seen are slightly different in target/scope. (e.g. F#'s seems more appropriate for scripting where you can use it without a proj entry).

Do you mean type providers? That's their own type of nice thing but to your point it is only for generating types, source generators can generate much more than a basic type. Also I swear I saw somewhere type providers were not functioning as well in newer .NET but that was hearsay as I never tried them in 5 and now 6.

They are working in .NET 5 last time I checked. Opened an FSX script, "#r: nuget SwaggerProvider", point to a JSON API and it seems to work with IDE auto complete included with 2 lines of code, no project scaffolding, or package manager files required. Things seem to be improving on this front I guess as well.

I do agree - source generators have a better API as an implementer and can generate more than classes. I guess as soon as I need to jump into a proj file and I'm working with MsBuild anyway what stops me creating my own generation framework that runs before PreBuild that generates code for my compile step? I've done it before source generators were a thing.

I also did a quick Google search - Myriad (F# library) might be something that does something similar.

Oh Myriad looks super interesting. As I figure out what I want to do as I pick f# back up more seriously I'll have to keep this in mind.

> I certainly wouldn't feel comfortable to say to my team "let's do this next project in C#".

Could you expand a bit on that?

I used .Net 1.1 and 2.0 for awhile, and coming back to it now while deciding the future path for our application.

I left .net around the 2.0 days and came back with .net core 5.0. It's a world of difference, and absolutely worth checking out again. If anything, you don't need Windows to run it, and there's great tooling support outside of Visual Studio (VS is still pretty nice though).

As someone who programs with .NET in their day job...no probably, not.

Outside of a few areas related to DDD, event sourcing, and some distributed-system frameworks (NServiceBus and MassTransit) there's really no killer app for .NET, in my opinion.

The big selling point for .NET now is that it runs on Linux...which is not really a selling point in the grand scheme of things.

ASP.NET Core is an excellent and high-performance general purpose web framework.

Blazor is an excellent C# on the browser stack.

And MAUI will target React Native (native controls) and Cordova (Blazor on Maui) at the same time ... which is extremely powerful. But that is half a year out.

.NET has a lot to offer if you take individual app models of it. If you want to stick in one language, it is even a top contender.

Linux selling point is already gone. That is standard already for 5 years now.

> If you want to stick in one language, it is even a top contender.

That's why I like it. Not only being able to do tons of stuff with one language, but using the same frameworks and libraries.

I'd say the ability to run on Linux is a major selling point. Without this, I think .NET would have largely disappeared.

> I don't see any particular reason to make my own tools in C# vs anything else.

I can tell you why the company I work for uses C# to develop microservice based products:

-cross platform

-tons of libraries

-integration with most of the things we need

-great speed

-good productivity

-great tools

We can iterate fast, have performance. Also, C#/.NET is good for other purposes such as mobile apps, frontend, writing glue code, and even desktop if the need arises.

>> ASP.NET Core in .NET 6.

I've been on .net since 1.1 and .net Core since 1.0 and this statement makes me so confused.

Core lives _inside_ of .net 6? Is there a non-core ASP.NET that also lives inside that framework?

I thought .net 5 was where the legacy 4.x branch and core 3.1 was married in holy matrimony, minus the worst of the legacy garbage.

I think "ASP.NET" would imply the legacy web framework, so they had to keep the "ASP.NET Core" name. Not unlike EntityFramework & Entity Framework Core.

Naming it ASP.NET 5 would clash with .NET Framework ASP.NET 5 MVC, hence the ASP.NET Core 5 name.

I see all 'Core' names being dropped with the release of .NET 7. So it would be .NET 7, ASP.NET 7 , EF7

I look forward to the announcements of Office Core and Windows Core.

https://docs.microsoft.com/en-us/windows-server/administrati...

Reminds me of this: https://www.itprotoday.com/net/windows-net-server-first-look

Oblig: https://stackoverflow.com/questions/51390971/im-lost-what-ha...

Wow, I take it you are the author of that post. That is incredible. You need some sort of presidential medal for that.

And a bunch of people probably had a bunch of meetings and sat around and thought "Yes, this is what we will name it!" FFS!

So no excuse for .Net 6 since there was no ASP MVC 6 right?

There was. ASP.NET MVC 6 and EF6 were the last versions for .NET Framework 4.x. Hopefully with .NET 7 next year and all the versions aligned they will drop the "Core" name for just ASP.NET 7 and EF7.

And someone will finally cross out that Jira (er, Azure DevOps) task on their list. "Harmonize branding and version numbers across all major .Net technology offerings", only took them ten years or so.

Asp Mvc 6 was never released, it basically became MVC Core 1.

.NET is sane now... .NET 5, .NET 6, .NET 7... all cool, no more confusion going forward... .NET Framework(full Windows only Framework) is .NET Framework 4.x, stuck there forever only security patches...

Only remaining confusing part left in ecosystem is "ASP.NET Core", because even though .NET got rid of Core, latest version ASP.NET didn't

And Entity Framework Core unfortunately because EF6 was already a thing.

Yeah, hopefully as others have pointed out, with .NET 7 next year all the version numbers align so that ASP.NET and EF can drop "Core" again.

Searching the internet for help is going to be a nightmare, though.

Shouldn't be too bad, I don't think, if you remember the version number. Which anyone that worked in ASP.NET 4, 5 or 6 was generally pretty used to (a lot of things changed between versions even the "classic" .NET Framework days). I still have "fond" memories of fighting to find a specific EF6 answer that was different from EF4 or EF5, but that was still somewhat easier than having to remember to add "core" to all your searches lest you get classic EF3 results when searching for EF Core 3.x help. Having a version number high enough that you no longer need "core" is something I'm looking forward to.

I guess they could do that, but what makes you think they actually will?

I stated "hopefully … they can". I mangled the commas on that one, but that was the intended statement: "hopefully they will". I have no idea if they actually will.

There was an EF7 RC1 version, and .NET 7 isn't LTS. Dropping "Core" is better done in .NET 8 - or MS could pick an entirely new name.

Well, part of the problem with the naming for ASP.NET is that the .NET Framework version (WebForms) was simply called ASP.NET, so they couldn't just drop the "Core" like they did with .NET itself.

ASP.NET isn't only WebForms. It also covers the Razor engine as well as their WebAPI (API only).

btw. webforms is dead. thank god.

It’s easy. You have .NET Framework 4.8 which is followed by netcore 3.1 which is followed by .NET 5 and now 6. 4.8 supports netstandard 2, core and 5 additionally support netstandard 2.1. You can then use ASP.NET with 4.8 or ASP.NET Core with 3.1 onward. Entity Framework is only supported on 4.8 and Entity Framework Core up to 3.1 support netstandard 2 so .NET 4.8 and 3.1 onwards both. But the versions after 3.1 (obviously they went to 5 there) only support netstandard 2.1 so only dot net core 3.1 and onwards.

Perfectly clear and reasonable.

As far as I know that's because asp.net mvc 5 already exists. For example Entity Framework 6 already exists so the new stuff will still have the name core until the number is high enough that there is no legacy stuff with the same number anymore.

> Core lives _inside_ of .net 6? Is there a non-core ASP.NET that also lives inside that framework?

Yep!

> I thought .net 5 was where the legacy 4.x branch and core 3.1 was married in holy matrimony, minus the worst of the legacy garbage.

.NET 5 was the next evolution of .NET Core. There was no great merging of legacy .NET Framework into the .NET Core branch or something like that. It saw a bunch of foundational stuff land in so that .NET could support modern client apps from Xamarin and further support the modern versions of WinForms and WPF.

If that sounds confusing, it kind of is. But it's a clear branding effort - .NET is not a choice between the "slim .NET Core" and the "big .NET Framework. It is either .NET or the legacy stuff (still called The .NET Framework).

Microsoft branding is terrible. My only point of contact with it is Visual Studio Code which is different from Visual Studio which is different from Visual Studio for Mac.

There was a brief period of time after I recognized that .NET really works on all platforms without proprietary stuff and before the `dotnet watch` desaster in which I was at least curious about .NET. But even then I never fully figured out how .NET, .NET Core, ASP.NET, .NET Framework, .NET MAUI and the kitchen sink relate to each other.

If the purpose of branding is to make something recognizable, Microsoft consistently fails across the board with me.

We used to have a saying on the team when I worked there:

"Nobody can name things like we can't!" (followed by cry-sobbing)

The more serious response to this is:

For better or for worse, The .NET Framework (which is now squarely legacy tech) has stuck around and been reliable. People have had their trust in it validated. For two decades now, if you're a CTO at some big enterprise, you know that .NET Framework will get the job done for much of your development needs. From a Microsoft branding perspective, this is amazing. But it's got all kinds of problems can't be fixed unless you break everyone. Uh-oh!

This is the biggest reason why branding and naming has been so complicated pver the years. And it's even come with little sub-problems, like the fact that the version number for one "flavor" of .NET would match up with the version number for another "flavor" of .NET and so now you're screwed no matter which decision you pick.

A cleaner approach would be to throw it all away and do a complete rebrand (we had a little proposal to call it "Concert" where C# and F# could be played in harmony with each other, how cute) but with that you throw away the brand of one of the most successful pieces of technology ever produced by the company. Not exactly a winning proposal.

The other factor here is that with .NET there is so much software involved. It's three entire programming languages, a runtime, a huge standard library, a web framework, a database access and management framework, a machine learning framework, several Windows app frameworks, a mobile framework, IDE tooling, command-line tooling, and a bunch of other stuff too. .NET is far larger than many other competing stacks in terms of what a single vendor produces. Since Microsoft produces so much software for .NET and aligns their releases, they also message each one, and with that there's a big sea of stuff to keep track of.

I don't know if I have an answer for how to handle the complexity of it all. A lot of folks I know in the F# community only keep track the F# language and IDE tooling updates, then dive into specific stuff only when they care about it (e.g., doing web programming? check out the ASP.NET release notes). But that may not be an option if you're a decision-maker at a company.

> Microsoft branding is terrible.

Agreed.

> I never fully figured out how .NET, .NET Core, ASP.NET, .NET Framework, .NET MAUI and the kitchen sink relate to each other.

You're not the only one who is massively confused about everything that is labelled .NET or Core.

If anyone else is struggling, I recommend this (I wrote it):

https://dusted.codes/dotnet-basics

Great article, thank you.

You've done a really nice writeup here. To me it reads as someone patiently explaining the basics without being patronizing.

Wow, I will surely pass this to my students. Thanks for having written it!

Just wanted to say thank you for the write-up, it helped bring me up to speed on the state of dotnet as I am looking to get back into it

Agreed 100%. Even seasoned .NET devs can’t tell what all this stuff means and what the implications are. I wonder if anybody at MS really knows.

I'm developing with .NET for a decade and I can understand and explain the difference. The trick is too read about it from time to time: miss a few years and there is a lot to catch up. I can see how it can be a nightmare for beginners or people not following closely.

The naming for .NET got tough when it was decided that open source and cross platform was the way forward. If that had not happened it would all be called .NET framework to this day.

>.NET, .NET Core, ASP.NET, .NET Framework, .NET MAUI

ASP.NET Is the web framework that comes with .NET

.NET MAUI is the application user interface framework that now comes with .NET (Since .NET 6)

.NET is the overarching term for everything .NET.

.NET Framework refers to every version of .NET 4.8 and before. .NET Framework only ran on Windows (unless you used Xamarin to run it on other frameworks. Xamarin was a third party implementation of the .NET framework, it is now owned by Microsoft as well).

.NET Core is the new version of .NET. In the first 4 (I think) versions it had it's own branding, .NET core 1, 2, 2.1, and 3. .NET Core runs cross platform across the desktop OS's natively. Xamarin was still used for mobile development.

What would have been .NET Core 4 has been rebranded as .NET 5. Xamarin at this time was brought into the fold, allowing full functionality of .NET Core API's across desktop and mobile. I believe this rebranding was done because .NET Core was being considered full feature enough to take over the legacy of .NET.

One thing you didn't mention but I'll touch on as well, is .NET Standard. Lot's of people get confused about .NET Standard. .NET Standard is just the definition of what different frameworks that implement .NET Standard can use. So if you write your code to target .NET Standard you can't use .NET Core specific API's but what you can do is have the same code compiled against .NET Standard referenced in your .NET 4.5 - 4.8 Code, or your Unity Code, or your Xamarin code. It was primarily designed with libraries in mind.

> ASP.NET Is the web framework that comes with .NET

Not quite. ASP.NET is the web framework that comes with .NET Framework. ASP.NET Core is the web framework that comes with .NET Core and .NET.

> .NET Framework refers to every version of .NET 4.8 and before.

It was fine to call .NET Framework 4.8 just ".NET 4.8" in the past, but I would avoid it now, to clearly separate .NET Framework 4.8 from .NET 5.0.

>.NET MAUI is the application user interface framework that now comes with .NET (Since .NET 6)

Not quite, MAUI has been delayed until next year.

There are more purposes for branding and if you have people calling themselves ".NET developers" you probably want to stick to that brand instead of coming up with something new that people would not trust.

I believe people would not jump as easily onto that wagon if it would be called "Silverlight Core".

>> Is there a non-core ASP.NET that also lives inside that framework? > Yep!

No, the "non-Core" ASP.Net framework is not ported to the .Net Core platform (i.e. .net 5+). Only ASP.Net Core runs on .Net Core.

This is unfortunate, because it means older web sites based on the classic ASP.Net does not have clear migration path to .net 5+.

the old "framework" versions are in maintenance mode. That is the OG aps.net and framework. it's currently at 4.8 and will probably stay there forever. This includes the OG versions of things like ASP.NET and Entity Framework.

The open source multi platform rewrite, originally named core, now named "", is going to be the active platform going forward. There are several core rewrites of the popular modules that will be the ones that are actively developed going forward.

We can either stay on 4.8 forever, or migrate to the "" which is where all the new and exciting things are being developed. MS has promised they will support 4.8 for the foreseeable future, for what it's worth.

Here's a video explainer: https://youtu.be/4olO9UjRiww

Microsoft is easily the worst at naming things.

At this point I've given up hope at grokking the various names within/peripheral to dotnet.

Looks like .NET Framework has had it's life extended as well. It is scheduled to be installed on Windows 11 and Server 2022 which gives the 10 year native to OS support. https://docs.microsoft.com/en-us/dotnet/framework/migration-...

The naming really is confusing. "Core" was the keyword for several semi-independent projects.

There is .Net Core, which was a rewrite of the .Net runtime to make it platform independent.

Then there is ASP.Net Core is which is a rewrite of the ASP.Net web stack. Despite the name, this was not initially dependent on .Net Core platform, it could run on both .Net Framework and .Net Core.

ASP.Net Core is the only web framework running on .Net Core though, the old ASP.Net framework is not ported to .Net Core. So to answer your question, no, there is not a non-core asp.net running on the .Net Core platform.

Then there is EF Core which was a rewrite of Entity Framework. Again, this was not initially dependent on .Net Core, although later versions is.

Basically "Core" just means "new backwards-incompatible rewrite".

Welcome to .NET :)

It requires a PhD to understand versioning at this point.

Historically — yes, ASP.NET Core 1 and 2 had the ability to live _inside_ both .NET Framework and .NET Core.

As a relatively new engineer (~2 years FAANG experience), there seems to be a connotation around .NET.

Perhaps this is indicative of the larger Microsoft ecosystem, but it feels like my peers at university and in the industry tend to stay far away from .NET for personal projects, etc.

Why is this?

I can't answer your question directly but I can add that what I've noticed is frameworks and language seem to be very regionally orientated. I've noticed on some parts Java seems popular, other parts .net, and so on. It's quite interesting to see differences in job ads across regions globally. In my region, .net is used extensively and my friends do tend to use it for personal projects.

I think you are correct. A couple things probably at play:

1) Region (for example, my data point is from Boston)

2) Framework language choice (https://insights.stackoverflow.com/survey/2021)

3) Ecosystem (i.e. Microsoft vs. Unix)

4) Experience level (probably)

If anyone has any SF data points I am extremely curious.

Definitely true. The netherlands for example is VERY Microsoft oriented. I come across .NET everywhere.

I once saw a world map annotating the dominant dev stack in different regions, and yes, it's absolutely a thing.

I've primarily been a .NET Developer (a few stints using Java/Python) since I finished college when the original .NET first RTM'd (2001). I think today's Microsoft and the Microsoft of 20 years ago are very different. Make no mistake about it, they're still interested in making money first, but their strategy has changed (it had to.) I think that old reputation haunts them (and .NET) It's too bad, because it really is a great cross-platform framework (at least on the server side.) I will often try other languages/frameworks for my side projects and I always go back to .NET. Maybe it's because of familiarity or because I'm obviously more productive with it than Java/JS/TS/Go/Rust/Elixir/Python/etc.

A lot of people in the industry were turned off of Microsoft. Also academics tend to have FOSS-adjacent philosophies. IMO this really became a passion/pathology in the 2010s when it became viable and quite easy to live M$-free.

Another aspect is that M$ tools are used by millions, it's just that there's a selection bias for tried-and-true tool users to just quietly make things work. "Blue collar programmer" comes to mind. All the leading-edge churn, noise, and fatigue is the corner of the industry that generates tons of blog posts and HN links.

Most/all of their offerings seemed like legacy software/tools once IntelliJ, big JS projects, and SPAs became such a popular solution for software development on macOS and Ubuntu.

Now with VS Code, TypeScript, heavy dev in GitHub platform, cross-plat .NET, vcpkg, etc... and generally very powerful dev tooling, they actually have excellent offerings.

All that said, M$ clearly has a long road ahead of earning back good will in "high" tech corner of the industry and Academia.

Perceived cool factor, I think.

Both .NET/C# and Java are the core of Dark Matter Development [0]. They're what a huge chunk of developers and enterprise actually use but they're not cool and they don't get blogged about.

Obviously the history of EEE and Windows only legacy means there's a lot of hostility to anything .NET specifically amongst a subpopulation of developers. However I don't think it sufficiently explains the lack of noise about both Java and C#.

It's a bit of a shame because it would be nice to have more startup opportunities in .NET (or Java/Kotlin - rather than slow, dynamically typed, error-prone scripting language du-jour), there are some but they're a tiny minority.

It's hard not to get caught up in worrying about the future of one's favorite language/ecosystem but then I think over time the obvious benefits of the ecosystem will win people over, I hope.

[0]: https://www.hanselman.com/blog/dark-matter-developers-the-un...

IMO Java/.NET just don't get blogged about _on this site_. If you visit /r/Java, /r/dotnet etc, you'll actually find the content about them.

The issue with /r/dotnet is that most people there are almost fanatics. A single bad word about MS or any topic of the month like MediatR gets you downvoted to oblivion. There's almost no real discussion there.

Not a new thing. I recall the same fanaticism on big C# IRC channels back when .Net 2.0 was in beta.

Getting blogged on this site is the goal.

Getting blogged on a site that is dedicated to that tech is not noteworthy.

You can find such blogs or forums for every obscure language that has more than a 1000 users.

Java and dotnet aren’t obscure languages. Java’s user base is larger than anything on _this site_. Java bloggers also know that HN isn’t their target audience because they know HN is biased. It’s a much more worthy investment to reach the actual community who are going to come back to your site and actually discuss your content.

> It's a bit of a shame because it would be nice to have more startup opportunities in .NET

Even if you ignore the history of companies like MS and Oracle what it comes down to is vendor lockin. If there's a chance a vendor will pop up in 3 years time with a huge bill, why take the risk when there are plenty of free alternatives.

I think there is zero chance of that happening.

MS recently made one tiny decision that was unfriendly to open source, it caused a huge outcry and a reversal within 48 hours on a weekend. I can't even imagine what the reaction would be in your scenario.

Besides, basically everything is open source now and you can't put that genie back into the bottle.

SQL Server, Windows and Oracle DB are open source?

Saying that outcry was about one tiny decision is like saying WW1 was because an Archduke got assassinated.

Microsoft's handling of .NET 's OSS community has been haphazard at best. Just a week or two prior to the 'dotnet watch' debacle, there were issues and concerns with the .NET Foundation that led to the Executive Director stepping down [0].

I bring this up, because in many cases the perception is that there is -still- lock in, just in a different fashion.

By that, I mean, if you Ask a typical .NET developer what they use, they'll probably say ASPNETCORE, EF Core, maybe you'll hear Hangfire, MediatR, RestSharp, or Dapper.

So, you've got a bunch of .NET devs that -only- know Microsoft technologies for the most part. Yeah there's some other stuff like MongoDb, Kafka, Redis, stuff like that, but It's not very frequent you hear about teams reaching out to other technologies.

It's very rare I hear people bring up Linq2Db, a beautiful* Micro-ORM that is best described as a type-safe, extensible SQL DSL. Or Websharper, a really-freaking-cool library that basically lets you transpile your C#/F# code into Javascript and/or Reactive HTML, complete with seamless server calls if you'd like.

You might run into some interesting things at different places. One shop I was at used MassTransit, which was kinda cool. I've wound up using Akka.NET a few times in the past, which has always been super fun.

The end result of this though, is the -perception- of what .NET Developers are like. And sometimes those perceptions are real. I remember the dev that felt Dapper was some sort of 'black magic' and would stick to writing DataReaders and or datatables by hand, and another that was so against the idea including Non-MS tech in a project that it wound up costing him his job; he insisted there was a way to get EF to do things in a performant way (answer: not sanely, and not easily the way the app was built on an arch level,) and refused to accept a PR that solved the problem with Dapper.

He wound up doing the thing I've seen a -lot- of .NET developers do; fight the Framework.

To be clear here, I'm not referring to the BCL. It's not always perfect (I'd love for an analogue to SSLEngine, please?), but it's -fine-. I'm referring to bits like ASPNETCORE, EFCore, SignalR, and Microsoft.Extensions.(DependencyInjection/Logging) where developers wind up getting in awkward tarpits around some weird edge case because of a business requirement or some other decision that, unfortunately, can't be undone.

Or are just plain 'well, that sounds sensible in theory' like "I would like to update N rows in an new status that are older than 1 month and set to overdue, and not have it be N update statements." Maybe EF does that now, but last I knew the answer was not really.

At my first 'Real' Dev job, we were a .NET shop, that often had to 'fight the framework' (it didn't help that we were on an Oracle Backend, which made -everything- more of a PITA before we discovered Dapper.) When the .NET guys hit one of these roadblocks, it would often take sprint after sprint of fighting to either have no solution, or have a solution that would render the app hard to maintain. The newer teams using Java? They didn't have those problems. We later heard they had 5 different ORM-ish libraries in use over there. At the time, a lot of the .NET devs kinda treated it as a sort of derision. 'hows somebody gonna understand it?'... But the Java teams delivered. It is also worth considering, maybe those were the best libraries to solve the problems that the app in question needed to deal with.

And that's kinda the 'mindset' that is a set of .NET developers that fit the stereotype; if it's not an app that fits their cookie-cutter world, they break down and can't understand it. In other words, they're afraid to step outside the box, which means they're less likely to think outside the box.

The typical 'litmus-test' of this type for me is a sliding scale based on their past/current experience with other languages and willingness to work with them.

* - I do some contribution work to Linq2Db, so my opinion may be a little biased.

[0] - https://github.com/dotnet-foundation/Home/discussions/39#

Java is one of the very few languages with a complete specification, instead of the usual “here is a binary, whatever it compiles to, that is the language”. Due to that and its size, it has plenty of independent implementations, so vendor lock-in is simply not a risk. But even if it were, the Oracle-developed and completely open-sourced OpenJDK project uses the exact same license as the Linux kernel, so no, noone will get sued, you can change to whatever else, etc.

Not just "cool factor".

From your linked article: "Where are the dark matter developers? Probably getting work done. Maybe using ASP.NET 1.1 at a local municipality or small office. Maybe working at a bottling plant in Mexico in VB6. Perhaps they are writing PHP calendar applications at a large chip manufacturer"

i.e. in Cost Centers not Revenue Centers, which is to say in jobs that do not pay well, and their management is trying to figure out how to spend less money, not make more money.

Exactly - .NET ecosystem and community is structured around cost center development.

I see Microsoft attempting to make C#/ASP.NET more lean and faster to get started with (eg. minimal APIs) but I doubt they can overcome the stigma.

I was working with .NET most of my career. And I've been in a cost center just for one year.

And I'm sure some COBOL developer out there is working on new projects.

That doesn't change the fact that .NET roots are in old enterprise and Java - which was dumbed down by design to make it easy to onboard unskilled developers (look at their arguments against local type inference and lambdas before they were added).

Things like ASP.NET core slam you with heavy duty abstractions from ground up and justify it by project scaling and reducing maintenance cost at the expense of iteration speed - again tradeoffs made for large enterprise const center style projects.

With recent iterations (minimal APIs, top level functions, namespace declaration, etc.) they are trying to reduce those tradeoffs and cater to the startup crowd but the MS + corporate budget development stigma is going to be there.

"Dark Matter Development" -- finally I have a name for it!

Sometimes you see articles on the Internet where someone basically says something along the lines of "All developers use the Linux bash command-line workflow", and I just look at statements like that and wonder what on earth are they talking about!?

I have never seen a developer familiar with the command line. I have never seen a developer willingly use a Linux desktop. I have never seen anyone do anything but boring, "dark matter" .NET and Java development using IDEs on Windows.

I'm not talking about a couple of guys here. I mean that I have met or interacted with hundreds of developers across dozens of organisations!

Literally not one has ever said: "I wish I had bash", or any similar statement.

I tell a lie. I just remember that the one startup that I worked for had: Linux, bash scripting, allergies to Microsoft, hip-new-technologies, etc, etc...

I agree. I am from India. My whole life I have used Windows. Usage and teaching of Unix / Linux is severely limited to top universities, and only because they copy the US university culture (most professors are US educated)

90% of the articles on the web, are 100% certain that I have a use VIM / Emacs, on a Linux machine.

Where are the articles that focus on the rest of us?

What kind of articles make assumptions about your preferred text editor? Or do you mean they assume you're on Linux in general?

As a random example, the justification presented for VS Code using "up arrow" to view the search & replace history is that it matches the "bash standard". Every other Windows text editor in the history of the world uses down-arrow.

Similarly, Microsoft broke how clear screen works in both Windows Terminal and VS Code to match the UNIX terminal standard.

Hint: Neither of these are standards by any definition, and UNIX people were arguing over both of these things at length themselves.

Before we forget: VS Code is made by Microsoft employees and is primarily deployed by people using Microsoft Windows.

But it has to adhere to the "standards" that Microsoft developers are used to and expect.

> I have never seen a developer familiar with the command line.

There are a lot of CLI devs out there, even in enterprises! I highly recommend gaining proficiency with the command line, as it will make you a more productive developer in the long run. While most everyday tasks may have a GUI, if you end up working near the cutting edge, you will likely encounter problems that do not have any GUI alternative. And if you end up working on a rare problem, no GUI may ever emerge. Your CLI skills may be the difference between a 10-minute solve and not being able to accomplish the task at all.

I spent > 10 years building on Windows, and this advice definitely applies to the .NET ecosystem as much as others. On Windows, Powershell mastery will set you apart.

I thought we were calling us plumbers >:(

Don't think it's just about coolness.

In .NET there is usually one way to do things, the MS way. You don't have options. Whatever MS prescribes is practiced by most enterprise shops. I remember arguing for something closer to MVC (several open source solutions) when ASP.NET forms was the way to do things. It wasn't until ASP.NET MVC came out that enterprise shops came on board.

I still see a lot of documentation that shows Visual Studio screenshots. How am I supposed to do that on Linux? .NET still feels like a Windows first solution. You will not find official docs for Python, Node or Go using OS-specific IDE or editor screenshots.

>In .NET there is usually one way to do things,

There are infinite ways to do things. But the most easier way to do things is one. And that is good because anyone can understand anyone's code.

There are many languages that are easier to follow than C#. Every import in Go or Node is explicit. You don't need an IDE to tell you which package a method originates from.

Anyway, my point is there are very legitimate reasons why most startups don't use .NET. And it rarely has anything to do with being cool.

I needed to learn dotnet for my new job, and I use MacOS and Linux when developing. Took a course on dotnet and entity framework, and when it came time to set up the database stuff of course both the tutorial and documentation on the official dotnet framework page showed instructions specifically for Visual Studio. Had to do some googling and reading GitHub issues to find the command line solution.

When the .Net Foundation was announcing that they were going to drop the hotreload support from dotnet watch in favour of supporting it in the Visual Studio editor I was again reminded of how (some parts of) MSFT think that dotnet should still be a fully integrated development platform for Windows, rather than a multi platform, open community and open source project. I guess there might be some internal power struggle there between various business interests.

There are already more Linux VMs on Azure than there are Windows VMs. And if they still insist on making the dotnet experience on Linux and MacOS subpar compared to Windows they will very quickly find that people who develop for these OSs will move towards Java or other languages and frameworks with better support for these operating systems.

>, but it feels like my peers at university and in the industry tend to stay far away from .NET for personal projects, etc. Why is this?

It's leftover industry bias because of Microsoft's long history of a proprietary tech stack that costs money to use. Today's Microsoft of promoting open source VSCode doesn't really undo the mindshare they lost in the 1990s and 2000s when the internet got big. I wrote previous comment about this: https://news.ycombinator.com/item?id=20256825

C#/.NET (including WinForms and ASP.NET) was instantly popular with corporate enterprises but Microsoft never captured emerging startups with their tech stack. E.g. 1990s startups like Ebay, Amazon, Google, etc all used Java+MySQL+Linux instead of C#+MSSQLServer+MSWinNT. And new high-profile open-source projects like Hadoop, Cassandra, Elasticsearch, etc chose Java instead of C#. I currently can't think of a famous project where the canonical source is C#. I use iText C# library but that was ported from Java. That's how it usually evolves. A lot of C# libraries were actually Java projects at first.

A part of this is that MySQL can have read only scale-out replicas for zero additional licensing cost. You pay only for the hardware.

In Microsoft Land, the SQL Server team considers this an Enterprise feature, which basically translates to: "We added a couple of zeros to the price".

THIS, I feel, more than anything, meant that the Microsoft stack was just a dead end for many startups. The licensing cost for the database alone exceeded their revenue.

This was already crazy back then, but since then Microsoft has doubled down and increased SQL Server licensing. It is eyewateringly expensive now, and even their Enterprise customers are slowly starting to switch away from it.

They're slowly but surely turning SQL Server into Oracle.

Into Oracle? Isn't it also expensive?

I mean that Oracle is even more fantastically expensive, and the SQL Server team wants the charge a comparable amount. They're slowly but surely working up to that level...

Ah I see. I misread they as Enterprise customers.

In my country and some European states .NET is far more popular among devs than Java. Depends mostly on the region and what is taught in universities. The two most popular unis in my country all use teach .NET in the final years of studies and a lot of professors are MS MVP's.

In the late 90's and early 2000's Microsoft made a real effort to prevent people from being able to choose any operating system other than Windows. They've come a very long way since then, but they still profit from the enormous amount of software infrastructure still being developed today that's Windows only. For example, they've made it easy to run native Linux applications on Windows but they've made little effort to run native Windows applications on Linux. Their old reputation still haunts them and not everyone is convinced that they love open source and user choice as much as they say.

Indeed. It's not so long ago that Microsoft was draining the life out of open source with its bogus patents racket.

I think .NET is still seen as if it's Windows-only or Windows-first. If it does start being used cross-platform, I think it will take a lot more time to get there, especially since Java has been working just fine for the same sorts of projects.

And it's an especially hard sell given that it doesn't have a good GUI situation. Support for Windows GUIs is back since .NET 5, but the cross platform options are weak. It's very possible when the MAUI library finally releases that we'll see more people deciding to use .NET.

> And it's an especially hard sell given that it doesn't have a good GUI situation. Support for Windows GUIs is back since .NET 5, but the cross platform options are weak. It's very possible when the MAUI library finally releases that we'll see more people deciding to use .NET.

Avalonia is great and recommended by most people that used it. Or do we now only count Microsoft-made solutions and then whine that .NET is not open to OSS?

AIUI, MAUI does not include Linux support. There was a third-party effort to get that going, but it's not part of MAUI proper, and it looks somewhat moribund.

https://github.com/jsuarezruiz/maui-linux

The package manager is not the best, it may have improved since last I used it. Also .Net really needs Visual Studio (not VS Code) to unlock its full potential.

I'm using Rider professionally and it's miles ahead of VS. Colleague of mine works on the same project using vscode without issues as well. You don't need Visual Studio for anything anymore...

VS holds .NET back, IMO. VScode (proprietary version) is less powerful (especially on the refactoring side), but does have a bunch of nice features.

Rider is the perfect replacement, though. Comes with all the features of ReSharper (this is a big deal for many .NET workflows, VS may have integrated many of its features, but not all of them) and extensions and themes you can actually use (IME with VS of the 50% that promise to do what I want 90% are broken).

JetBrains just know what they’re doing. They’re clearly prioritizing quality (something the VS team seems to be actively working against).

Oh, and it’s damn near 100% compatible with VS projects (one thing I missed about 2 years ago were live updates of WPF XAML, everything else just worked).

Probably because of licensing costs. Take for example SQL Server. If you want to use it on a server with more than 128GB or RAM you have to get the enterprise version which is licensed per core and the cost is in the thousands per each core pair. Sure, you get a discount, but still the price is steep.

Which has nothing to do with .net. I work for a company that won't invest a cent in extra software licenses or dev tools but all my devs are in .net. For the database I use Postgres.

.NET is a difficult platform for people to learn programming, that's probably why. I've sum'd up everything that I think make it quite hard for programming beginners in the article below:

https://dusted.codes/dotnet-for-beginners

Even with my personal projects, I am wondering "What am I learning?" and "How might this benefit me professionally?" Other times I'm thinking "I just want this to work".

I started with C# with 1.0, back when structs inside structs didn't serialize properly. I've written iOS apps with Xamarin. I am a C# fan. I haven't used it professionally in a decade and my last personal project was years ago.

When is C# the right idea? The only time is when the project is entirely captured by the Microsoft ecosystem. There are plenty of places where this is the case. Windows desktop applications. Small business contract work who are still using Windows. Big business IT who still use Windows. Opportunities to migrate to Azure.

Where is C# the wrong idea? Everywhere else.

Writing for the best monetized mobile market? Swift.

Writing for cross-platform mobile market? Javascript.

Writing for cross-platform desktop market? Javascript. Maybe Java if you have a history of it.

Writing for the cloud? Something linux first. Javascript, Python. If you want a big GC language, why would you pick C# over Java?

AAA games? C++

Not AAA games? Maybe C# with Unity?

In every category where C# is used (outside Microsoft captured environments), there is a dominant solution which is not C#.

And that sucks. Because C# is awesome.

Yeah .. but there is one aspect in this argumentation: C# is everywhere a reasonable contender. So while you rarely get a dominant position (Unity and Backends) you get a lot of second places (Apps, Desktop, ...) which complement your full stack experience in an awesome language. And this is different to other languages: Python/Go: no-show in apps; JavaScript: no-show in data science; Swift: no-show in backends (thanks IBM).

From a management perspective, this is not bad. You get movable team members. In my company we have moved people from WinForms app, to cloud deployed micro-portals and then to a Apple/Android App (all different solutions .. not a migration). C# play a big role in that.

I think this is again a dark-matter-developer / line-of-business situation.

>From a management perspective, this is not bad. You get movable team members.

I have a friend-of-a-friend who has a successful 30 person contracting business. They do C#. He, the co-owner benefits from this.

I was responding to a question from a FAANG developer. FAANG developers don't get moved. FAANG developers move when they want to move: to projects that they find interesting; to other FAANGs; or to start-ups.

And FAANGs don't pick one language because "hey, it's possible to do what you want in it".

I honestly don't have first hand experience, but I seriously doubt every FAANG developer is the rock star you're making them out to be. I'm sure there are certainly plenty of FAANG developers working on boring shit that needs to get done.

>FAANG developers move when they want to move: to projects that they find interesting; to other FAANGs;

If a developer knows C# he can tackle more than one domain. Suppose you got bored and want to switch. Or there are new interesting opportunities. If you know C#, you just switch without having to learn a new language and libraries.

> without having to learn a new language

Well, at least you can if Blazor gets finished.

>without having to learn a new language and libraries

This. You see this as a positive. I see this as a negative. And we're both right, right? You are right in your domain, and I am right in mine.

One reason might be an awareness that Microsoft will be Microsoft and they tend to do things like putting "telemetry" in the CLI tools: https://github.com/dotnet/sdk/issues/6145

History. Microsoft technology used to suck terribly for small-time developers. It was always popular in the “enterprise” (which also brings with it some extra architectural baggage), but if you wanted to ship an app with it to consumers you basically couldn’t ... until Xamarin, Mono and dotnet core.

.NET 6 (or 5, or Core 3.1) is absolutely fine for personal projects. The tooling is great, it runs on Windows and Linux, the web stack is miles better than Spring Boot.

But if your personal projects are a stepping stone to a programming job, then .NET has a monstrous legacy problem. In 2002-2007 a lot of code was written using .NET in enterprises: it was the best way to write a rich desktop application for Windows and ASP.NET WebForms, while terrible, were an okay stack for intranet websites, certainly not worse than PHP5 without Yii or Laravel. And if you were a Microsoft shop, you got the best integration with MS SQL Server and (oh Lord) BizTalk if you used .Net.

But then Rails and Google Chrome came out and completely upended the webapp industry. Microsoft has been playing catch-up ever since.

A modern startup could certainly use .NET 6 instead of the framework of the month to write their world-shattering program, but they won't, because .NET isn't cool. A lot of .NET jobs are in stuffy enterprises where you likely won't be paid to write a backend to a Svelte SPA in .NET 6, you will be paid to maintain an ASP.NET WebForms 2.0 monster that uses WCF to talk to some SOAP/XML webservices.

Of course, the same applies to JavaEE, but Java has a second leg to stand on: people wrote FOSS in Java back when it was a dirty word at Microsoft, so not everything in Java shops is a terrible Spring/JavaEE mutant that has to be configured using vendor-specific XML.

Legacy exists in every company and platform older than some years. You either do the business of brownfield jobs or not. Every platform has their ugly history .. they just call them differently: SOAP/WS, RMI, CORBA, 2to3, PHP4, jQuery, AngularJS 1, ... . If a platform does not have history, I would be worried that I am riding something which soon is the legacy.

Microsoft does not play catchup in the web space. It is in the pack for some years already. The stuff they do with Blazor is at the upper end of the pack.

.NET, like Java, is not cool. It does not need to. It gets the job done without any experiments in a very modern platform. Doing a startup with boring tech is a thing.

So in summary: .NET is a very good choice for a beginner or converts. It is fresh, you can do solid stuff, do the full stack in one platform (web, desktop, apps, games, iot, ML, ...) and there are plenty of jobs (greenfield or brownfield).

Any idea why .Net rates seem to be significantly lower than for comparable Java roles? Seems to be true in the UK according to Indeed.

That is market specific. Cannot answer for the UK.

This wouldn't matter so much except that Microsoft completely broke all backwards compatibility for ASP.NET web applications. There's no "wizard" upgrade.

I'm working on migrating an ASP.NET 4.0 application right now, and it's basically stuck in the past.

Physically, yes, it could be updated by the developers to work on .NET 6.0, but no manager will ever fund this. They don't understand the benefits, and no amount of explanation will justify this effort in their minds.

So Microsoft basically stranded their customers on an iceberg floating away from the shore that is very slowly, almost imperceptibly melting...

> but no manager will ever fund this

Looks like the way to convince them is to tell them we will be moving to a <gasp> microservices <gasp> based stack and slowly start building the services on modern stacks (and gRPC)

I mentally translate "modern" to 0.3.54 build 72 alpha.

>Looks like the way to convince them is to tell them we will be moving to a <gasp> microservices <gasp> based stack and slowly start building the services on modern stacks (and gRPC)

We did just this at the company I work for. We are replacing an old monolith with modern architecture.

This. In many ways .NET Framework is to .NET Core/6 as Python 2 is to Python 3. The new stuff is all phenomenal, truly. But there are mountains of code running right now, responsible for billions of dollars of economy, still being maintained and added to, that will never be ported to the new. One wonders how our young industry of software development will evolve into the future, how many COBOLs are being created as we speak. Old cars, planes, bridges, buildings and roads eventually stop working and break down, but code is code. Or is it?

>then .NET has a monstrous legacy problem

Every enterprise targeting technology has the same issue.

In fact, that legacy is an opportunity to move into modern stacks.

The wheels started to come off with .NET back when ORMs became a thing, slightly before Rails. Look up "ALT.NET" movement for the history.

TLDR: Microsoft wanted .NET developers to only use tech from Microsoft, used various tactics to achieve that, and people got the message. If you wanted to use modern tech or develop innovative stuff, .NET was not a comfortable place to be.

Microsoft have tried to move past that, but never really have. .NET has never had a healthy Open Source eco-system.

>But then Rails and Google Chrome came out and completely upended the webapp industry. Microsoft has been playing catch-up ever since.

And where is Rails now? .NET is still thriving.

>A modern startup could certainly use .NET 6 instead of the framework of the month to write their world-shattering program, but they won't, because .NET isn't cool. A lot of .NET jobs are in stuffy enterprises where you likely won't be paid to write a backend to a Svelte SPA in .NET 6, you will be paid to maintain an ASP.NET WebForms 2.0 monster that uses WCF to talk to some SOAP/XML webservices.

I get paid to write a modern microservice based application using .NET, Kubernetes, Docker, Consul, Redis, Postgres. I can't say it's boring. But it is true, the app is for an enterprise, not a startup. The payment is relatively good and the app is making money for the company, so we aren't a cost center.

I can chime in on this one. I think it's very much a 'culture' thing.

So, I'm a *nix guy. You know, running Sway WM, using Doom Emacs as my daily driver, that sort of a thing. Learned vim to write my thesis at night on an armchair where using the mouse was not comfortable.

Not long ago I accidentally got involved with a kind of a .NET consulting gig. Rather, I got involved as a domain expert to help out some SaaS startup dealing with that domain, and it just so happened that they were writing their thing in C#. Before that I hadn't used C# at all, mainly dealing with Python and C++. I liked the language, I thought the tooling on Linux was pretty decent. The ecosystem was a bit lacking for the domain in question, but it had other nice things going for it.

But there was definitely a bit of a culture clash with the .NET guys. As an example, I did my domain thing in a pretty much self-contained library. While writing it I needed something that would be 'just data' without any additional 'functionality' attached to it, so I naturally reached for `struct`, given that it exists in the language. The .NET guys asked why it was not a `class` instead. See, somewhere deep inside they felt that not wrapping everything in a `class` is wrong on some fundamental level. Later, I had to touch the rest of the codebase a bit. At one point there was something I felt was a 'one-line change', that took 12 files to edit. Mostly routing calls through different auxiliary classes because 'architecture'. And you know, I'm really not trying to diss those guys. They were nice, capable, smart, productive, good people. It's just that I was very evidently from a different 'tribe'.

So, I personally like the direction that .NET is taking. I think that this release has very nice things in it. Such as the statically linked binaries, and compilation to webassembly. I also believe that modern .NET has a nice value proposition in being able to use your code across the board in many contexts and settings. On top of that, both C# and F# are nice languages.

But I won't be looking for .NET jobs, or putting that .NET stint on my resume, lest some recruiter gets the wrong ideas!

> While writing it I needed something that would be 'just data' without any additional 'functionality' attached to it, so I naturally reached for `struct`, given that it exists in the language. The .NET guys asked why it was not a `class` instead. See, somewhere deep inside they felt that not wrapping everything in a `class` is wrong on some fundamental level.

The difference between a class and a struct in C# is not the same as between a class and a struct in C++. In C#, structs can definitely be useful, but also have some gotchas, so they're mostly used only in performance-critical parts of the code.

If you visit a foreign tribe, I think you should listen to the locals, unless you are really certain your way of doing things is better in the local context.

Yes, of course, I applied 'when in Rome' a lot.

In this case though, the struct usage was completely in line with C# documentation regarding what structs are for. I wasn't trying to write C++ in C#. But hey, I do agree that code should be idiomatic to the particular community such that it doesn't feel out of place! In that case the struct did become a class.

Edit: Just re-read C# documentation on structs. Yes, it absolutely made sense to have a value type there. As in, the documentation mentions the use case almost verbatim.

The .NET people were likely right in your case. In C# structs are allocated on the stack, that's why you'd use them. Unless you have a specific reason you'd generally keep pure data objects as classes and not structs.

And there can certainly be a culture clash, there is a bit of a tendency towards more complex patterns in the .NET world. But you don't have to do that, and MS is quite explicitly adding versions with less boilerplate in this release, if you prefer that.

Just re-read C# documentation and remembered the situation more clearly.

Basically, I consciously researched the differences between class and struct in C# beforehand. And decided to use struct as the 'thing' was a kind of a coordinate that would be instantiated a lot for simple coordinate-space transformations, so it made sense for it to actually be a value type.

I should've been more assertive about it. Well, worst case some periodic imports are taking somewhat longer than they should.

C# 9 and 10 added records, which is better for pure data objects.

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

That's different, and in that case a struct is preferred.

Don't confuse inexperience with culture.

I'm from a mostly-.NET background I argue with typical .NET developers all the time.

I also argue with Java developers, and C++ developers, and...

Just to add some context. Another commenter mentioned gotchas that would make C# developers weary.

The fist that comes to mind is that with a class invariants of the type can be ensured in the constructor or by making the constructor private and exposing static factory methods. A struct, on the other hand, is always simply declared, so don't afford these protection measures. For some reason C# still supports constructors in structs though, and even uses the `new` keyword to invoke them. This creates a kind of trap where structs almost, but not quite, behaves like classes.

Another gotcha is the defensive copy semantics. When a method is invoked on a struct, and that struct is a readonly field, a copy of the struct is created for the method to avoid mutating the field. This is not at all how classes referenced by a readonly field behaves.

I guess the same can be said for the simpler case of just passing a struct as parameter to a method mutating its now local copy. Again different outcome for structs and classes.

Since the code look so similar (its just a different keyword at declaration site) it creates an uncanny valley tripping people up. Not least when refactoring between the two. After all, being a language with a GC means memory layout is seldom a primary concern for people.

However you can now declare structs readonly to avoid the defensive copy thing, or as a ref-struct to retain mutability, almost like a class. And as long as the default value is perfectly valid, like say (0,0) there shouldn't be much surprises anymore.

> But I won't be looking for .NET jobs

Have heard this sentiment in more than one comment in places like HN. "The {tech} is great, but the culture was ... so I'm not putting {tech} on my resume". And So it becomes a self-fulfilling prophecy :). Yet some tech seem immune to this. They don't say "X is great but the culture was crap, so I'm abandoning X", they say "X is great but the culture was crap so I'm changing jobs".

It really drives home that culture is critical, and even the worst tech can be tolerable if it is thought of as cool. Though of course the thought of abandoning ship to learn the latest and greatest solely to avoid legacy C++98/Spring/WebForms/whatever is naturally appealing.

I see your point.

But then, do you really believe one would be a smart person if they were to look for .NET jobs where at the same time Windows is not the dominant environment that people use at work?

>Windows is not the dominant environment that people use at work

Are you sure about that? Maybe Windows is not dominant when you look at startups.

Anyway, what .NET has to do with Windows now? You can happily use it on Linux or macOS.

>You can happily use it on Linux or macOS.

I would say that has only just become the case and still isn't for desktop development.

>At one point there was something I felt was a 'one-line change', that took 12 files to edit. Mostly routing calls through different auxiliary classes because 'architecture'.

I won't blame .NET for this. Needlessly complicated architectures are because OOP everywhere minded guys, Uncle Bob and GoF patterns. If you worked with a Java shop you cold have been hit by the same scenario.

.NET does push you down that route though, at least on the UI side. Using WPF feels like wading through treacle to me.

I believe colleges tend to circle around script or newer tools like Ruby, Rust, Python. A lot of development focuses on front-end tools like NodeJS/JavaScript/Typescript.

.NET/C#/F#/VB are old. 20 years for C# and VB. And they weren't friendly on non-Windows platforms until recently (last five years or so).

Microsoft procured the open source version of .NET (Mono) and decided to push the platform to a unified, cross-platform deployment. That started with .NET Core and has evolved to .NET 6.

So you're coming to .NET awareness exactly when it's at its most effective cross-platform capabilities.

And AWS and Azure both let you build C# functions/lambdas for serverless API's, so it has market appeal.

I'm building my startup, Mach9Poker, in C# and the debugging/unit testing are top notch. The language C# is easy enough. It's the libraries you have to really learn and there is a "way" to Microsoft things that's different. But there are also massive helpers in IO, list management (Linq is one of the greatest technologies ever created), generics, lambdas, and more.

For the same reason there's no "M" in FAANG. This industry has PTSD from the old Microsoft of the 1990s and 2000s, and isn't open to giving the new .NET a chance. It's a shame really, as the modern .NET stack / tooling / ecosystem is probably one of if not the best there is (at least for general purposes).

>my peers at university and in the industry tend to stay far away from .NET for personal projects, etc.

>Why is this?

It's a reminiscence from the times .NET was Windows only and MS was considered evil by the Linux guys.

Some older people haven't learned that times have changed.

And for young people is missing the coolness factor, it isn't promoted and made fashionable like the shiny new framework X for Javascript.

We recently got through upgrading a large code base from .NET framework to .NET core 3.1. It was quite challenging as it seemed to touch every corner of .NET including AppDomains, .NET remoting, serializing type information, C++ interop which requires environment variables to be set in process (that one is very obscure), etc, etc.

In any case, the performance results were really outstanding (particularly vs Mono) especially given we use C++ for many performance sensitive areas already. Looking forward to upgrading to .NET 6 in the coming months.

Great work! Congrats to the .NET team!

> In any case, the performance results were really outstanding (particularly vs Mono)

Interesting. Do you have measurement results? According to my measurements the difference is not that big, see https://www.quora.com/Is-the-Mono-CLR-really-slower-than-Cor..., especially the section Update September 15th.

Yes. Back to back runs were performed on identical hardware. The results varied depending on input but .net core universally outperformed mono 6.8 on Linux - in one case by 35%. This is quite encouraging since quite a bit of time (again depending on input) is spent in native code (where .NET is essentially idle).

Interesting, thanks. According to my measurements based on the Are-we-fast-yet suite the biggest difference is between Mono 5.2 and CoreCLR 5.0 on x64; about 28% speed-up from Mono to CoreCLR. The spread is smaller on x86 (about 18%). This speed-up is good but not the most impressive one I've ever seen.

Would you mind sharing how long the upgrade took, did it require a lot of changes?

I am wondering about jumping from relatively large codebase in .NET Core 3.1 to 6.

I would personally prefer you to fix the multitude of things that don't work well in Visual Studio and library issues that are continually pushed back as "won't fix" or "upgrade to .Net5/6" as opposed to always racing forwards to the horizon.

Even those of us who are actively migrating applications are stuck with web forms, netfx and dotnet core 2/3 and will be for years, so it would be nice that we felt some love rather than being left behind.

MS are starting to feel like Apple where you only have value if you can keep up.

Nobody gets promoted for fixing bugs.

> Even those of us who are actively migrating applications are stuck with web forms, netfx and dotnet core 2/3 and will be for years

Well, the job market is pretty hot right now so I hear.

It's not perfect but MS has been investing in a scheme to make upgrades as easy as possible for the last five years, .NET Standard being the prime example. This way, we've been able to migrate our project progressively while keeping it up to date. We've been able to use .NET Core versions of libraries as long as they support .NET Standard 2.0. This is way better than "migrate fully or die".

Why can’t you upgrade to the latest version? Sounds like tech debt. And Visual Studio is almost dead, why aren’t you on Visual Studio Code?

… huh? Visual Studio is extremely not dead, they are literally about to release a 64-bit version after a massive rework. VS Code is a text editor which you can extend into being an IDE. Visual Studio is an IDE.

There are many reasons why one might be unable to upgrade to the latest version of any given thing. For an example close to my heart of why one might be unable to upgrade to .NET 6 (or indeed to later versions of the .NET 5 SDK), there's the showstopping https://github.com/NuGet/Home/issues/10389.

>And Visual Studio is almost dead, why aren’t you on Visual Studio Code?

That's incredibly weird take in my opinion.

Whenever I use VS Code, then I feel huge gap between this and real VS with Roslynator extension.

I was surprised to see there wasn't much discussion of this Joel Spolsky classic here:

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! [...] the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up

Maybe Microsoft got out-fire-and-motioned by Node.js for a while but they're working extra hard cranking out new stuff.

Been thinking about switching to Rider (already had the personal license for Jetbrains from wanting CLion for Rust) and figured .NET 6 would be a good time to try making the switch. With how blah VS has been for a while hopefully I'll like the Rider experience better (for both c# and f#)

Edit: Though I saw something this morning when I tried to load an f# project I made in VS refused to load even though the new ones generated with Rider are fine...

Compare the generated project file between the two.

I noticed for a time that some projects created in rider had a different project type than those created in VS which caused some issues at my company. Was a simple change to the proj file though.

I've been using Rider for a couple of months now for Xamarin projects, as Visual Studio was for unknown reasons unbearable slow on my iMac - it totally destroyed my workflow and productivity.

Rider is not perfect, but in many ways miles above Visual Studio.

As Rider doesn't have any Forms editor build-in (AFAIK), I am slowly switching most of my views to fully code, so I don't need to rely on Visual Studio's visual layout editors anymore.

It does but only on Windows and for C# projects:

https://www.jetbrains.com/help/rider/Working_with_Windows_Fo...

I switched from VS to Rider a few years back - it's great, and I'm so glad I made the move!

Rider feels so much faster than VS, and is rock solid - these were my 2 main reasons for switching from VS.

I'd love to give Rider a try but I need SQL Projects. VSCode and DataStudio both have support for it now so I'm hoping they figure out how to bring it into Rider as well.

+1 for Rider. It’s one of the 2 .NET IDEs I know that don’t suck terribly (the other being the proprietary version of VSCode).

> proprietary version of VSCode

Do you mean Visual Studio? They don't share anything AFAIK

The binary VScode you install is different than an open source build. Microsoft doesn't want OS builds using the same package registery and I assume various tooling iirc

Very interesting. I wasn't aware of that.

I switched to Rider a few years ago. I really like it and I find its Vim emulation a lot lot better than what you can get for Visual Studio. Its F# support is ok, but I'd say VSCode+Ionide is better. But Rider isn't bad for F# still, and it has other tools it brings.

.NET seems to be getting better every year. Really interested to learn and use it for daily basis.

I just wished more startup are using it more as their tech stack to improve the ecosystem to be on par with Java. Almost every big tech companies are always using java now it's just hard to use .net when you won't get a job that doesn't suck

Java user here. What is a good book/set of resources on getting started in .NET/C#, possibly this version 6, without knowing the ecosystem beforehand (but with a experience in programming)? Thanks!

Learn .NET is a great place to start: https://dotnet.microsoft.com/learn

The official resources and documentation are pretty good.

https://docs.microsoft.com/en-us/aspnet/core/?view=aspnetcor...

I learned C#/.NET by jumping into an existing project, so I can't answer your question directly.

I can, however, recommend you use Rider as your IDE. It includes JetBrains' excellent ReSharper code analysis tool, which actually corrects a lot of your generic OO code and will automatically rewrite it for you to be more idiomatic (avoiding memory and performance issues, for example). Rider knows the sharp edges so you can mostly forget about them.

Otherwise it should be very easy for you to pick up. .NET has some annoying code organization conventions (lots of subprojects, too many folders, etc.) but you can just structure your project however makes sense for you and avoid all of that.

For high level, you can start at https://dotnet.microsoft.com/ which has links to learning resources for different topics.

There's also a 40 page e-book ".NET for Java developers" here: https://aka.ms/dotnet-forjavadevs

Thanks a lot for the suggestions!

Check `C# X Pocket Reference: Instant Help for C# X Programmers` by Joseph Albahari and Ben Albahari. I've used this book to refresh my knowledge about .NET and C#.

If you know Java it's easy to just jump in, and learn by doing.

If you feel like you really need a book, this one is good: https://www.packtpub.com/product/c-10-and-net-6-modern-cross...

I moved from C# to the NodeJs/JS/React world a while ago, when React was fairly new as well.

I like JS as a language and the enormous progress thats been made in the JS ecosystem from the wild west days back then. But I have to say my most productive and enjoyable dev experience was with VS, C#, ReSharper etc.

Magical intellisense and real refactoring across millions of LOCs and multiple assemblies, all kinds of tools, visual designers, powerful 3rd party toolkits (anyone remember Infragistics), amazing docs. And of course now it'd be much better I'm sure.

Best of all - no Gradle to deal with.

> .NET 6 is the first release that natively supports Apple Silicon (Arm64)

Finally! :)

I was a bit disappointed that MS didn’t want to support macOS arm64 natively with .NET 5.

At the same time Microsoft invested a lot of effort in porting Java to arm64. Almost a year ago I could download Java builds for macOS arm64 from Azul (java 8-latest).

MAUI was the big release I was looking forward to most with .NET 6, appears to be postponed.

> .NET MAUI will be released a little later than .NET 6

I wonder when, that could mean 2022

"We are now targeting early Q2 of 2022 for .NET MAUI GA."

https://devblogs.microsoft.com/dotnet/update-on-dotnet-maui/

No worries. There will be a shiny new successor to MAUI soon and MAUI will be all forgotten.

A lot of MAUI components are in .NET 6 they are just still marked Experimental/Preview to give everything more time to bake. If you want to start with MAUI in .NET 6 it sounds like it is as good a time to start as any. The impression given is that MAUI is retaining the Experiment/Preview designation in .NET 6 not because it isn't "ready" (though that can be argued both ways), but most specifically because .NET 6 is an LTS with three years of support and MAUI is still moving fast enough they aren't ready to commit it to LTS support.

I wish they put more effort into round 10 version of C# . Features presented will have minimal impact on productivity and maintainability.

Discriminated unions is one of those features that everyone talks about, but never gets championed. Wish C# 10 already had this feature. https://github.com/dotnet/csharplang/discussions/2962

Maybe try F#? I know it isn't always an option but if you can, especially recently, its been quite productive to work in.

you can actually do them pretty easily in C# without language support anyways.

for instance, the F# example from https://fsharpforfunandprofit.com/posts/designing-for-correc...

can be done in C# like https://gist.github.com/keithn/ceeeed5f7eb567e1b2333747065d1...

almost similar amount of code, however, no exhaustive checking. Not that I find that to be much of a problem, but it would be nice

But who needs sum types when you have the visitor pattern :troll_face:

https://blog.ploeh.dk/2018/06/25/visitor-as-a-sum-type/

wow.....that is one way to do it.....yes. I would hate to think what a system would look like with many sum types in it

I've been a huge proponent of file-scoped namespaces and it's in C# 10. I think it'll improve code readability and maintainability significantly despite being a seemingly minor change. It's also in line with "minimal API" and "top-level code" changes. I wrote about it here: https://ssg.dev/a-pledge-for-namespace-directives-in-c-15a32...

I love C#10 for a few features. The language is developing rapidly. And C# is already productive. I would like to see fewer features in each release.

Static interface members enabling generic math and other cool features slipped the C# 10 quality bar. That is why the release looks a bit thin.

But honestly, with file scoped namespaces and global usings ... there is enough to see.

C# is already evolving fast enough that quite a few devs are uncomfortable with it. Speaking strictly for myself, I love getting new language features faster - but there's a balance to strike here for the overall good of the ecosystem. You don't want to drive out all the people who can't keep up.

Is it possible to load ".NET Framework" assemblies into ".NET 6" applications?

(We have a lot of .NET Framework libraries, shared between different applications, and a complex dependency graph between them. So I'm wondering if it is possible to migrate away from .NET Framework by starting with the executables and working our way down the dependency graph.)

No, you can however have .NET Standard assemblies that can load into both .NET (Core) and .NET (old) applications.

Those use a common API subset, and are a stopgap to make migration easier.

Yes if you can migrate them to .netstandard2.0 you can run them on both .net framework and the newer core/.net5/6 releases. I've just done this exact migration path myself for a legacy application

Others have said no, but I think you can. The ".NET Framework compatibility mode"[0][1] was introduced in netcore2.0 (which actually is now quite a long ago, geez), which means that if your libraries don't use some windows-specific APIs/functionality, like WPF, there is a big chance that you can use them just as they are. I have never used my own .NET framework library like that but I think have used some 3rd party library targeting .NET framework in production.

[0]: https://docs.microsoft.com/en-us/dotnet/core/porting/third-p... [1]: https://docs.microsoft.com/en-us/dotnet/core/porting/#net-fr...

Yes you can, you simply add them as project references. We have done this in production and it works quite well.

You have to be careful though because you could get runtime crashes if they try to access stuff that is not supported in .NET 6 (mostly Windows-specific libraries).

I'd recommend running this guy on the code base, it'll give you a good idea of how much a pain it will be: https://docs.microsoft.com/en-us/dotnet/standard/analyzers/p...

I'm glad that Openssl 3 and more support for WASM was added. I doubt that anyone will use WASM though.

Why? WASM can be a huge productivity win.

well i hoped it would be easy to publish wasm modules that also works outside the browser. I'm not sure if that is possible tough.

I played around recently with Blazor (the WASM app model). It is awesome regards productivity. Just a bit heavy to load ;)

Fast framework for Web, MAUI for mobile and desktop, Blazor for frontend, ML.NET for AI and ML, Unity and Godot for games, F# for functional programming. All relatively fast and easy to use. Libraries for everything and good documentation.

The only thing we miss is system programming due to not being able to opt out of using the garbage colector.

You can get C# to run without the stdlib, and use it as a native language with some effort. Here's an example running Hello World as a C# EFI boot program: https://github.com/MichalStrehovsky/zerosharp/tree/master/ef...

this is nice.

I built a couple of side-projects and startups - all on .net.

First one was on Xamarin even before it was bought by MS - the progress from that times is amazing, the last one - built fully on Blazor.

I believe more startups should try to adopt .net stack - it's fast, fun and efficient and becomes better every day.

Congrats .net teams on launch

Is there a mature(!) webview library for .NET so I can build cross-platform GUIs with HTML/JS/React but write the backend in C#/F# and bundle that whole thing into a single file (not a zip/something that gets extracted on run) for every platform?

Hopefully with MAUI + BlazorWebview component:

https://devblogs.microsoft.com/dotnet/announcing-net-maui-pr...

Unless it gets rebranded again before it's usable.

WebView2: https://developer.microsoft.com/en-us/microsoft-edge/webview...

For instance, in WPF applications: https://docs.microsoft.com/en-us/microsoft-edge/webview2/get...

If it is cross-platform it doesn't seem to be very mature cross-platform: https://github.com/MicrosoftEdge/WebView2Feedback/issues/645.

Edge on Linux itself only just exited "beta" status a couple weeks back, so yes Linux support on WebView2 is behind other platforms and still playing catch up. Hopefully should be corrected "any day now". Appreciate the link to the tracking bug.

You may want to take a look at Chromely and its WebView2 offshoot EdgeSharp:

https://github.com/chromelyapps/Chromely https://github.com/webview2/EdgeSharp

.NET 6 was released but MAUI was pushed for next year and I still haven't heard anything about AOT which was delayed a few times and was supposed to come WITH .NET 6.

They promised Blazor AoT and its here, with. NET6. Maui is just a refresh of Xamarin Forms so that can wait.

I've been talking about native AoT.

Unlike all the preview builds this actually crashed on `dotnet run` after upgrading. Luckily a `dotnet clean` fixes it.

Good to finally have an official version!

Reply on news.ycombinator.com