[Guid_NewGuid]

The bad:

- Web framework is not quite on-par with Django/Rails. Particularly with auth/OIDC.

- Job market is very sector dependent. Startups just don't seem to use C# whereas big enterprises do.

- Some design decisions in the early days seem to prevent some features being added, e.g. structural typing or union types (not certain this is the reason).

- Some days, like yesterday, your IDE updates and gets messed up and then it's back to writing full variable names like a medieval monk.

- .NET is not really viable for non-server work. There is embedded/desktop stuff but you're going to have a headache outside of servers.

The good:

- When it's working properly the developer experience is like those dreams where you're flying. Rider or VS + Resharper make typing anything seems an incredibly antiquated way of developing. Intellisense means you barely ever need to type more than 2 characters to express your intent. Unlike my experience in Go or Python I just think about intent/data shapes and the tools fill in the rest. No language I've ever worked in comes close to reducing the ideas -> implementation effort barrier.

- Type system. This is non-negotiable for me, plenty of syntactic sugar to make overhead of typing lower but because it's compulsory, types save so much mental effort and our production systems never wake us up, feeds into the above. You don't just have to reimplement a compiler badly through unit testing saving a lot of time.

- Tooling, full framework used to be hell and very tied to the (paid) tools. Now with Core the tooling is great and Linux support is fantastic.

Overall I don't want to work in any other language if I can stick to C# but the fact startups don't use it mean I might have to enter scripting language hell, again.

[bobkazamakis]

>- Web framework is not quite on-par with Django/Rails. Particularly with auth/OIDC.

Completely wrong. Not only does Auth work particularly well out of the box, but microsoft documentation is top tier with both c# and asp net core.

https://docs.microsoft.com/en-us/aspnet/core/security/authen...

asp net core is the single best framework for backend web at this time, but yes, won't be as fast to ship as django/rails. If you like to maintain code, I'd consider it a worthy tradeoff.

[Guid_NewGuid]

Ah, fair criticism, thanks for educating me. To be honest I'm repeating barely-remembered experience from years ago now, time flies. I just always found documentation pushing to Azure AD, or the now paid IdentityServer stuff, when it comes to SSO.

The other thing that works against me in having a Django-like experience with web is I always switch away from EntityFramework as early as possible in favour of handwritten SQl. I think a fair comparison probably puts EF level with or ahead of Django.

But this auth documentation looks interesting and definitely an improvement.

[melony]

Their offical "SPA API Auth" involves paying for a third party OAuth server (called Duende IdentityServer, the ASP.NET Core built-in auth solution on the other hand is called ASP.NET Core Identity) and Microsoft refused to ship their own server because that would be "competing with the open source community" (there are multiple long Github threads on this which Microsoft product people would lock and mute). I wonder which PM got kickbacks for that decision. Originally Duende IdentityServer was free under Apache, and then they immediately turned into a paid solution after they became the "official" solution for API Auth. Microsoft also claims that standard cookie auth cannot be used for API Auth in a SPA scenario (their security engineers insist that you use JWTs), if you look through their Github issue threads, the ASP.NET Core engineers seem to believe that the default ASP.NET Core Identity generic cookie auth is for MVC only and it is "not recommended" for use with SPAs.

https://docs.microsoft.com/en-us/aspnet/core/security/authen...

https://duendesoftware.com/products/identityserver

They like to hide their dirty laundry behind clever developer advocacy teams and drowning it in Github bureaucracy but here are some examples:

https://github.com/dotnet/AspNetCore.Docs/issues/25832

https://github.com/dotnet/AspNetCore.Docs/issues/7644#issuec...

https://github.com/dotnet/AspNetCore.Docs/issues/24157

https://github.com/dotnet/AspNetCore.Docs/issues/18524

Their PMs are not building an open source product in good faith. As far as they are concerned, ASP.NET Core primarily exists as a funnel to send customers into Azure or buy stuff from Microsoft partner companies. Imagine if Vercel one day removes the standalone server hosting option and requires you to pay for their serverless cloud to use important features. This is what Microsoft is doing here right now with ASP.NET Core. If you lock your stack into their ecosystem, then be prepared to spend money either on redundant cloud subscriptions or developers reinventing the wheel on core features

