Ask HN: Current state of coding .NET code on non-Windows machines? | Hacker News Reader

Ask HN: Current state of coding .NET code on non-Windows machines?

80 pointsuticus79 comments

Does anyone have a good idea of how much .NET development is happening on non-Windows machines (or in non-Windows dev environments)?

I'm talking about the environment where code is written and debugged - not the environment where it is published or ultimately ran.

For example, I could imagine .NET back-end code being developed on Macs or Linux then deployed to AWS.

I enjoy the .NET language, but I much prefer a Linux dev environment over a Windows one (Ruby and occasionally others languages uses in the Linux dev environment). The release of Visual Studio 2022 for Mac has made me wonder how much demand there is for writing .NET code in a non-Windows environment. I also realize there are other alternatives, like JetBrains or VS Code.

View on HN

I do all my hobbyist development in .NET 5 on a M1 Mac using Visual Studio 2019 for Mac (now VS 2022) and then deploy to x86 Linux boxes on OVH.

I used to use the .NET runtime on Linux but now I just use a Make file to publish to self-contained Linux binaries and rsync them to the Linux boxes in prod.

I'm really enjoying it. Honestly the only (and biggest) problem right now is with TLS 1.3. .NET on Mac doesn't support TLS 1.3, even for their client Http classes like WebClient, because of some silly ways SslStream is implemented under the covers on macOS. There is more details in this issue: https://github.com/dotnet/runtime/issues/1979

I only used it for few months as a beginner, so take this as you will.

VSCode works, but JetBrains Rider is probably your best bet. It just works and works really well compared to hodgepodge of extensions in vscode. Beyond these 2, you're pretty much on your own, and things never Just Work.

But, beyond the editor, the ecosystem is not Linux-friendly. A lot of libraries expect and assume you are on Windows and just refuse to work for whatever reason. There are near-zero relevant resources (blog posts, stack-overflow Q/As, forums) for developers on Linux. (I guess this is how Emacs users on Windows feel).

The second paragraph is why I stopped. The .NET core itself is decent, and if you manage to limit use within you should be mostly fine, probably. But the experience never feels home and it is a constant reminder of being second-class that's not my personal favourite way of spending life.

> A lot of libraries expect and assume you are on Windows

I'm curious about this. Can you give an example of a library that refused to work? I'm having trouble imagining what would cause something to break on Linux - but not on Windows - in a typical .NET library or NuGet package.

MS deprecated Linux support for System.Drawing in .net 6.0 and will remove it in 7.0. https://docs.microsoft.com/en-us/dotnet/core/compatibility/c...

System.Drawing never worked well on linux, and is mostly used in windows-only gui.

To generate/process images, there are other, great, .NET library like SkiaSharp, or ImageSharp.

So are these mostly documentation/outreach issues, then?

The documentation of System.Drawing point to these projects:

> If you can't use System.Drawing with your application, recommended alternatives include ImageSharp, SkiaSharp, Windows Imaging Components, and Microsoft.Maui.Graphics

Sadly .NET devs will jump on any first party software and won't look a lot in community alternatives.

I think there is still a lot of benefit in a first-party library which provides shared abstractions like `Color` and `Bitmap`, even without any fancy manipulation capabilities.

I came across this with System.Drawing on Ubuntu and successfully managed to replace it with SkiaSharp code instead. It was drawing a map for a game in memory then saving to a .jpg file.

I use VS 2022 Community on Windows, tested it there then published to Linux and uploaded over SSH to a VPS. It worked very nicely.

Everything I write in .NET eventually makes it to a Linux container, I'm not quite writing code in the same environment, but the only difference I've encountered so far is how DateTime works with UTC.

> how DateTime works with UTC

What do you mean by that? I know that the timezone definitions in txdb are not the same as the ones MS uses on Windows, but it doesn't sound like you're talking about that.

