6 ms·

Who is using .NET on Linux? I'm interested to hear success stories. Sounds like a a great way to build and deploy applications.

actionfromafar 3y ago
Mostly web stuff, ASP.NET and such.
devjab 3y ago
We do, in the few things we haven’t yet migrated away from C#. I’m curious as to why you wouldn’t, it’s much cheaper than deploying on windows since you’ll likely need a license for that. We use it for a range of things. Mostly related to the legacy software of when our developers were mostly C# developers. Which isn’t how things are now, as C# has often stood in the way of our ability to deliver business value at a rapid pace while keeping maintainable systems. Not so much the languages fault as how Microsoft manages a lot of the libraries. Like how the model builder for EF and OData (both official Microsoft libraries) don’t work together and how you need to extend basically any standard library to do any real work with them. So while it’s actually a decent language, if a bit verbose, and .NET is sort of solid these days, we honestly have very few success stories with it. Some of our AD (now Entra ID I guess) integration operates on it while we slowly migrate it to Powershell (which is .Net but runs in Azure Automation). Some of our APIs run with it. We have a few azure function apps (in containers and isolated) which are being migrated to other techs, and non-function apps. So it’s not like it’s not “working” for us, it’s just that it works a lot less great than its alternatives, even despite a it’s huge leap forward in recent years. Honestly it feels like Microsoft mostly keeps C# around because it sells licenses to medium sized stagnating companies, considering how “half-finished” a lot of the libraries are and how poorly so many of them function together.
- all2 3y ago
  What language and frameworks has your business shifted into? How has that better fit the goals of speed of development and maintainability?
  - devjab 3y ago
    We’re switching into Powershell for operations. With azure automation. We’re switching to Go for concurrency. C and C++ for computation (though to be fair, we were already doing this with C# and the integration between them has always been great). Our generalist language has become TypeScript however. Not because it’s great technically, but because it lets us share resources better which in term has made us much more productive in meeting our business needs. I don’t think C# is bad, I also think it’s much better today than it used to be. If your use of it remains within what works well I think it’ll be hard to find a language with better tooling, but if your needs go beyond that you’re going to have to fight it a lot.
    - canadianfella 3y ago
      [dead]
    - pharmakom 3y ago
      What does Go offer that C# does not? Both have actors, channels, threads, etc.
      - throwaway2990 3y ago
        > What does Go offer that C# does not? Nothing. This often happens when people don’t know .net to begin with. Better they go to go than complain about non existent issues in. .net.
      - lenkite 3y ago
        Do C# channels offer lightweight concurrency ? The defining feature of Go is only matched by Erlang/Elixir and now Java. AFAIK C# has nothing like it.
        neonsunset 3y ago
        C# approach to concurrency has always been better since its introduction. It does have Channels which offer more focused pattern for SPSC, MPMC, etc. scenarios but neither Java nor Go offer a comparable level of ease of use as C#’s hot-started tasks: // The tasks will run in parallel var data = service.GetData(id); var user = service.GetUser(name); Handle(await data, await user); Re: the above comment on switching to Go for concurrency - probably one of the most ill-informed things I have read in the last few days. Doing this borders on incompetence due to the lack of analysis of the utilized technology - Go's GC offers far worse throughput and its concurrency story at best is "on par" with C#.
- genuine_smiles 3y ago
  What are you using instead?
- skrebbel 3y ago
  I agree that many of MS’s “open source” libraries (eg EF, OData) are half-assed, badly run projects. I’m also still mad at them for competing against amazing stuff like ServiceStack (a real OSS project from the community, and the best way to run REST APIs I’ve ever seen) with “official” but worse stuff like ASP.NET Web API. They do this a lot, some OSS gets popular but instead of embracing it, they make a half-assed ripoff, proudly proclaim it “official” on conferences and all the C# devs jump off the cliff like lemmings, and the original OSS project dies/stagnates. MS might have officially embraced Open Source but they’re absolutely awful at fostering an OSS community. But .NET itself is amazing! There’s this weird misconception in Microsoft land that if you choose .NET you must also use all MS’s half-assed libraries. Just use Postgres! Use a lean ORM like Dapper, use Redis, use whatever you want from the wider OSS ecosystem. There’s nothing about C# that forces you onto Entity Framework. Get out of that red polo shirt and look around, there’s a lot of cool stuff out there.
  - fullstackchris 3y ago
    to be fair though, using Entity Framework at least for migrations has worked really well in my experience (and doesnt prevent you from using any of those other OSS tools you mentioned!) still have yet to learn / try dapper
  - efdee 3y ago
    Calling ServiceStack OSS is disingenuous since it comes with quite a heavy price tag for commercial use.
    - skrebbel 3y ago
      Not back in the day. IIRC it was mostly FOSS and the author gradually shifted to a more commercial model when MS waltzed all over it with ASP.NET Web API. I’m quite impressed he made it through actually, and I can’t fault someone for going full commercial when a giant moloch whose ecosystem you’re supporting pulls the rug under you like that.
      - efdee 3y ago
viraptor 3y ago
Many apps from the ...arr series (sonarr, radarr, prowlarr, and others) use .net.
all2 3y ago
I do C# and dotnet for my day job. All my recent side projects have been dotnet on Linux. It's pretty painless.
skrebbel 3y ago
I once was CTO of a now defunct startup and we ran a C# backend against a postgres db inside Docker containers on Linux. This was before MS was on board with Linux and all, but Mono was already super good tech. It wasn’t as fast as real .NET but it was still way faster than eg Python or Ruby, the popular backend languages of the day. There was even a half decent cross platform IDE (MonoDevelop), most of the dev team wasn’t on Windows. I guess this is not very actionable knowledge anymore but I assume that if C# on Linux was productive and fast in 2013 it won’t have gotten any worse today. Somehow linux/mac people seem to avoid .NET out of sheer cultural avoidance, and Windows people seem to avoid most of the OSS ecosystem like the plague for awkward “i was at a .net conf and all the talks were about MS tech” reasons but actually the two combine really well. C# is a great language with unparalleled tooling. It’s easy to learn for people with nearly any background. It’s fast, it’s easy to refactor, it’s easy to debug and it runs everywhere. For over a decade now. My current company runs Elixir because we’re a chat API and the BEAM’s parallelism/robustness story is uniquely suited to our product. If we’d be in a different domain I’d choose C# (on linux, with postgres) again in a heartbeat.
- pid-1 3y ago
  Re: 4th paragraph Nowadays Windows only provides a nice SDK for C#. If you want to create apps in any other language you will need to use the Win32 ABI or some wrapper.
  - deleted 3y ago
    [deleted]
- supertron 3y ago
  You're right, Mono was pretty good even in the very early days. I had a small C# Mono app deployed on macOS in a similar time period (possibly close to 10 years ago now) and I was amazed at how well it worked at the time. It also felt like magic somehow, after having my .NET development tied to Windows for so long before that... There were a lot of caveats then and quite some disparity in how it would run on Mono vs normal .NET Framework. > I assume that if C# on Linux was productive and fast in 2013 it won’t have gotten any worse today. Safe assumption!
konaraddi 3y ago
It's common to run .NET apps in linux containers in production.
- throwaway2990 3y ago
  It's common to run .NET apps on linux in production. Fixed.
fodkodrasz 3y ago
I have good and bad experience as well. I do have a prototype project, and while it allowed to get going quickly, I found the remote debugging story useless, as Visual Studio 2022 SSH support is a steaming pile of garbage. (Doesn't use the windows systemwise ssh install, but some crappy library that only supports password auth, or some wonkny certificate format, and outdated ciphers, which is understandably disabled, wasted an hour and insecured the target machine, and gave up finally). I used SQLite, and the System.Data.SQLite, because reasons (legacy). It is a bug ridden piece of work (on linux), with no sane way to contribute. Also it is useless on M1 Mac, as the author doesn't give a shit about compiling it for arm (or setting up a CI pipeline on github or gitlab for example, where it is supported). Had plenty of problems with single file app bundle deployment, as much as it eased deployment initially, lots of libraries broke on it. It has been working okay for us (in other former projects) generally well, but personally I am missing some things from the JVM, where VM tuning and monitoring and remote debugging are all a smoother ride in my experience. Oh, and async broke the C# language (or rather the standard library) and killed the CLR interop with other languages, it was a big mistake to release it with these defaults. I really like F#, but async everything made it uselessly difficult in my opinion. But it has nothing to with .Net on Linux. It works, and is way better than the nodejs world, but I think more ideas should be copied from the JVM world to ease the Ops side, or they should be more clearly communicated.
- SideburnsOfDoom 3y ago
  A decent setup of logging and metrics from UAT and prod environments seems to me a superior alternative to remote debugging.
  - fodkodrasz 3y ago
    Bit snarky PTSD induced rant: Thanks for the unsolicited advice on the situation you have nigh no context on. A bit of context: I could put decent logging and metrics inside the buggy System.Data.SQLite library, to know why it fails to do its job in remote Linux machines... which would be quite and effort (Comparable to forking and fixing it, which might be the goal, but getting the info for the problem is rather an interactive problem. Even opening the database didn't work). Also Logging from inside libraries is... a bit divisive topic. At our shop logging and metrics are not always the best answers, when *developing*, they are mostly useful for *operating* a solution.
SeriousM 3y ago
At my company, every api server and azure function is executed in k8s as linux container. The license costs and performance footprint are a huge factor to not run on windows. And docker-images for the CI production. Linux is just so much better IMHO. I would switch to linux if visual studio (not vscode) would run there natively.
- dranudin 3y ago
  You could try out Rider on linux. I use it since a few months (on Windows though) and it is pretty great. I used Visual Studio before and Rider is definitely competitive.
- j0nimost 3y ago
  try out Rider, you'll love it
0xDEF 3y ago
Most .NET backend services and web apps are now deployed on Linux (containers). The default .NET PaaS experience on Azure (App Service) also defaults to Linux.
pjmlp 3y ago
Microsoft shops cutting down on license costs for serverless deployments on Azure. For those cases we do the same approach we have been doing with Java for decades, developing on Windows, deploying on Linux based instances. Other than that, still too many projects depend on .NET Framework. I still have too much of .NET version of Python 2/3 transition.
chimbosonic 3y ago
Most of our backend APIs are written in C#. We deploy them on AWS lambda, so on Linux. Pipelines are Linux and Devs will use a mixture of Linux, MacOS or Windows.
pharmakom 3y ago
We do and it’s brilliant. Technically, we are using Microsoft official dotnet Docker images, not bare metal. Building is really simple and we can cross-compile from developer MacBooks. I expect similar success is possible with JVM but F# is too good to pass up!
Rochus 3y ago
I'm using the Mono CLR which is a great as a runtime system for statically typed languages; it's lean, efficient and easy to use and deploy (e.g. compared to LLVM), with an integrated, cross-platform debugger. It runs even on old embedded Linux images. Dependency on the .NET framework is possible, but not necessary.
tmitchel2 3y ago
Been using dotnet on a Mac + AWS for many years, awesome combo that's only getting better.
SideburnsOfDoom 3y ago
> Who is using .NET on Linux? We don't usually even think about it, but for web apis, function apps and other microservices that process data over http or message queues, it's more or less the default now that the production environment is a linux of some kind. But it isn't a thing that we spend time worrying about.
voxadam 3y ago
I serve videos from my home Linux server using Jellyfin[0][1] and previously ran Emby[2] (from which Jellyfin was forked). Jellyfin is written in C# and runs on .NET 7. [0] https://jellyfin.org/ https://jellyfin.org/ [1] https://github.com/jellyfin/jellyfin https://github.com/jellyfin/jellyfin [2] https://emby.media/ https://emby.media/
- tentacleuno 3y ago
  Jellyfin is great for movies & shows. As an anecdote, it's not so good for music if you're a collector. I personally use Navidrome for that[0]. Anyway, Sonarr[1] makes use of .NET, too. Very reliable software, in my experience. [0]: https://github.com/navidrome/navidrome https://github.com/navidrome/navidrome [1]: https://github.com/Sonarr/Sonarr https://github.com/Sonarr/Sonarr
  - majkinetor 3y ago
    I am a music collector and I don't see a problem with Jelly, apart from android app pausing after first song. It recognized my Musicbrainz filled library immediately without any problem, it was 0 effort to have it fully available on the web with multiple accounts.
    - tentacleuno 3y ago
      IME Jellyfin struggles to deal with a few edge-cases, and the ecosystem for Subsonic is generally better: more applications, more servers, and therefore ultimately more choice. Though Navidrome may be the most popular, there are plenty of clients to choose from (Supersonic, Sublime-music, etc. etc.) where such an ecosystem doesn't really exist for Jellyfin.
pbiggar 3y ago
We do at Darklang, the repo is open if you want to take a look https://GitHub.com/darklang/darklang https://GitHub.com/darklang/darklang We deploy in Linux containers to cloud run, and we're about to start shipping a cross platform language binary, so people can run Darklang on any system. Dotnet does cross platform builds from any OS.
paulmendoza 3y ago
We have been running all of our .net apps on Linux for years. No problems. Works great.
klauserc 3y ago
We do, very successfully (large online retailer). Moving off of Windows as a deployment target simplified our processes significantly. Developers use a mix of Windows and Mac to develop, running the services "natively", before we ship them as Docker images to k8s. There are some "Windows-isms" buried deep in the older layers of the standard library, but these tend to be not relevant for backend services (anything that talks via the network). I experience .NET as a very productive tech stack. If I were to found a startup tomorrow, I'd pick .NET for boring web service stuff.
supertron 3y ago
I am. I've been developing with .NET since the start and my current workflow is really the smoothest and most productive (and most enjoyable!) I've ever had: I develop solely on Mac (JetBrains Rider), compiling/debugging Mac binaries locally - no containers - unless I need any external dependencies like eg. Postgres. On M1 MacBook Pro the experience is blazing fast - and Rider can be pretty heavy but Apple Silicon eats it up. (And to be fair to Rider, it was still pretty good even on Intel machines). Everything is built and tested on Linux (and sometimes Mac) runners in GitHub. Then I deploy direct to cloud-based "disposable" Debian VMs. If it's a small/hobby project, I can get really great performance out of even the smallest VMs. For those interested in the details; I most often run production .NET ASP.NET apps as a systemd service on Debian using the native/in-built .NET Kestrel web server, and almost always (currently) use Cloudflare Tunnel as a reverse proxy for ingress traffic. No inbound ports open in Linux. I've got multiple production systems running like this including some load-balanced using Cloudflare Tunnel load balancing features, and it works really nicely. The .NET team have been laser focused on performance since the early days of .NET Core and they haven't let up on this. The whole experience is night and day compared to "legacy" .NET Framework development. My entire workflow is now Windows free - and for me there are no longer any compromises compared to developing/deploying on a Windows stack (in the early Mono days, there used to be a lot of compromises compared to a then first-class Windows experience, but no more...) I have some strong (negative) opinions about what Microsoft is doing to the Windows ecosystem - which is partly why it's been a delight to no longer have to use it in any part of my day-to-day - but I will extoll the benefits of .NET all day long. The .NET team really do an amazing job. * * For the purposes of generosity, I will briefly overlook MAUI and the slight mess that is the .NET GUI based app story...
- solarkraft 3y ago
  > Rider can be pretty heavy but Apple Silicon eats it up. (And to be fair to Rider, it was still pretty good even on Intel machines). Rider (like all JetBrains IDEs) gobbles RAM and sometimes needs its time to think. But what makes it so, so much better than Visual Studio (besides a minimum of effort spent on usable design) is that it doesn't randomly completely lock up the UI for several (sometimes tens) of seconds. Unlike Microsoft apparently, they know not to do their heavy computation on the UI thread.
vladvasiliu 3y ago
Not me personally (I'm not a dev), but where I work, we have two teams working on two separate projects written in .net that run in Linux containers on ECS. The devs themselves use Visual Studio on Windows for local dev. These things work very well and seem to use very few resources. Those systems manage retail kiosks and similar stuff, and one of the two systems is actually on the critical path for operation, so it's not like they only do housekeeping once in a while.
fearface 3y ago
Microsoft and many others.
maxlin 3y ago
I have a single-file executable with the framework embedded, that I run on all of my computers, from desktops and laptops to cloud VMs to SBC's. -it's designed to be run once after which it auto-registers itself to always stay running (linux:systemd, windows: task scheduler), while keeping itself up to date -It contains my CI system (runs software from git, either one run per commit or "keep running forever" mode, UI thru local web server with even browser blazor support hacked in). I use this to run my other programs like servers, crawlers, telegram bots which I write in dotnet and almost always in a way that they run identical on Linux and Windows, x64 or aarch64 (arm). The CI system installs its own dotnet env and env variables to ease with dependencies for the programs ran with it -It constantly updates its state to a relatively simple azure C# app which functions as a status webpage for all my machines and provides some basic controls like "restart machine" while sending notifications of unexpected machine on/off states -The executable is capable of automatically updating itself through the central web app server. It does a dance of downloading new version starting the new version as "MRestartor_new", which is then started and renames the current "MRestartor_old", which then starts that "_old" which will rename the newly downloaded one to "MRestartor", then starts that. -I've half-added a few extra features like remote console, remote VNC-like desktop too My friend keeps telling me I've re-invented a shitty kubernetes but I actually want to, and need to run this on desktop windows machines (previous reason was Unity build server, now also need it for non-headless puppeteered chrome), and am planning to run some "infoscreen"-like software on it for some computers which would not be possible inside docker to start with. Outside of this system, I've found the "single file executable" option to be a very pragmatic way to just have a "companion app" bundled with an Unity game for example, that the game starts, and if the game crashes, it sends a crash log. Functions with zero dependencies so even caught an Unity slip-up where Unity actually needed some almost-ubiquitous dll a virgin Windows that our publisher's PC had doesn't actually come with
AdrianB1 3y ago
My department is only .NET due to dependencies to specific third-party manufacturing software that is .NET and we use their SDK for a lot of stuff. 95% of our apps run on Windows, 5% on Linux. The Linux part exists only because management heard about it and mandated to try it, not because it makes any sense - the third party software runs only on Windows, so even creating 2 dedicated servers with Linux (out of several dozens with Windows) in every plant is just a major pain in the back and a complication that does not pay out. But if you don't have dependencies and limitations to Windows and you can go full swing with Linux, it's a matter of overall cost and productivity, use what is best for you.
bob1029 3y ago
We were looking at that, but we found Azure Functions to be an even better overall experience. Today, we develop w/ VS2022 on Windows, push to GitHub, and the GH actions take it to function deployments from there. Then, we monitor for any exceptions using app insights search from visual studio. The developer experience is flawless. I don't even have to touch the azure web UI to do the happy path. Finding exceptions using the native VS tooling is much easier. All the pieces fit together really well now - managed identity alone saving us probably a FTE role in our org chart.
- SideburnsOfDoom 3y ago
  > we develop w/ VS2022 on Windows, push to GitHub, and the GH actions take it to Azure functions There's actually likely some linux in that stack under the GHA and Azure functions. But this is very much like what I find - "is this .NET running on linux?" is question where the answer is frequently "yes" but also is not an important or interesting question.
JackMorgan 3y ago
I maintain three different projects for three business in .NET Core using Linux Docker containers and it's been very smooth. The ability to have both C# and F# along with a ton of perfectly serviceable libraries is great. I'm using ASP.NET Core for the web stack, swashbuckle to auto generate swagger docs, EF for auto generated database models. It's pretty great actually. Adding a new field is as easy as making a migration file, changing the API message, and adding one line to map the database model field to the message field. Everything just moves smoothly. The resulting web servers just work. I've had effectively no issues with them at all. The only issues I've had were the result of Portainer not correctly shutting down a container, which really isn't related to .NET at all.
GordonS 3y ago
I am, for a range of applications including web APIs and background workers. I've always favoured Linux for server apps (I used to deploy dotnet apps to Linux with Mono), but I also think Azure (and cloud in general) has, in a roundabout way, introduced a lot of .NET developers to Linux. There's little reason not to deploy to Linux instead of Windows - it's cheaper and just a much better experience to work with for deployment and operations.
torginus 3y ago
We are - we are in the process of transitioning our ASP.NET based backend from Windows to Linux. Linux machines are cheaper and easier to administer than Windows based ones.
- ragestorm 3y ago
  Same here. We are also getting some performance gains on transaction processing and system.io stuff (10% or so) compared to windows. Additionally, some of clients are linux and we have to ensure that our programs work flawlessly on it.
Decabytes 3y ago
I use .NET on Linux and the experience with Rider has been great. The workflow transfers really well between Mac, Windows, and Linux, and everything works the way you expect. The only problems I run into are that there are still things that are Windows focused. For example MAUI does not run on Linux which is a shame because we could use another cross platform GUI. There are still bugs, for example I ran into one with Polyglot Notebooks not working on Manjaro or Pop!_OS https://github.com/dotnet/interactive/issues/3159 https://github.com/dotnet/interactive/issues/3159 but hopefully that will just get better with time. I think the biggest with .NET is that it spent so long being Windows only. A lot of people just developed workflows in other languages. It also took time before .NET core, now just .NET really became first class on Linux. With .NET 8 this will get a lot better, and to my understanding will allow the popular Game Engine Godot to be able to target the web with C# builds. This will allow them to go back to having one Godot binary instead of two. The thing that has me scratching my head though is I can't believe they still don't have System.CommandLine in the standard lib. We want our cli programs please!
Rudism 3y ago
I do contract work for NASA and the main project I work on is transitioning from PostGraphile to an ASP.NET Core WebAPI (currently targeting .NET 7, but will likely look at bumping that to 8 once it's released if it's not too disruptive). I work completely in Linux, coding using Neovim, with Omnisharp for language features and code completion, and our applications are fully built and deployed using Linux containers. .NET on Linux has come a long way since the early days of Xamarin and Mono, it's quite enjoyable to use.
tester756 3y ago
I've been deploying .NET web apps for years The only problem I faced 5 years ago was that I didnt have some fonts installed for pdf generation.
SeanKilleen 3y ago
Our company's app is written in .NET 7 (soon to upgrade to .NET 8) and deployed via Linux containers into Kubernetes. It is a delightful ecosystem to work with. Productivity is huge, great tooling and IDE support even in non-MS ways. I joined this company 3 months ago and what I've been able to get done on this platform is honestly exciting. And I haven't had to sacrifice modern development principles.
moron4hire 3y ago
I've used it exclusively on my servers for the last 5 years and am now using it on my laptop. Server side, it's better than running it in Windows. I don't pay a license fee for the OS, so spinning up new VMs is super easy. And set-up, deployment, and long-term operation have all just gone off without any hitches. I've got Let's Encrypt certificates, Postgres databases, and so little overhead that I can't get by with small server SKUs. On desktop, I still use Windows at work, so I've built a WPF/WebView2 and a GTKSharp/WebKit web app shell that lets me run identical code to my server apps, just as a desktop app. It was pretty fiddly to setup (mostly because GTK is hot garbage), but now that I have it, it just works.
pliHacker2013 3y ago
I suppose it depends what you mean by linux, but if aws lambda on linux counts, then i work at a top 250 UK company who uses dotnet heavily for lambda workloads, especially async workloads. Its been great for us, no complaints. We likely would use it for our sync apis too if dotnet supported apollo federation v2, but sadly it does not.
- jensneuse 3y ago
  Have you seen this? https://www.apollographql.com/blog/announcement/backend/announcing-official-apollo-federation-support-for-net-with-hot-chocolate-and-federation-2/ https://www.apollographql.com/blog/announcement/backend/anno...
  - pliHacker2013 3y ago
    I had not, this is great, thanks
benaadams 3y ago
41% of EVM nodes on Ethereum run .NET on Linux via Nethermind(https://github.com/NethermindEth/nethermind https://github.com/NethermindEth/nethermind). Ethereum has a Market Cap of $249Bn and $34bn of other assets in smart contracts. So you could say .NET on Linux has under management $116Bn and handles $800m of asset transfers per day, napkin math
jakubmisek 3y ago
We already had a huge C# console project originaly developed for windows/.net framework 4.5 .. .net on Linux was a zero cost transition, giving us a whole new platform, a whole new user base. It was that easy.

actionfromafar 3y ago

Mostly web stuff, ASP.NET and such.

devjab 3y ago

We do, in the few things we haven’t yet migrated away from C#. I’m curious as to why you wouldn’t, it’s much cheaper than deploying on windows since you’ll likely need a license for that. We use it for a range of things. Mostly related to the legacy software of when our developers were mostly C# developers. Which isn’t how things are now, as C# has often stood in the way of our ability to deliver business value at a rapid pace while keeping maintainable systems. Not so much the languages fault as how Microsoft manages a lot of the libraries. Like how the model builder for EF and OData (both official Microsoft libraries) don’t work together and how you need to extend basically any standard library to do any real work with them. So while it’s actually a decent language, if a bit verbose, and .NET is sort of solid these days, we honestly have very few success stories with it. Some of our AD (now Entra ID I guess) integration operates on it while we slowly migrate it to Powershell (which is .Net but runs in Azure Automation). Some of our APIs run with it. We have a few azure function apps (in containers and isolated) which are being migrated to other techs, and non-function apps. So it’s not like it’s not “working” for us, it’s just that it works a lot less great than its alternatives, even despite a it’s huge leap forward in recent years. Honestly it feels like Microsoft mostly keeps C# around because it sells licenses to medium sized stagnating companies, considering how “half-finished” a lot of the libraries are and how poorly so many of them function together.

all2 3y ago
What language and frameworks has your business shifted into? How has that better fit the goals of speed of development and maintainability?
- devjab 3y ago
  We’re switching into Powershell for operations. With azure automation. We’re switching to Go for concurrency. C and C++ for computation (though to be fair, we were already doing this with C# and the integration between them has always been great). Our generalist language has become TypeScript however. Not because it’s great technically, but because it lets us share resources better which in term has made us much more productive in meeting our business needs. I don’t think C# is bad, I also think it’s much better today than it used to be. If your use of it remains within what works well I think it’ll be hard to find a language with better tooling, but if your needs go beyond that you’re going to have to fight it a lot.
  - canadianfella 3y ago
    [dead]
  - pharmakom 3y ago
    What does Go offer that C# does not? Both have actors, channels, threads, etc.
    - throwaway2990 3y ago
      > What does Go offer that C# does not? Nothing. This often happens when people don’t know .net to begin with. Better they go to go than complain about non existent issues in. .net.
    - lenkite 3y ago
      Do C# channels offer lightweight concurrency ? The defining feature of Go is only matched by Erlang/Elixir and now Java. AFAIK C# has nothing like it.
      - neonsunset 3y ago
        C# approach to concurrency has always been better since its introduction. It does have Channels which offer more focused pattern for SPSC, MPMC, etc. scenarios but neither Java nor Go offer a comparable level of ease of use as C#’s hot-started tasks: // The tasks will run in parallel var data = service.GetData(id); var user = service.GetUser(name); Handle(await data, await user); Re: the above comment on switching to Go for concurrency - probably one of the most ill-informed things I have read in the last few days. Doing this borders on incompetence due to the lack of analysis of the utilized technology - Go's GC offers far worse throughput and its concurrency story at best is "on par" with C#.
genuine_smiles 3y ago
What are you using instead?
skrebbel 3y ago
I agree that many of MS’s “open source” libraries (eg EF, OData) are half-assed, badly run projects. I’m also still mad at them for competing against amazing stuff like ServiceStack (a real OSS project from the community, and the best way to run REST APIs I’ve ever seen) with “official” but worse stuff like ASP.NET Web API. They do this a lot, some OSS gets popular but instead of embracing it, they make a half-assed ripoff, proudly proclaim it “official” on conferences and all the C# devs jump off the cliff like lemmings, and the original OSS project dies/stagnates. MS might have officially embraced Open Source but they’re absolutely awful at fostering an OSS community. But .NET itself is amazing! There’s this weird misconception in Microsoft land that if you choose .NET you must also use all MS’s half-assed libraries. Just use Postgres! Use a lean ORM like Dapper, use Redis, use whatever you want from the wider OSS ecosystem. There’s nothing about C# that forces you onto Entity Framework. Get out of that red polo shirt and look around, there’s a lot of cool stuff out there.
- fullstackchris 3y ago
  to be fair though, using Entity Framework at least for migrations has worked really well in my experience (and doesnt prevent you from using any of those other OSS tools you mentioned!) still have yet to learn / try dapper
- efdee 3y ago
  Calling ServiceStack OSS is disingenuous since it comes with quite a heavy price tag for commercial use.
  - skrebbel 3y ago
    Not back in the day. IIRC it was mostly FOSS and the author gradually shifted to a more commercial model when MS waltzed all over it with ASP.NET Web API. I’m quite impressed he made it through actually, and I can’t fault someone for going full commercial when a giant moloch whose ecosystem you’re supporting pulls the rug under you like that.
    - efdee 3y ago

viraptor 3y ago

Many apps from the ...arr series (sonarr, radarr, prowlarr, and others) use .net.

all2 3y ago

I do C# and dotnet for my day job. All my recent side projects have been dotnet on Linux. It's pretty painless.

skrebbel 3y ago

I once was CTO of a now defunct startup and we ran a C# backend against a postgres db inside Docker containers on Linux. This was before MS was on board with Linux and all, but Mono was already super good tech. It wasn’t as fast as real .NET but it was still way faster than eg Python or Ruby, the popular backend languages of the day. There was even a half decent cross platform IDE (MonoDevelop), most of the dev team wasn’t on Windows. I guess this is not very actionable knowledge anymore but I assume that if C# on Linux was productive and fast in 2013 it won’t have gotten any worse today. Somehow linux/mac people seem to avoid .NET out of sheer cultural avoidance, and Windows people seem to avoid most of the OSS ecosystem like the plague for awkward “i was at a .net conf and all the talks were about MS tech” reasons but actually the two combine really well. C# is a great language with unparalleled tooling. It’s easy to learn for people with nearly any background. It’s fast, it’s easy to refactor, it’s easy to debug and it runs everywhere. For over a decade now. My current company runs Elixir because we’re a chat API and the BEAM’s parallelism/robustness story is uniquely suited to our product. If we’d be in a different domain I’d choose C# (on linux, with postgres) again in a heartbeat.

pid-1 3y ago
Re: 4th paragraph Nowadays Windows only provides a nice SDK for C#. If you want to create apps in any other language you will need to use the Win32 ABI or some wrapper.
- deleted 3y ago
  [deleted]
supertron 3y ago
You're right, Mono was pretty good even in the very early days. I had a small C# Mono app deployed on macOS in a similar time period (possibly close to 10 years ago now) and I was amazed at how well it worked at the time. It also felt like magic somehow, after having my .NET development tied to Windows for so long before that... There were a lot of caveats then and quite some disparity in how it would run on Mono vs normal .NET Framework. > I assume that if C# on Linux was productive and fast in 2013 it won’t have gotten any worse today. Safe assumption!

konaraddi 3y ago

It's common to run .NET apps in linux containers in production.

throwaway2990 3y ago
It's common to run .NET apps on linux in production. Fixed.

fodkodrasz 3y ago

I have good and bad experience as well. I do have a prototype project, and while it allowed to get going quickly, I found the remote debugging story useless, as Visual Studio 2022 SSH support is a steaming pile of garbage. (Doesn't use the windows systemwise ssh install, but some crappy library that only supports password auth, or some wonkny certificate format, and outdated ciphers, which is understandably disabled, wasted an hour and insecured the target machine, and gave up finally). I used SQLite, and the System.Data.SQLite, because reasons (legacy). It is a bug ridden piece of work (on linux), with no sane way to contribute. Also it is useless on M1 Mac, as the author doesn't give a shit about compiling it for arm (or setting up a CI pipeline on github or gitlab for example, where it is supported). Had plenty of problems with single file app bundle deployment, as much as it eased deployment initially, lots of libraries broke on it. It has been working okay for us (in other former projects) generally well, but personally I am missing some things from the JVM, where VM tuning and monitoring and remote debugging are all a smoother ride in my experience. Oh, and async broke the C# language (or rather the standard library) and killed the CLR interop with other languages, it was a big mistake to release it with these defaults. I really like F#, but async everything made it uselessly difficult in my opinion. But it has nothing to with .Net on Linux. It works, and is way better than the nodejs world, but I think more ideas should be copied from the JVM world to ease the Ops side, or they should be more clearly communicated.

SideburnsOfDoom 3y ago
A decent setup of logging and metrics from UAT and prod environments seems to me a superior alternative to remote debugging.
- fodkodrasz 3y ago
  Bit snarky PTSD induced rant: Thanks for the unsolicited advice on the situation you have nigh no context on. A bit of context: I could put decent logging and metrics inside the buggy System.Data.SQLite library, to know why it fails to do its job in remote Linux machines... which would be quite and effort (Comparable to forking and fixing it, which might be the goal, but getting the info for the problem is rather an interactive problem. Even opening the database didn't work). Also Logging from inside libraries is... a bit divisive topic. At our shop logging and metrics are not always the best answers, when *developing*, they are mostly useful for *operating* a solution.

SeriousM 3y ago

At my company, every api server and azure function is executed in k8s as linux container. The license costs and performance footprint are a huge factor to not run on windows. And docker-images for the CI production. Linux is just so much better IMHO. I would switch to linux if visual studio (not vscode) would run there natively.

dranudin 3y ago
You could try out Rider on linux. I use it since a few months (on Windows though) and it is pretty great. I used Visual Studio before and Rider is definitely competitive.
j0nimost 3y ago
try out Rider, you'll love it

0xDEF 3y ago

Most .NET backend services and web apps are now deployed on Linux (containers). The default .NET PaaS experience on Azure (App Service) also defaults to Linux.

pjmlp 3y ago

Microsoft shops cutting down on license costs for serverless deployments on Azure. For those cases we do the same approach we have been doing with Java for decades, developing on Windows, deploying on Linux based instances. Other than that, still too many projects depend on .NET Framework. I still have too much of .NET version of Python 2/3 transition.

chimbosonic 3y ago

Most of our backend APIs are written in C#. We deploy them on AWS lambda, so on Linux. Pipelines are Linux and Devs will use a mixture of Linux, MacOS or Windows.

pharmakom 3y ago

We do and it’s brilliant. Technically, we are using Microsoft official dotnet Docker images, not bare metal. Building is really simple and we can cross-compile from developer MacBooks. I expect similar success is possible with JVM but F# is too good to pass up!

Rochus 3y ago

I'm using the Mono CLR which is a great as a runtime system for statically typed languages; it's lean, efficient and easy to use and deploy (e.g. compared to LLVM), with an integrated, cross-platform debugger. It runs even on old embedded Linux images. Dependency on the .NET framework is possible, but not necessary.

tmitchel2 3y ago

Been using dotnet on a Mac + AWS for many years, awesome combo that's only getting better.

SideburnsOfDoom 3y ago

> Who is using .NET on Linux? We don't usually even think about it, but for web apis, function apps and other microservices that process data over http or message queues, it's more or less the default now that the production environment is a linux of some kind. But it isn't a thing that we spend time worrying about.

voxadam 3y ago

I serve videos from my home Linux server using Jellyfin[0][1] and previously ran Emby[2] (from which Jellyfin was forked). Jellyfin is written in C# and runs on .NET 7. [0] https://jellyfin.org/ https://jellyfin.org/ [1] https://github.com/jellyfin/jellyfin https://github.com/jellyfin/jellyfin [2] https://emby.media/ https://emby.media/

tentacleuno 3y ago
Jellyfin is great for movies & shows. As an anecdote, it's not so good for music if you're a collector. I personally use Navidrome for that[0]. Anyway, Sonarr[1] makes use of .NET, too. Very reliable software, in my experience. [0]: https://github.com/navidrome/navidrome https://github.com/navidrome/navidrome [1]: https://github.com/Sonarr/Sonarr https://github.com/Sonarr/Sonarr
- majkinetor 3y ago
  I am a music collector and I don't see a problem with Jelly, apart from android app pausing after first song. It recognized my Musicbrainz filled library immediately without any problem, it was 0 effort to have it fully available on the web with multiple accounts.
  - tentacleuno 3y ago
    IME Jellyfin struggles to deal with a few edge-cases, and the ecosystem for Subsonic is generally better: more applications, more servers, and therefore ultimately more choice. Though Navidrome may be the most popular, there are plenty of clients to choose from (Supersonic, Sublime-music, etc. etc.) where such an ecosystem doesn't really exist for Jellyfin.

pbiggar 3y ago

We do at Darklang, the repo is open if you want to take a look https://GitHub.com/darklang/darklang https://GitHub.com/darklang/darklang We deploy in Linux containers to cloud run, and we're about to start shipping a cross platform language binary, so people can run Darklang on any system. Dotnet does cross platform builds from any OS.

paulmendoza 3y ago

We have been running all of our .net apps on Linux for years. No problems. Works great.

klauserc 3y ago

We do, very successfully (large online retailer). Moving off of Windows as a deployment target simplified our processes significantly. Developers use a mix of Windows and Mac to develop, running the services "natively", before we ship them as Docker images to k8s. There are some "Windows-isms" buried deep in the older layers of the standard library, but these tend to be not relevant for backend services (anything that talks via the network). I experience .NET as a very productive tech stack. If I were to found a startup tomorrow, I'd pick .NET for boring web service stuff.

supertron 3y ago

I am. I've been developing with .NET since the start and my current workflow is really the smoothest and most productive (and most enjoyable!) I've ever had: I develop solely on Mac (JetBrains Rider), compiling/debugging Mac binaries locally - no containers - unless I need any external dependencies like eg. Postgres. On M1 MacBook Pro the experience is blazing fast - and Rider can be pretty heavy but Apple Silicon eats it up. (And to be fair to Rider, it was still pretty good even on Intel machines). Everything is built and tested on Linux (and sometimes Mac) runners in GitHub. Then I deploy direct to cloud-based "disposable" Debian VMs. If it's a small/hobby project, I can get really great performance out of even the smallest VMs. For those interested in the details; I most often run production .NET ASP.NET apps as a systemd service on Debian using the native/in-built .NET Kestrel web server, and almost always (currently) use Cloudflare Tunnel as a reverse proxy for ingress traffic. No inbound ports open in Linux. I've got multiple production systems running like this including some load-balanced using Cloudflare Tunnel load balancing features, and it works really nicely. The .NET team have been laser focused on performance since the early days of .NET Core and they haven't let up on this. The whole experience is night and day compared to "legacy" .NET Framework development. My entire workflow is now Windows free - and for me there are no longer any compromises compared to developing/deploying on a Windows stack (in the early Mono days, there used to be a lot of compromises compared to a then first-class Windows experience, but no more...) I have some strong (negative) opinions about what Microsoft is doing to the Windows ecosystem - which is partly why it's been a delight to no longer have to use it in any part of my day-to-day - but I will extoll the benefits of .NET all day long. The .NET team really do an amazing job. * * For the purposes of generosity, I will briefly overlook MAUI and the slight mess that is the .NET GUI based app story...

solarkraft 3y ago
> Rider can be pretty heavy but Apple Silicon eats it up. (And to be fair to Rider, it was still pretty good even on Intel machines). Rider (like all JetBrains IDEs) gobbles RAM and sometimes needs its time to think. But what makes it so, so much better than Visual Studio (besides a minimum of effort spent on usable design) is that it doesn't randomly completely lock up the UI for several (sometimes tens) of seconds. Unlike Microsoft apparently, they know not to do their heavy computation on the UI thread.

vladvasiliu 3y ago

Not me personally (I'm not a dev), but where I work, we have two teams working on two separate projects written in .net that run in Linux containers on ECS. The devs themselves use Visual Studio on Windows for local dev. These things work very well and seem to use very few resources. Those systems manage retail kiosks and similar stuff, and one of the two systems is actually on the critical path for operation, so it's not like they only do housekeeping once in a while.

fearface 3y ago

Microsoft and many others.

maxlin 3y ago

I have a single-file executable with the framework embedded, that I run on all of my computers, from desktops and laptops to cloud VMs to SBC's. -it's designed to be run once after which it auto-registers itself to always stay running (linux:systemd, windows: task scheduler), while keeping itself up to date -It contains my CI system (runs software from git, either one run per commit or "keep running forever" mode, UI thru local web server with even browser blazor support hacked in). I use this to run my other programs like servers, crawlers, telegram bots which I write in dotnet and almost always in a way that they run identical on Linux and Windows, x64 or aarch64 (arm). The CI system installs its own dotnet env and env variables to ease with dependencies for the programs ran with it -It constantly updates its state to a relatively simple azure C# app which functions as a status webpage for all my machines and provides some basic controls like "restart machine" while sending notifications of unexpected machine on/off states -The executable is capable of automatically updating itself through the central web app server. It does a dance of downloading new version starting the new version as "MRestartor_new", which is then started and renames the current "MRestartor_old", which then starts that "_old" which will rename the newly downloaded one to "MRestartor", then starts that. -I've half-added a few extra features like remote console, remote VNC-like desktop too My friend keeps telling me I've re-invented a shitty kubernetes but I actually want to, and need to run this on desktop windows machines (previous reason was Unity build server, now also need it for non-headless puppeteered chrome), and am planning to run some "infoscreen"-like software on it for some computers which would not be possible inside docker to start with. Outside of this system, I've found the "single file executable" option to be a very pragmatic way to just have a "companion app" bundled with an Unity game for example, that the game starts, and if the game crashes, it sends a crash log. Functions with zero dependencies so even caught an Unity slip-up where Unity actually needed some almost-ubiquitous dll a virgin Windows that our publisher's PC had doesn't actually come with

AdrianB1 3y ago

My department is only .NET due to dependencies to specific third-party manufacturing software that is .NET and we use their SDK for a lot of stuff. 95% of our apps run on Windows, 5% on Linux. The Linux part exists only because management heard about it and mandated to try it, not because it makes any sense - the third party software runs only on Windows, so even creating 2 dedicated servers with Linux (out of several dozens with Windows) in every plant is just a major pain in the back and a complication that does not pay out. But if you don't have dependencies and limitations to Windows and you can go full swing with Linux, it's a matter of overall cost and productivity, use what is best for you.

bob1029 3y ago

We were looking at that, but we found Azure Functions to be an even better overall experience. Today, we develop w/ VS2022 on Windows, push to GitHub, and the GH actions take it to function deployments from there. Then, we monitor for any exceptions using app insights search from visual studio. The developer experience is flawless. I don't even have to touch the azure web UI to do the happy path. Finding exceptions using the native VS tooling is much easier. All the pieces fit together really well now - managed identity alone saving us probably a FTE role in our org chart.

SideburnsOfDoom 3y ago
> we develop w/ VS2022 on Windows, push to GitHub, and the GH actions take it to Azure functions There's actually likely some linux in that stack under the GHA and Azure functions. But this is very much like what I find - "is this .NET running on linux?" is question where the answer is frequently "yes" but also is not an important or interesting question.

JackMorgan 3y ago

I maintain three different projects for three business in .NET Core using Linux Docker containers and it's been very smooth. The ability to have both C# and F# along with a ton of perfectly serviceable libraries is great. I'm using ASP.NET Core for the web stack, swashbuckle to auto generate swagger docs, EF for auto generated database models. It's pretty great actually. Adding a new field is as easy as making a migration file, changing the API message, and adding one line to map the database model field to the message field. Everything just moves smoothly. The resulting web servers just work. I've had effectively no issues with them at all. The only issues I've had were the result of Portainer not correctly shutting down a container, which really isn't related to .NET at all.

GordonS 3y ago

I am, for a range of applications including web APIs and background workers. I've always favoured Linux for server apps (I used to deploy dotnet apps to Linux with Mono), but I also think Azure (and cloud in general) has, in a roundabout way, introduced a lot of .NET developers to Linux. There's little reason not to deploy to Linux instead of Windows - it's cheaper and just a much better experience to work with for deployment and operations.

torginus 3y ago

We are - we are in the process of transitioning our ASP.NET based backend from Windows to Linux. Linux machines are cheaper and easier to administer than Windows based ones.

ragestorm 3y ago
Same here. We are also getting some performance gains on transaction processing and system.io stuff (10% or so) compared to windows. Additionally, some of clients are linux and we have to ensure that our programs work flawlessly on it.

Decabytes 3y ago

I use .NET on Linux and the experience with Rider has been great. The workflow transfers really well between Mac, Windows, and Linux, and everything works the way you expect. The only problems I run into are that there are still things that are Windows focused. For example MAUI does not run on Linux which is a shame because we could use another cross platform GUI. There are still bugs, for example I ran into one with Polyglot Notebooks not working on Manjaro or Pop!_OS https://github.com/dotnet/interactive/issues/3159 https://github.com/dotnet/interactive/issues/3159 but hopefully that will just get better with time. I think the biggest with .NET is that it spent so long being Windows only. A lot of people just developed workflows in other languages. It also took time before .NET core, now just .NET really became first class on Linux. With .NET 8 this will get a lot better, and to my understanding will allow the popular Game Engine Godot to be able to target the web with C# builds. This will allow them to go back to having one Godot binary instead of two. The thing that has me scratching my head though is I can't believe they still don't have System.CommandLine in the standard lib. We want our cli programs please!

Rudism 3y ago

I do contract work for NASA and the main project I work on is transitioning from PostGraphile to an ASP.NET Core WebAPI (currently targeting .NET 7, but will likely look at bumping that to 8 once it's released if it's not too disruptive). I work completely in Linux, coding using Neovim, with Omnisharp for language features and code completion, and our applications are fully built and deployed using Linux containers. .NET on Linux has come a long way since the early days of Xamarin and Mono, it's quite enjoyable to use.

tester756 3y ago

I've been deploying .NET web apps for years The only problem I faced 5 years ago was that I didnt have some fonts installed for pdf generation.

SeanKilleen 3y ago

Our company's app is written in .NET 7 (soon to upgrade to .NET 8) and deployed via Linux containers into Kubernetes. It is a delightful ecosystem to work with. Productivity is huge, great tooling and IDE support even in non-MS ways. I joined this company 3 months ago and what I've been able to get done on this platform is honestly exciting. And I haven't had to sacrifice modern development principles.

moron4hire 3y ago

I've used it exclusively on my servers for the last 5 years and am now using it on my laptop. Server side, it's better than running it in Windows. I don't pay a license fee for the OS, so spinning up new VMs is super easy. And set-up, deployment, and long-term operation have all just gone off without any hitches. I've got Let's Encrypt certificates, Postgres databases, and so little overhead that I can't get by with small server SKUs. On desktop, I still use Windows at work, so I've built a WPF/WebView2 and a GTKSharp/WebKit web app shell that lets me run identical code to my server apps, just as a desktop app. It was pretty fiddly to setup (mostly because GTK is hot garbage), but now that I have it, it just works.

pliHacker2013 3y ago

I suppose it depends what you mean by linux, but if aws lambda on linux counts, then i work at a top 250 UK company who uses dotnet heavily for lambda workloads, especially async workloads. Its been great for us, no complaints. We likely would use it for our sync apis too if dotnet supported apollo federation v2, but sadly it does not.

jensneuse 3y ago
Have you seen this? https://www.apollographql.com/blog/announcement/backend/announcing-official-apollo-federation-support-for-net-with-hot-chocolate-and-federation-2/ https://www.apollographql.com/blog/announcement/backend/anno...
- pliHacker2013 3y ago
  I had not, this is great, thanks

benaadams 3y ago

41% of EVM nodes on Ethereum run .NET on Linux via Nethermind(https://github.com/NethermindEth/nethermind https://github.com/NethermindEth/nethermind). Ethereum has a Market Cap of $249Bn and $34bn of other assets in smart contracts. So you could say .NET on Linux has under management $116Bn and handles $800m of asset transfers per day, napkin math

jakubmisek 3y ago

We already had a huge C# console project originaly developed for windows/.net framework 4.5 .. .net on Linux was a zero cost transition, giving us a whole new platform, a whole new user base. It was that easy.