[WorldMaker]

It's not Microsoft's fault that Duende took their ball and went home, becoming a closed source operation after years of open source work. That's on Duende for being bad Open Source community members.

I somewhat sympathize that Duende's unpaid support costs went up once Microsoft pointed a lot of heat their way by including it in official samples, and they should get paid for support. I also somewhat sympathize that closing their source was seen as the easiest option to redirect the community to paid support plans.

But it's still a jerk move in the Open Source community to have code be open source for more than a decade and then close it simply because it was used in one tutorial/sample too many.

Sure, Microsoft could have offered sponsorships or other help, had Duende asked. Supposedly Duende didn't ask, their first public response was when they immediately went closed sourced because apparently they never really cared about Open Source.

There are people not building an open source product in good faith in this story, but it doesn't seem to be Microsoft (surprisingly).

Microsoft probably should replace IdentityServer with something that actually wants to be good Open Source in the samples again. They are between a rock and a hard place because if they fork the last Apache versions of IdentityServer they look like the bad guy for "stealing" Duende's work at that point, and they can't resurrect their old code because it was bad. They probably have to wait for some third party fed up enough with paying Duende for bad faith Open Source to make their own fork.

[melony]

They don't have to fork anything, they can just add a built-in OAuth to ASP.NET Core Identity. They did that with JSON and created an in-house alternative to Newtonsoft's fast JSON library once it became popular enough. I didn't hear any PMs whining about "competing with the open source community" then.

[WorldMaker]

OAuth is too (stupidly) complicated for "just add a built-in OAuth to ASP.NET Core Identity". They had that in previous samples (which you can still find online if you look) and it was bad code that suffered from code rot and stopped being "OAuth compliant" especially with respect to even more (stupidly) complicated OIDC, so they looked for someone to maintain that and IdentityServer already existed and was OAuth compliant/audited. That's why it needs to be forked. Someone has to do the OAuth/OIDC hard work. Microsoft is paid to do that in other divisions of the company, of course, but it's all in Azure and they want you to pay for Azure AD alphabet soup that pays the bills for their OAuth/OIDC compatibility auditing.

> They did that with JSON and created an in-house alternative to Newtonsoft's fast JSON library once it became popular enough. I didn't hear any PMs whining about "competing with the open source community" then.

James Newton-King, the "Newton of Newtonsoft", was one of the developers involved in that project that decided a clean compatibility break with JSON.NET (which has been showing its age, but also has far too many users to easily break API compatibility) was necessary to achieve the performance goals that System.Text.Json was created to meet. That's not so much competition as it is cooperation.

[bpicolo]

Cookies work great for SPAs and I highly recommend the path for first party auth. Setting up CSRF tokens on the frontend is a lot easier than setting up OIDC.

[melony]

That's correct. And if you have configured SameSite corrrectly and your GET request handlers are locked down, you don't event need CSRF tokens. Unfortunately Microsoft ASP.NET Core security engineers' careers seem to depend on have differing opinions on how to secure SPAs and APIs.

[uticus]

> Intellisense means you barely ever need to type more than 2 characters to express your intent.

Agreed Intellisense is pretty good. Not excellent - it never suggests using statements as a first option, and in unit tests I have to always type "Asser" to bring up "Assert" (using 2022 expensive version). But it pretty good.

From a tooling perspective, this a positive. From a language perspective, well there are other languages that allow flow-of-thought without needing the tooling to autofill [0]. There are tradeoffs, and practically speaking you'll need to eventually look at someone else's flow of thought and expect them to understand yours.

[0] https://www.wisdomandwonder.com/article/10231/if-you-like-li... "...by and large, I find that the language allows me to express myself, in the language, about the things I’m dealing with. I find that a very precious property of a programming language."

[cweagans]

> - .NET is not really viable for non-server work. There is embedded/desktop stuff but you're going to have a headache outside of servers.