Something about how Linux and Windows using different local times, Linux uses the hardware clock in UTC and then converts, Windows sets the hardware clock to "Local" time adjusted for daylight savings time (https://www.codeproject.com/Questions/533978/C-23plusWINDOWS...)

It's complicated.

There are a lot of things you'll miss coming from "real" Visual Studio.

VS Code is really a very good lightweight editor, but it's not trying to be an IDE.

Visual Studio 2022 for Mac is.. fine. It's a poor choice of name given that it sounds like a Mac port of Visual Studio, which it's not (it's MonoDevelop rebranded and updated with other features, but is still really far from VS on Windows).

I use JetBrains Rider quite a bit and I really quite like it, but even then, it's not close to matching Visual Studio + Resharper.

The features that you only really get to know on large projects or specific use cases are the ones that you'll miss the most in my experience, as it tends to be the blind spot for lighter environments.

IntelliTrace is a big one. There's nothing like it on any other .NET IDE that I can think of. Also the deep AppInsights integration has always been fairly incredible in VS and while VS Code has started to adopt some of this, it's still far from what's in VS.

The last thing I really miss is Snapshot Debugging. Having an exception being reported to you from live, being able to then click the exception on Azure and immediately pop a VS window with the debugger on the line that failed with a fully rewindable call stack as if it were running locally is magical for turning around bugs - most of the time you don't even need to try to trace the cause or recreate the circumstances at all.

It’s quite the opposite from my experience.

Rider got a lot better over the years and I would pick it over Visual Studio anytime.

I just finished working on a .NET backend for a year and a half on mac w/ vscode, I found the experience to work pretty well. I did however choose to run a cloud windows VM to work with .NET Framework 4.7 libraries that needed to be integrated into the project, but after a few months worth of work I was back 100% on mac.

Unfortunately, if you have to reach back further than .net core or standard then you'll need to work in a windows environment – Cloud VMs are pretty cool and cheap if you don't want to use your hardware for a partition.

Understood. The .NET Framework stuff will be kicking around for a while yet, but newer stuff (especially backend work) is undoubtedly moving towards .NET 6 (or whatever LTS is desired).

I'm curious if you had team members with similar setups, and how well the team worked together with that setup?

Most team members had Windows machines as their main workstation with Visual Studio, so it was no problem with them as long as they had all the runtimes and toolchains installed.

I'm using Rider on Ubuntu and it's perfectly fine as long as you are developing web-related stuff (WebAPIs, Blazor, MVC). Rider is much better IDE than Visual Studio, also dotnet is really terminal-friendly these days.

A year ago I needed to quickly do something related to Xamarin and as far as I remember I actually had to move to Windows for some reason, but that was the only time. I'm not even sure if it was related to inability to run stuff or it was just too much tinkering to launch that single thing.

Do you have one or two points why you like Rider more than VS? Honest curiosity. I never used Rider but i really like VS compared to other code editors (for other languages). To me it's the perfect match for anything .NET/C#.

1. Rider provides really good linting and static code analysis out-of-the box. I've once opened my project that I've been developing in Visual Studio and it gave my a sh*load of actually useful hints on how to improve my code. 2. Typing is also much faster, once you get used to snippets your code just writes itself :) 3. Lots of built in tools, I just didn't even need to install any database management tool as the one built in in Rider is enough for my needs 4. I tend to use mouse in Visual Studio more. Don't know the exact reason, maybe it's because Rider gives a really powerful shortcuts like "Shift+Shift" and "alt+Enter" that are easy to remember and does most of the job.

But it may also be, that it's just because it works on Linux. I develop mostly for Linux servers and use Linux tools that obviously integrate better with Linux-based OS than on Windows. There is WSL, but still, experience is not that fluent.

Rider is for one significantly faster, it also has better solution analysis and refactorings due to it integrating all the resharper ones.

Work on ASP.net core servers on Mac(Arm/M1) + Linux

.Net itself:

Everything builds and runs no problem, on linux I occasionally have to self install the latest SDK but that's a well known problem with many languages/platforms.

This is with the preface that I work on web servers, desktop right now is a no go with things like System.Drawing, printing etc. not being cross platform.

Tooling:

VS code is in a superposition of being an excellent free editor and a complete joke, it works but it's a long way from a great experience. Funnily enough this is a spot where F# support is better than C#.

Rider on the other hand has a great, near identical experience across all 3 systems.

Other notes:

I'm on Azure so I can't comment on the state of AWS SDK's (I would not be remotely surprised if they were better) and I find the emulator support lacking in general and especially on an M1 mac. This is an Azure problem rather than .Net but one i felt worth mentioning for other .Net developers.

To answer the start of your question: I think the bulk of .Net development going on is still on windows but that's definitely changing.

I did a little development on Ubuntu back before Rider existed and switched back to Windows because I prefer it but now with Rider I think for any .NET Core shop the development platform is more or less irrelevant.

Almost everyone in our team uses Rider (except me and a couple of other holdouts) and the general consensus seems to be that it is far superior to VS. We completed a long migration over to Core and now we have developers on Mac (not sure on Linux) and we don't have a hard requirement on OS.

As for general numbers/market I think it's still relatively niche as any glance at a more start-up focused jobs board indicates (though not niche overall, just tends to be enterprises where dark matter developers are employed).

I hope one day people will realise what a fantastic ecosystem is available but for now they'll be bashing out messes in write-only languages and desperately carrying out microservices migrations to try and escape the pain when the project goes above 100LOC /s

I have coded on .NET in Windows/Mac/Linux. It works equally well in all environments. You can use VSCode, VS for Mac, or Rider. I use Rider in all platforms. It's an awesome IDE.

Source: I work at MS but have used .NET on other platforms at previous jobs.

Half my team is using mac and the rest of us are begging for mac laptop refreshes to do our ASP api work, if that tells you anything. I consider the experience with rider on a mac to be far superior to windows based development.

The vast majority of places that use .NET core (or .NET 5.0/6.0) are places that used to use old .NET and use Windows for their dev environments.

You would be really limiting yourself if you look for a .NET job without Windows. I am sure they exist but it's probably something like 95%/5% windows/not windows.

I am not really sure why you would want to use Linux/MacOS for this though. The dev experience for .NET is very consistent between platforms if you don't use Visual Studio.

Using VSCode, Rider, and the dotnet CLI, I have developed on MacOS, Windows, and Linux without noticing many differences.

Agreed. I am a front-end developer on a Mac. I am learning the .NET backend code on a Mac. All of the 12 backend devs on this project are on Windows. When I tried to screen-share and get help (using VS for Mac), they are all like "WTF is that?". VS for Mac is not like the Windows VS. I also had to run MS SQL Management Studio, and it only runs on Windows.

So I ended up running a Windows machine on Parallels on my Mac. Now I have a consistent work environment as the other backend devs, but it's not a good developer experience. Sometimes it's extremely slow. The context switching from a Mac to Windows is distracting. I feel very disconnected from the code I'm working on. I'm going to try JetBrains Rider based on suggestions here.

It makes me reconsider if I really want to go down the .NET path in my career if I probably have to use Windows (with about 95% .NET job opportunities using Windows). Java looks like a better option for fullstack web development on a Mac.

>I also had to run MS SQL Management Studio, and it only runs on Windows.

Azure Data Studio is cross-platform and the obvious successor judging by comparative release speed and that every SSMS install automatically installs ADS. It's also more annoying than SSMS, but ADS is still a better experience than most SQL gui tools.

I work at a startup using .NET Core and deploying to AWS.

It's a mix between Windows, MacOS, and Linux. When you join they ask if you have a preference between a Windows laptop or a MacBook.

The people on MacOS and Linux use either VSCode or Rider I believe.

Everything seems to run fine. It's kind of amazing to see, considering where .NET started.

Depends on where you're looking to work. If you're looking for startups there isn't a huge number of .NET startups. (I work for one) But the ones there are are usually ok with someone working on a Linux dev environment.

If you're looking for an enterprise job most non-tech enterprise companies still require development on a Windows machine because they require everyone to use a Windows machine.

I would argue there's a huge number of .NET startups that aren't being talked about because it's still not considered "sexy", super compact, or other stuff like that — even though lots of new hotness is being added all the time.

Yeah .NET never shows up high on the wish list, but surely it's because .NET has been historically tied to Windows.

I'm wondering if it still is in fact tied to Windows - because even though developers can use .NET without Windows, they are not for whatever reason. Don't know if this is true or not, but it is what I'm asking here.

I develop cloud stuff in .NET that runs in a Docker container, and I'm using Windows - it's not that anything ties me to the platform, but having tried Linux and Mac, on all environments I'd be running minikube with a VM. It's just that Windows isn't worse at this kind of stuff that other OSes are.

I've developed on all 3 major OSes, and all of them have some kind of drawback (though I have to admit, since M1, Apple hardware is miles ahead of the competition).

"Is it still tied to Windows/what kind of edge-pain can I expect on my Fedora machine?"

"Microsoft people said EEE, using Microsoft- led projects is nonstarter."

"Are you going to pay me the time to relearn x,y,z in dotnetland?"

I think a lot of the reason .NET isn't yet used that broadly beyond Windows is as much leftover distrust/paranoia at Microsoft than anything technical.

I tried to get involved in Mono-based Open Source back in the day and it left a lot of lasting sourness at the "Linux community" and how distrustful/paranoid it could be. Despite Mono being open source. Despite however many open patent agreements Microsoft signed. There was so much ugliness and so many people I encountered had a lot of passion for "Never .NET".

I hope that changes for the community. .NET doesn't get any more Open Source today. There's no longer a .NET/Mono split, they've merged. The open patent agreements with the .NET Foundation and other stewardship orgs are about as rock solid as they can possibly get.

I cynically saw so much "Never .NET" hate in that community that I can't imagine it won't linger for long past its expiration date.

I'm not sure if I agree. If a startup itself was "sexy", it would show up in discussions regardless of what tech stack it was using.

That they don't show up is more indicative that there aren't that many in the first place IMHO.

Speaking as a former .NET developer, something that impedes searching for a .NET job that isn't at a huge, crufty, old school enterprise company is that the vast majority of .NET jobs are at such companies. So you have to sift through all of those to find something that doesn't fit that mold.

> If a startup itself was "sexy", it would show up in discussions regardless of what tech stack it was using

Yeah, but you wouldn't necessarily notice that they're using .Net.

I have found JetBrain's Rider IDE[0] to be sufficient for development on Linux. It is not as heavy weight as Visual Studio but does bridge the gap of convenience that VS provides.

[0] https://www.jetbrains.com/rider/

I also feel like VS is getting worse. I run into far more errors and issues now than I did several years ago. My theory is the success of Azure and the end of the era of "Developers developers developers" has caused Microsoft to place less of their best engineers on the tooling team.

I don't know -what impressed me about VS 2022, is just how amazingly fast the new UI is - everything is instant now, it's by far the greatest speedup I experienced in a new VS release. Probably it helps that they moved to .NET Core from Framework, and to 64-bit as well.

Okay, I keep seeing people say this, and I have had the complete opposite experience. VS 2022 brings my somewhat beefy work laptop to an absolute crawl sometimes. I can open VS 2017, load a solution, and close VS 2017 all before I can even get to the solution selection screen for VS 2022.

Often a big difference is plugins: check and triple check what plugins you have installed.

There's a couple extremely common plugins "everyone loves" that just murder VS performance and everyone blames VS and not the plugins.

+1 on this. Previously worked in the developer tools division that builds VS, and whenever someone got assigned to work on a performance or crash bug you'd almost always wind up hearing them mutter "it's f*cking ReSharper again". The VS team has had a huge push in the last few years to improve code analysis, introspection, and refactoring (with Roslyn) specifically to try to replace / kill ReSharper. The company has no animus with JetBrains, and the team has nothing but respect for the value it's added to the ecosystem, but it's by far the biggest source of perf and crash issues in VS.

I know people feel like they just can't possibly live without it, but the refactoring tools in VS nowadays are much better, so I encourage folks to test drive by going a couple weeks without installing ReSharper. If you still really miss it and are willing to pay the performance penalty to have it after that, go for it. But give VS a fair shake without it.

Resharper is kind of a dog in terms of performance, and I think it's a major source of performance issues under VS - especially with large project.

One of the reasons for this is you can't turn off the Roslyn-based MS engine in VS (which IMO is reasonable, since it's needed for a lot of stuff) so there are always 2 code analysis engines running.

