Who is using .NET on Linux?
I'm interested to hear success stories.
Sounds like a a great way to build and deploy applications.
I'm interested to hear success stories.
Sounds like a a great way to build and deploy applications.
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.
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.
Is vs doing something else internally?
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.
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!
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.
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...
The experiences were night and day: while my first experience was serviceable, my most recent experience was great & comparable to the work I'm currently doing in Visual Studio 2022 & SQL Server Management Studio 2019 in Windows 10 on a Lenovo Thinkpad w/ 32GB RAM, targeting .NET 7. And the macOS laptop + multi-monitor experience on a Macbook Pro is so nice that I absolutely prefer coding on Macs now instead of Windows.
I'm actually amazed that you got away with that on an 8GB (presumably Intel) MacBook Air!! :)
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.
Are you using 3rd party extensions? ReSharper? Lots of badly written (even tiny extensions that you’d think would be basically no-ops) can make VS lock up again.
Side note, great website! It’s so rare to see such an aesthetically pleasing site on here! Do you happen to have any open source repos where you implement a lot of what you talk about? I’m interested to look under the hood at your code and your versioning system (I’m sure more, too, but I only spent 15 mins on your site so far)
Having spent the last decade or so buried deep in quite a big project, I have shamefully very little to show in terms of open source - but that will likely change quite a bit over the coming year.
I do plan to talk more on my blog about my approach to versioning and various dev/CI tooling.
Always happy to chat to like-minded people so feel free to ping me a message via my contact form if you'd like to talk more tech :) Happy to share a bit more about versioning - the approach mentioned in my article still works really well for me.
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.
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.
I have had two projects where the customer paid to rewrite their .NET Framework applications into Java, instead of the more sensible idea to migrate to .NET Core, as they saw it was more valuable to them to move completely away from Microsoft stack.
Just as a counterpoint to this, I have found Entity Framework (Core) to be an extremely nice and very productive dev experience, with a lot of constant improvements in every release. MS don't always get it right, but I definitely wouldn't call EF a "half-assed, badly run project" by a long stretch. (Though there are probably other MS projects I might be more inclined to describe as such!)
That said, they were pretty brutal in cutting off legacy support for those still using .NET Framework and trying to migrate. Through luck, I didn't have to suffer too much pain, but the migration story from .NET Framework to the new world of .NET (including EF to EF Core) has not been the smoothest for some scenarios.
If you're still using .NET Framework at this point, that's your own fault (or, more likely, your org's). They have been communicating for _YEARS_ that .NET Framework was on its way out, and provided support for .NET Standard 2.0 as a stepping stone to .NET Core & beyond (i.e. .NET 5+). There are some apps & frameworks that don't really have a modern .NET equivalent, but you won't find me shedding any tears over the lack of a direct upgrade path for Windows Communication Foundation (WCF). =P
> There’s this weird misconception in Microsoft land that if you choose .NET you must also use all MS’s half-assed libraries.
The way I see it, it's more the opposite really. People chose .NET (or more specifically C#), because, they want to use it's tooling and if you're not going to use it, then why would you pick C#? .NET on it's own is excellent, I'm not sure if I think it's as good as the JVM, but it's definitely gotten very good in the recent years, but why would you pick it if you didn't plan on using the "official" tooling?
I'm sure there are some good answers to that question. We just haven't found any.
Because it’s a great language with amazing tooling. It’s fast, robust, easy to debug, easy to refactor, and so on.
It’s also very easy to learn for novices and experienced programmers alike because it’s kind of the middle ground between many popular programming paradigms, and it has few surprising gotchas. It’s a fast way to get a heterogeneous team productive.
I agree but I also think the main issue with this is that you could've said it in reference to most programming languages in 2023. I'm sure people can have a lot of debate on that, but aside from the fast bit, most programming languages are frankly in excellent places today, and fast is sort of irrelevant for us specifically as we tend to use c/c++ for that.
Compile errors are super long lines and don’t show an excerpt of the code with underline under what went wrong with suggestions on how to fix it?
I know I’m asking a lot here, but that level is available with Rust and Elm.
I didn't particularly mind the new way project files are made up in .NET. It used to be a lot worse too. But at the same time, it can be cumbersome as you point out here and for whatever reason, it's these small annoyances that so rarely get fixed by Microsoft allowing them to pile up. I mean, I just said it used to be worse, and it really did, but then when they made it better they didn't make it great. Which is something I'll just never understand, especially because they did it recently, so it's not like they couldn't have taken inspiration from other languages and done it right.
But yes .. when you step out of the well-defined area in .net you have an "Apple moment" where trying to do something they didn't anticipate or actively dislike becomes wildly, unreasonably difficult and you get pushed down a hacking rabbithole. I'm quite proficient at MSBuild now but I shouldn't have to be.
That’s literally it: they couldn’t.
It’s hard to duplicate good effort and make it profitable. So many people make either valuable or well-made things.
Explain? This isn't an assembly line, it's not a question of scaling handmade artisanship.
You do get the same information in the IDE from intellisense.
When order of declaration matters, it ceases to be declarative. “Let there be a function” is instead “make me a function”.
It’s entirely unnecessary, and even JavaScript can let you run a function that gets declared later.
The advantage when order does not matter inside the module is that you can list big things at the top of the file and the smaller things it’s made of below, rather than opposite.
The advantage when order does not matter outside the module system is that you can have mutually recursive modules.
It's also part of the ocaml legacy (I believe file order matters in ocaml as well).
What do you mean by this?
That means Microsoft strives to provide a first-party library for every business case.
That said, you can still use ServiceStack and Newtonsoft.JSON if you wish to.
Compared to my projects that (begrudgingly) use Node.js...
still have yet to learn / try dapper
That said, ServiceStack has transitioned to payware a long, long time ago and I'm pretty sure that is what's caused its demise, not ASP.NET Web API. As a single anecdotal data point, it's definitely the reason I'm not using it.
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.
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.
// The tasks will run in parallel
var data = service.GetData(id);
var user = service.GetUser(name);
Handle(await data, await user);
The simplicity of this approach and the advantages this brings to code structuring and easy refactoring simply cannot be understated.
Task-returning method indicates an asynchronously produced (deferred/delayed) result, a promise. If a language hides this fact (that the returned value needs to be awaited), it is grossly misdesigned - at most it can offer not blocking a thread, completely missing the point and leaving 20 years of improvements other programming languages have on the table.
But it's not as bad, yet instead in many other languages you are forced to manually schedule and then block/join until all of your tasks/promises/goroutines finish. Not in C#, that makes it as easy as it gets, which you can see in my example.
On top of that, you always pay for concurrency in Go, even when you don't use it, it is by definition always "colored" which further contributes to the overhead.
Also, in my example, the tasks will run in parallel. They won't in Go.
Very hard disagree. This depends on your computing philosophy. Go was designed based on the principles of CSP in mind and that code is produced by humans for humans first. The CSP architecture has proven to work and fit well for high-concurrent middleware. Not just for Go either.
You are not forced to block until goroutines finish as you claim. You can do other work or yield to the go scheduler. All the necessary busy work is taken care of by the runtime - which is terrific for folks who don't want to fiddle with low level details.
> On top of that, you always pay for concurrency in Go, even when you don't use it, it is by definition always "colored" which further contributes to the overhead.
And that is a completely fair compromise. Supporting easy concurrency natively in the runtime was an excellent design tradeoff since the computing world is moving to more and more cores. There are fewer and fewer uses for non-concurrent software.
> Also, in my example, the tasks will run in parallel. They won't in Go.
You appear to be confusing Go with NodeJS. If you have more than one core and GOMAXPROCS > 1, the tasks can indeed run in parallel.
What would the Go code look like that achieves identical behavior to the example above (tasks are dispatched concurrently and executed in parallel)?
As a side note I really don’t think C# does parallelism better than Java.
If two callers call the same method concurrently, whether it requires any synchronization or a more advanced primitive like Channel (for which C# has well-written implementation) or nothing at all is a case-by-case choice.
Java's parallelism by definition cannot be better because they had to retrofit a green threads design onto existing ecosystem, only ever addressing the hardware thread blocking issue with all the ceremony and bloat to do the most basic actions concurrently and/or in parallel still remaining in place.
Java requires far more steps to achieve comparable behavior for what C# requires you doing nothing or a method call at most. Dispatching array elements to a consumer in parallel? call .AsParallel(), and no, Java's Stream API requires more work. Want to fire off two asynchronously completing methods? Just use the example above, neither Java nor Go can hold a candle to this. Methods are CPU-bound and blocking? Easy - just use Task.Run to achieve the same.
I’m sorry, but it’s really not the same thing. You appear very confident, and sort of rude, in your argumentation, but there is just such a huge difference between parallelism and concurrency I don’t even know where to begin. I mean, you’re talking about (a)synchronous calls, tasks, and, what not, but what you need to solve is when two thousand sensors want to update the same data through the same service all at once. And they want to do this fairly often.
In reality it’s even more complex than this because a lot of the sensors carry data on behalf of each other so often you’ll receive the same data multiple times and so on, but there isn’t much need to get into that.
But hey, you do you, if C# works for you, great.
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.
Anyway, Sonarr[1] makes use of .NET, too. Very reliable software, in my experience.
[0]: https://github.com/navidrome/navidrome [1]: https://github.com/Sonarr/Sonarr
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.
-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
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.
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.
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.
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.
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.
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 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!
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.
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
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.
Fixed.
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.
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.
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.
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.
.net on Linux was a zero cost transition, giving us a whole new platform, a whole new user base. It was that easy.
Additionally, some of clients are linux and we have to ensure that our programs work flawlessly on it.
The only problem I faced 5 years ago was that I didnt have some fonts installed for pdf generation.