[mdaniel]

I would find it hard to evaluate these answers without the inclusion of "upon what workstations" and "deployed via what" because if the startup requires developers to use Windows and deploys to Azure (or such), this isn't as newsworthy as heterogeneous workstations deploying on Bottlerocket/Container Optimized OS

[WorldMaker]

What does it matter if the deployment is "newsworthy" or not? "Newsworthy" doesn't mean "productive" nor does it mean "good for a startup trying to build revenue". I guess it might matter to attracting talent or investment? But productivity should still be more useful to a startup over novelty.

That said, .NET Core 1.x through .NET Core 3.x and .NET 5+ have great heterogeneous support. I've seen teams develop on Linux and deploy to a mix of "nano" containers on AWS and Azure. That "novelty" certainly exists in today's .NET.

[mdaniel]

Sorry if that word ruffled feathers, I wasn't trying to be a troll :-(

And yes, I appreciate that the marketingware for .NET claims a lot of cross platform, but from outside of that ecosystem it has been my experience that Microsoft's definition of cross platform can often be "works on Windows 10 and Server 2008" which is quite different from what normal people think of as cross platform

The mention of that "nano" containers in your response is the very risk I was trying to get at, since I have absolutely zero interest in running Windows anything in production, so it's important to be able to hear from folks who roll these out alongside their existing containerd setups

[HeyLaughingBoy]

I shipped a .NET Core product on a handful of Raspberry Pi's running whatever the current version of Debian was at the time. That's cross platform enough for me.

[mdaniel]

That's good to know, thank you. To help with the first part of my comment, upon which local system did you develop that product (and, I guess implied in that question is: was it just you, or were there other developers with their own workstation setups)?

[HeyLaughingBoy]

Visual Studio on Windows 10. I don't know why you'd use anything else for a .NET project: it's by far the path of least resistance.

I was one of 3 developers but the others were writing iOS and Android apps that interfaced with my Web product. That said, they had identical setups. Since the code was hosted locally on the Pi and we were all remote, they needed to be able to build and deploy my code also.

[WorldMaker]

Anecdotally, I've been using Visual Studio mostly regularly since the original ".NET Version" of Visual Studio (~2002), and I'm increasingly closing it and just using VS Code and the dotnet command line tools. Visual Studio is definitely starting to feel its age/weight and between all the C# 10 language features (finally) removing boilerplate (things like namespace statements and global usings), I'm often feeling more productive in VS Code than in full Visual Studio. For hobby projects I've moved entirely to VS Code even for .NET.

I'm inclined to imagine that with extensions like SSH remoting in VS Code you'd probably have a better Raspberry Pi deployment and debugging experience in VS Code than in Visual Studio, if you gave it a chance.

[WorldMaker]

I just used "nano" as a general term because I couldn't think of a better one (which does show my personal bias here more than the ecosystem's), but I was also thinking about about a lot of deployments on some sort of container optimized Alpine Linux, I forget what that was specifically called.

So far as I'm aware most of the remaining cross platform concerns in the .NET ecosystem are almost all in drawing/rendering and in cross-platform desktop UI. There's at least one MAUI fork working on a Linux renderer for MAUI UIs, but no official support like every other platform MAUI supports today (Windows, iOS, Android, Mac Catalyst). Drawing/rendering is mostly a legacy ecosystem support issue: System.Drawing API has been around a very long time and was always just a thin wrapper around Windows GDI that it had some abstraction leaks that the .NET team thought were too hard to patch and instead gave up on making System.Drawing itself cross-platform. There are multiple cross-platform replacements for System.Drawing backed by everything from Cairo to SDL to ImageMagick, but they are replacements and for the most part aren't "drop in" replacements and there's still just so many libraries (and developers) so used to System.Drawing being always available that it's still too easy in the ecosystem to stumble into a library you want to use with a hard dependency on System.Drawing.

Other than needing to watch for System.Drawing dependencies, I've got ASP.NET Core/EF web backends that build, test, run on Linux no sweat with no cross-platform issues. (Including fun things like cross-builds: a Linux CI that is also building the Windows x64 self-contained binaries for other servers. I can't think of that many cross-platform stacks where you can do that.)

I think it's still very rare to hear about cross-platform .NET not because it's uncommon (it may be much more common than anyone suspects), but just that especially to HN, .NET is still very much "dark matter". It's out there getting (boring) jobs done (in boring companies) and no one is really blogging about it or "hyping it" because no one really needs to be. That's why "newsworthy" may have touched a bit of a nerve.