That's one of the main selling points of Rider Imo, that it doesn't run 2 completion engines simultaneously, which makes it much faster.

Unfortunately Resharper is still far superior to VS with the quality and quantity of built-in refactorings.

Another thing with Resharper is that it seems to run synchronously, meaning if you type something and press the completion button, the suggestions always pop-up. A major pain point in previous VS versions is that this wasn't the case with the built-in engine.

Sometimes you just pressed the autocomplete button and nothing happened, because VS was still parsing your code.

Thankfully 2022 fixed this, and this is one of the reason I would never consider going back to the older versions.

> One of the reasons for this is you can't turn off the Roslyn-based MS engine in VS (which IMO is reasonable, since it's needed for a lot of stuff) so there are always 2 code analysis engines running.

Roslyn is extremely well tuned. (Anecdotally in any IDE including VS Code without ReSharper it's performance is incredible and hardly noticeable.) ReSharper's performance problems are ReSharper's performance problems.

Blaming ReSharper's performance on Roslyn is just as wrong as blaming ReSharper's performance on Visual Studio. It's pointing the finger at the wrong thing in the stack.

Of course that's a big selling point for Rider. It's incredibly wonderful marketing luck that almost all of ReSharper's performance problems get blamed on Visual Studio itself or on Roslyn and almost never directly on ReSharper. As long as people keep pointing the fingers away from the plugin, JetBrains gets just about free marketing from every VS performance complaint real or imagined. Their incentives aren't aligned to improve ReSharper performance when "everyone" just answers "Just switch to Rider already" because they mistakenly blame Visual Studio rather than the ReSharper's own engineering.

VsVim is the only plugin I have, and perhaps it's slowing things down that badly, but that would be surprising to me.

VS 2022 is still based on .NET Framework. It’s faster because a lot of talented folks worked very hard to improve it :)

Counterpoint: I've been extensively using VS 2019 for years and VS 2022 for a few months. Neither has been notably buggy other than the occasional glitch with Live Unit Testing.

For further comparison, I've also used JetBrains products a lot over the past few months. They are also solid and work great.

I don't feel that VS is necessarily getting worse (it's always had weird errors and issues; some people just have nostalgia goggles for certain older versions), but relatedly I feel that VS Code is getting too good. So many new features seem designed for VS Code first and VS integration is an afterthought. An increasing amount of the time I find I want to work in VS Code more and switch over to VS only "when I have to".

On the one hand this is great for cross-platform development (as is the topic here), as VS Code is about as cross-platform as it gets.

On the other hand it feels increasingly interesting/weird/almost-sad that the expensive flagship of the VS brand sometimes seems to be left behind by its tinier, free (as in beer and speech) counterpart.

I don't think your theory is entirely correct, but I think some of it applies here: VS Code started as an Azure project (the core editing experience Monaco was designed for the Azure Portal first and foremost) and seems to get a lot of love precisely because of its cloud synergies and its place near Azure's heart. It does seem to have captured the hearts and minds of most of Microsoft's best tooling engineers. That said, it's possibly the most "Developers developers developers" they've ever been given how much of that tooling is now cross-platform, isn't tied so much to Windows specifically, and isn't tied as much to Microsoft-only languages either.