As an outsider to this ecosystem, desktop development is one of the things that has me interested in C# at all (built in windows stuff + Avalonia + Xamarin and the like).

Can you elaborate this?

[Guid_NewGuid]

So I think the current/new desktop approach is MAUI, maybe, it's hard to keep track. When evaluating Microsoft/.NET stuff I think the safest approach is to ignore anything they come out with and check back in 4 years to see if it still exists. Desktop is the worst for this.

Winforms and WPF are still solid choices if you need a Windows only UI and I think Avalonia is still going and might be good, I haven't really had an opportunity to evaluate it. But I think desktop still lacks a compelling cross-platform solution post-WPF and adopting early solutions from Microsoft will cause you many headaches and much sadness.

[WorldMaker]

MAUI is the continuation/rebrand of Xamarin, most especially Xamarin Forms (as some of what used to be Xamarin is now just baked into .NET at lower levels). It's still more cross-platform mobile focused (iOS and Android seem to be the best tested platforms), though with support for full WinUI 3 and macOS Catalyst the lines are blurrier than ever between mobile and desktop development, especially if you are trying to write a cross-platform app. The biggest missing link for cross-platform desktop development in MAUI is Linux. (There's at least one open source fork working on a GtkSharp implementation/backend for Linux, but I don't know the ETA on that shipping.)

[ocdtrekkie]

IMHO, you only know a .NET platform is there to stay when they finally get around to adding VB support to it. WinForms? Solid. WPF? Here forever. UWP? Never going to go away.

.NET MAUI? Who the heck knows, it's still C# only.

[WorldMaker]

MAUI on Windows desktop is just a cross-platform wrapper around WinUI 3 (UWP's UI replacement) on top of WPF. Worst case, if you are building Windows Desktop apps, you eject back to WPF. [0] For the rest of the platforms you could switch to Avalonia or Uno perhaps.

[0] Though of course the question then is that if you are building WinUI 3 apps and don't need cross-platform why you don't just use WPF directly, and I don't have a good answer there. I think MAUI might be slightly more appealing if there was a stronger bridge from "start with a WPF app then expand it to MAUI". (You can do it, in some ways it is straightforward, but it's not an official garden path.)

(ETA: Though I get you on the VB.NET as gate idea. It's a big reason I still don't entirely trust Razor much less all the hype around Blazor. Blazor more than anything feels way too much "for people that missed Silverlight, here's a worse ASP.NET Core Silverlight" with shades of ASP Classic runat="server" full circle)

[ocdtrekkie]

The entire cross-platform path is extremely rocky. Let me give you an example:

My home automation system runs as a .NET Framework WinForms app written in VB. I'm interested in moving it into two directions: I would rather run it as a service, and I would like to be able to run it on Linux. VB .NET works on .NET Core in Linux environments, without a UI framework like MAUI, this should be trivial to accomplish both... right? RIGHT?

Visual Studio happily provides a .NET Framework template for building a Windows Service (for C# or VB), which my app could work under pretty easily. Or there's a Worker Service template which is cross-platform .NET Core (for C# or F# only... for no technical reason whatsoever, Microsoft just didn't want to bother)

The Windows Service template provides basically the scaffolding entry points for every way you interact with a Windows Service, you can pretty much just paste the code in for what happens when the service starts and stops. This is straightforward and easy and you can tell was designed by the same sort of people who came up with the WinForms editor: It's simple, it's obvious, and anyone can do it. I wrote my first practical Windows service one day, and it was done that day.

There's instructions for turning a Worker Service into a Windows Service here: https://docs.microsoft.com/en-us/dotnet/core/extensions/wind... I think it's safe to say, this is not simple or straightforward in any way (especially since "Rewrite the entire worker class" is a step here...

And that gets you back to... a Windows-only service? What the actual heck?

So here's what I am mind-boggled hasn't happened here: Microsoft should have a cross-platform service template (in all supported languages, please and thank you), and it should give you entry points for starting and stopping the service and such which are all pretty much the same between operating systems, and then it should handle the scaffolding to translate it to the appropriate OS out of the box.

[aliswe]

This is poetry! Spot on.