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, a

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.