Interesting article from last November that touches on the tension between VS and VS Code: https://www.theregister.com/2021/11/08/dotnet_6_vs_2022/

That's true. I guess when I think of Microsoft prioritizing Azure over Visual Studio (which I understand) I'm thinking of VS code on the Azure side even though it is a tool.

There’s always some degree of a rotating cast of people, that’s always been the case.

Really there’s three important factors in perceived VS perf issues:

1. Your codebases have gotten bigger. More projects in a solution and more code in a project means more work the IDE has to do. Various components have their breaking points and it’s not uncommon to hit them.

2. VS is really really really really big. Some components in there run like a well-oiled machine. Others, like those last touched in 2013 and with less than 10k users per month, are rickety and will freeze your UI or cause the GC to freak out or both. If you’re one of those 10k users, whoopsie!

3. For many years the mandate in the VS org at Microsoft was that of a feature factory. That changed around 2016 or so, maybe a little earlier. But cleaning up a decade of feature factory work while still needing to innovate on a growing userbase that throws more and more at the IDE each year is hard.

we are developing a connected vehicle platform in .net on azure and one dev is using Rider on Ubuntu and is quite happy.

I write F# on Linux with both Emacs and VS Code. Works really well. LSP, Iodine, Fantomas greatly improve the IDE experience.

