Hacker News new | past | comments | ask | show | jobs | submit login
.NET 6 Released (microsoft.com)
502 points by tonicbbleking 77 days ago | hide | past | favorite | 416 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.


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.

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

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

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

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 believe it was introduced around .NET Core 5? or 3? so at least 1 year ago

Since .net core 3.0

After almost 18 years, Joel finally got his wish:


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.

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.

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.

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

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

The whole runtime gets included in the binary.

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

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?

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?


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


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

You create one binary per OS.

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

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

In my case about 60MB

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.

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

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.

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.

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.

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?

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

yes but then you have to write your program in java

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

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.

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

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

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

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.

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

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?

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

Three years doesn't seem very "long".

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.

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

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

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.



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.

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

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.

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

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.

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.

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

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.

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

>"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:


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.


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

> 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

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

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

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.

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

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

WPF compiling to WebAssembly would be ideal.

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

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.

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




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

For "regrettable" substitute "tire fire"

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.

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.

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.

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


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?

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

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.

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?

> 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

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

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.

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

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.

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.

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.

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

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.

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!

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

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.

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.

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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact