Hacker News Reader

> If you're interested in writing C# and .Net code on a Linux machine. Then wait no further. VS Code (with .Net dev kit extension) works great.

I’d advise using Jet brains Rider for serious C# development (on both Linux and Windows). It’s a serious competitor to Visual Studio (and is vastly superior to VS Code)

Yup! Well worth the 20 bucks a month!

Why is that? I've used JetBrains IDEs in the past, but haven't found anything that compelled me to spend money on them (and lock myself to a proprietary editor, which is a bigger issue for me).

I work on a big monorepo. OmniSharp takes so long to load that it's basically useless, I gave up at 10min. Rider takes a minute or so.

With the new Dev Kit extension in VS Code, it no longer uses omnisharp. So it may gotten better in larger monorepos.

But my guess it's still faster in Rider

Dev Kit extension is also partially pay for play, as only a subset of its features are available under community license.

"C# Dev Kit builds on the same foundations as Visual Studio for some of its functionality, it uses the same license model as Visual Studio. This means it's free for individuals, as well as academia and open-source development, the same terms that apply to Visual Studio Community. For organizations, the C# Dev Kit is included with Visual Studio Professional and Enterprise subscriptions, as well as GitHub Codespaces."

It is, the irony of Microsoft not being willing to do the same as Java folks have available in IDE options, as in free beer, and commercial alternatives.

Instead it is either Electron or Java/Kotlin, in both cases commercial licences (new VSCode plugin has different licence levels).

They are only great for those of us that use Windows as our main desktop.

Microsoft's scenario for non-Windows is clearly driven by Azure and mobile platforms.

VSCode development experience is only done to be good enough to drive people into VS proper, as it has already been confirmed in a couple of podcast interviews, that there is no plan for feature parity.

So if one wants feature parity with VS outside Windows shelling out money for Rider is the only option.

Ironically Java still wins out in tooling, not only is InteliJ community free beer, there is Eclipse and Netbeans, while Red-Hat in collaboration with Microsoft, makes most of headless Eclipse run on VSCode, a much better experience than .NET on VSCode.

Even the Python experience on VSCode is better.

Additionally none of them have "pro" features gated by license, as in the .NET VSCode plugin.

It feels like while .NET team tries to turn the ecosystem around into FOSS, management ie still pretty much into VS/Windows/Azure, with some carrots for other scenarios.

> If you're interested in writing C# and .Net code on a Linux machine. Then wait no further. VS Code (with .Net dev kit extension) works great.

Unless you're writing Roslyn source generators. You can only debug them with (non-code) Visual Studio on Windows in my experience. Rider does not work well either.

You can probably attach to the compiler process with any debugger. Even just hitting F5 in VS didn't do the expected thing as it ended up debugging devenv.exe instead of VBCSCompiler.exe (the Roslyn analysis process). But if Rider (or VS Code) can attach to other processes, you should be able to debug your analyzers (and source generators).

My experience is that Rider works much much better (on Mac) for source generators than Visual Studio did on Windows. In particular it handles changes without reloading the solution far better than VS. I should probably add I have never used Rider on Windows, could be different there.

Blazor is such a disaster. Frameworks like Next/Remix/Svelte are running circles around it. I'd go so far as to say they should create their own TypeScript based SSR framework if they still want to be relevant in the non-enterprise web game.

I think that Razor + HTMX might be the better approach in that space.

I find the HTML fragments needed to be HTMX to be unmaintainable for large projects. The static typing for the fragments isn't there either when you're trying to compose fragment components.

> if they still want to be relevant in the non-enterprise web game

They don’t. Microsoft makes products for companies who will pay for software.

They're losing a lot of business to Next.js/Remix/Svelte. If MS had a viable competitor based on .Net then more businesses might keep their IIS and Windows Server licenses. The Windows path leads businesses to SQL Server as well. I've seen this play out first hand.

Sadly can confirm, I have been working as polyglot dev for years, also a reason why I have so many opinions, never siloing under a specific XVYZ Developer label.

Several CMS on the .NET ecosystem that relied on .NET for their plugins, when they went headless, decided to focus on supporting Next.js and friends for their UI component layer, removing Web Forms, MVC, Razor Pages support for these kind of workflows.

Others, like Sitecore, decided that it was too much code to rewrite from .NET Framework to .NET Core, and not only refocused on Next.js with Vercel agreements, they also pivoted for an API first approach, and acquired non-.NET based products as means to evolve their product roadmap away from .NET.

Myself, I have been involved in a couple of .NET Framework to Java migration projects, as given some of the stuff the customers would need to write from scratch in modern .NET, they decided it was the right time to move away from Microsoft stack on the server infrastructure.

It should be noted that it isn't an accident that Microsoft, after all these years, has acquired jClarity and is now an OpenJDK contributor.

Who have thought to see this kind of stuff a few years ago?

https://devblogs.microsoft.com/java/

https://www.theregister.com/2024/01/31/microsoft_seeks_rust_...

Microsoft fucked themselves hard having basically no upgrade path from legacy ASP.Net Framework to what there is now.

It basically dead ended the large million line app that ran the company I worked for and forced a costly rewrite away from Microsoft. Though many parts of it still exist today, still on 4.8.

For a company, Microsoft, that prizes backward compatibility and typically provides good upgrade paths, I felt very betrayed having trusted them as our platform.

The upgrade path to ASP.NET Core itself is the most straightforward out of everything that existed during .NET Framework days, a lot of code requires little to no changes and the code that requires a lot usually was questionably written in the first place or relies on problematic APIs.

What are you talking about? ASP .Net Framework versus Core is completely different. Not just rewritten the API is totally changed as well. Many libraries were completely removed - WebForms, OData 3, the entire bundling infrastructure, etc.. How requests are handled, and how you pre/post process requests is completely changed as well.

Their documentation even says, "Updating an app from ASP.NET Framework to ASP.NET Core is non-trivial for the majority of production apps" Even that is an understatement. https://learn.microsoft.com/en-us/aspnet/core/migration/inc/...

It was not trivial but the subjective experience matters a lot. In migrations that I participated in the most difficult parts were not related to ASP.NET but to third-party libraries. Another pain point at the time was moving off WCF which ended up being packaged up on some legacy Windows host as a separate microservice for just that purpose to not hold everything else back but that's it.

Swapping out the startup and hosting models was not a challenge because the APIs were comparable, some controller classes had no lines changed either, and moving off IIS pool arguably is all around improvement (and far easier, to manage with docker and deployment manifests).

I don't know what disaster you're talking about. Blazor server is a complete .NET vision of "html over the wire" - it has some major downsides and is only appropriate in particular scenarios, but in those scenarios it shines. Effortless "push to the frontend", and not having to write an API for your frontend, those things are worth a lot.