My experience playing around with F# on linux was about the same but I used the snap version of dotnet core which when I using LSP/iodine ended up spawning infinite processes. Eventually, after a lot of trouble with that I thought of using C# and it was then that dotnet told me that because I was using a snap install (which the docs at the time recommended) that things wouldn't work. Some time later I switched distros and reinstalled dotnet from a package instead of a snap which had the effect of actually working as stated. TLDR; be weary of using the snap install (maybe it was user error on my part or maybe they've worked out the kinks) and be prepared to install via a package/source.

Its fine, just don't use VS for Mac. VS Code or Rider is the only sane workflow IMO.

Cross compilation is just as good as Go, and they are just starting to have the ability to generate native code instead of a wrapped runtime.

At work we have .NET6 running on both Linux and M1 dev laptops. We use JetBrains Rider as the IDE of choice. It works well, and we run it in production in our kubernetes cluster (on Linux, obviously).

We develop ASP.NET REST APIs for big gov services and automate deployments using pwsh. Most of the team work on Windows and some on Linux. Some use VS, some VS Code and we have deployments on both Windows and Linux machines. Pwsh is used extensively on any OS. For build we use Invoke-Build cross platform pwsh build framework and for tests Pester. I can not recall we had some serious problems on those OSes.

Regarding performance, I am impressed.

The platform and language is top notch IMO. It look like MS is entirely new beast since Nadella took the ship.

> pwsh is used extensively on any OS

:heart:

How do you sudo? AFAICS this is the biggest unsolved problem for pwsh on *nix.

On Windows I use awesome (and really only solution at this moment) gsudo: https://community.chocolatey.org/packages/gsudo

On Linux, you can use something like this: sudo pwsh -C <command> (or create wrapper for it...). Sure, not exactly full blown sudo but you could wrap it into scripts when needed and give appropriate sudo rules.

