As the author points out, Batteries Included is a big reason I choose C# over and over again. Every time I have to go to NPM or Crates.io and look over five or more packages to solve some seemingly basic problem I get exhausted and frustrated that I'm not actually solving the problem I need to. C# has so much built in, and while there are third party options, the Microsoft way is almost always good enough.
FYI, You are comparing the modern version of DotNet (the first link) with the old legacy version (the second link).
The modern version of DotNet, "Net Core" is effectively a reboot of DotNet, with a very cross platform focus and redesigned API's based on decades of experience.
The impressive thing between .NET Framework (original .NET) and .NET now (rebooted as .NET Core but now dropped the “Core”) in that they largely foxed the API while leaving almost all of it intact.
Library code you wrote in C# 10 years before .NET Core will often just compile and run. Even more than code the resides developer learning. The plumbing between ASP.NET MVC (old) and ASP.NET Core (new) was completely and radically different. Yet writing an application in it was very much the same.
The first link appears to be for .NET Standard, which has a common API compatible with both Framework and Core.
Though it might be worth checking Github to find example usages of the APIs. Maybe there's even some libraries that improve the developer experience with cryptography.
These limitations come from cryptographic implementations provided by specific platforms, not from .NET. Can you list specific algorithms you need that are not supported?
The second article uses the wrong link too (it's for Framework, not for .NET).
As someone with no horse in this race, I must say that I'm a little disappointed in the way Linux "compatibility" deals with platform differences. Most parts of the crypto API seem to be marked as "works on Linux if/except when" which seems strange given that porting to macOS didn't seem to impose such restrictions. In some cases, the inner workings of the underlying library works differently and you get an exception when using certain functionality on Linux at all.
I though Microsoft did better porting dotnet to Linux. I knew they don't care about Linux GUI, but I hoped they'd at least do system libraries better.
This is an uncharacteristically involved type of comment for "someone with no horse in this race". It is unserious and/or malicious. I can't believe we are still having to deal with the same type of conversation 9 years later.
In case someone else is reading:
- AvaloniaUI/Uno
- Algorithms are dependent on what an OS crypto provider supports (which is OpenSSL in the case of Linux, so it's an OpenSSL issue), but you can always just use bindings to an alternative and wrap it in a stream, like some do with e.g. libsodium
- IO behaves differently because each OS has different IO implementation, .NET tries to homogenize it within reason, but there are differences that cannot be hidden, big surprise?
AvaloniaUI/Uno are both third party open source GUIs ... not by Microsoft. The Microsoft provided MAUI does NOT run on Linux (though it runs on ALL others ... android, ios, and even Mac). Not squinting on this omission and not ignoring it, sorry!
Agree on the "Algorithms are dependent on what an OS crypto provider supports" bit.