Been developing my app (https://github.com/webreaper/damselfly) on an M1 Mac for the last 2 years, and a Macbook pro prior to that. Development experience is pretty good - been using VS for Mac 2022 since Sept 2021. As has been mentioned, there are some challenges around drawing stuff, but nothing that ImageSharp and SkiaSharp haven't covered admirably.

I wrote up my experiences of getting AI/face-recognition working cross-platform here: https://damselfly.info/face-recognition-in-net-the-good-the-...

If you’re just doing light work, by all means, maybe even server side development.

I think you have to use Mono Runtime w/o Windows which has poor performance. But ofc if your production is in a Windows environment that matters little.

> I much prefer a Linux dev environment over a Windows one

I used to try and get everything running on Linux. Unless you have some political motive, it’s not worth going against the grain.

C# development is ideal in Visual Studio, I could look at Vs code more, especially its debugging, but I don’t think it comes close to VS.

I know Windows isn’t very cool. There’s no modular user environment, not very programmer friendly, but it’s such a small price to pay when faced against getting something to actually work.

Just remember C# maybe great and ever expanding, but it’s just a language, and an enterprise centered one at that. I’ve worked with C# professionally for 3 years.

> C# development is ideal in Visual Studio, I could look at Vs code more, especially its debugging, but I don’t think it comes close to VS.

Some people like visual studio more but vs code works great for c# on linux. You only really need visual studio if you want the gui builder or you're doing windows c++ stuff.

> I think you have to use Mono Runtime w/o Windows which has poor performance.

This is just completely wrong (like 10 years out of date?). The dotnet runtime is the same on both linux and windows now as of .net core (now just ".net" as of .net 6+)

> You only really need visual studio if you want the gui builder or you're doing windows c++ stuff

VS code isn't an IDE, afaik there's no official support for .csproj, .sln, and any of the essential build automation technologies in the .NET ecosystem. There's no practical way to add NuGet packages in VS code, just 3rd party plugin city.

> VS code isn't an IDE, afaik there's no official support for .csproj, .sln, and any of the essential build automation technologies in the .NET ecosystem. There's no practical way to add NuGet packages in VS code, just 3rd party plugin city.

There is "official support" in that vs code will parse these files and understand nuget packages you have added, and the norm when using .net code on linux is to use the dotnet command or edit the project file directly.

I guess you want more of a gui interface for these things built into the ide, in which case yes, you should probably stick to visual studio on windows, but I've used .net on linux with vs code a lot and none of these things have ever struck me as the least bit inconvenient so I guess it just depends on what you want?

To put it another way, using vscode with the dotnet command on linux is a lot like using other modern languages like rust, and I don't think anyone would say that it's impossible to use vscode with rust on linux because there's no gui for adding packages.

Moved to MBP 14" M1 Pro and never looked back! VS Code as fast prototyping and code writing tool, then Rider for debugging and performance work. Both work really well and it's insane how full system draw gets as low as 4W in dark environments when doing fully-fledged development. I strongly recommend this to anyone working with .NET as a back-end dev.

On the note, .NET 6 and Omnisharp fully support debugging both arm64 binaries and cross-platform debugging of the x86 ones. What's more, .NET 7 includes A LOT of improvements to arm64 codegen so the things will only continue to improve.

Developing in F# full-time (.NET 6) on MacOS (M1) using Rider as my IDE of choice. Works like a charm.

I’ve spent the last 3 years running manjaro ( and ubuntu ) doing .net dev deployed to windows and linux (arm64 on t4g m6g) on AWS.

JetBrains Rider. Been solid no issues. Hate going back to windows to do dev work.

It works just fine on Linux. 2 years ago I wrote an application in .NET Core using Emacs on Linux and the whole process was seamless. I assume it's even better now, since it's been so long.

Outside Windows, you are constrained to ASP.NET and CLI stuff.

Plenty of .NET workflows still rely on libraries that are Windows only, because they either depend on classical .NET Framework, Windows specific APIs or VS plugins.

Watch this week's BUILD about all the cool features to develop on Azure and Linux (WSL) with VS, and then check which talks still refer to other workloads.

Unfortunately Microsoft's management still considers VS4Mac and VSCode second class, and hinders FOSS efforts with such actions.

Don't forget gamedev. Have never used C# on Windows actually, but I've been using it for game dev in godot for a couple of years now on Linux and it works great for that.

I have been doing back-end development based on .net core/5/6 using Linux and Rider since ~2018. I had to switch to windows a few times due to corporate environment requirements. It happened again a few weeks ago. Fortunately Windows 11 + WSLg is stable and I'm running Rider inside it. Maybe I'll be running the IDE from Windows once Jetbrains release Rider's WSL support (or Jetbrains Gateway).

I use vscode on debian in my startup for .NET development. My experience has been great, but I get the feeling that since WSL2/Docker are available for Windows that there aren't many people like me outside of hobbyists.

A lot of bigger companies want to use things like applocker to secure any machine inside their network, which makes linux problematic.

I use Rider on a M1 Max Mac along with .NET 6 for professional and personal dev - it’s boring in that it works well.

Developed mostly on Mac, deployed to Linux hosts packaged in Docker containers.

The non-windows .NET ecosystem is quite strong, imo!

edit: my personal advice is not to use VS Code as I found the .NET/C# integration to be quite buggy.

How about forms/CRUD?

Most of what I’m working on in .NET is not web apps - it’s long running console applications.

Just like with Java/node.js, it works okay, but it is its own ecosystem

You'll need the runtime to run things where they are deployed, and it is a huge dependency

No debugger/profiler available on linux (except a commercial one from jetbrains)

Hi mate, Visual Studio is available for Mac, not sure about Linux. If you can get by with VS Code then you should be set.

Maybe Ryder is available in Linux? It should be just as good as VS.

Oh, apologies I didnt understand you are asking about job opportunities. We have about 10 people doing c# at our place and we dont ask what their OS is.

Reply on news.ycombinator.com