|
|
|
|
|
by Nullabillity
1489 days ago
|
|
.NET Core is still absolutely designed to nudge you into the MS stack. - EFCore is MSSQL first, even if other options are provided - Many libraries ship with two implementations: an over-engineered Windowsy version that barely works (with a big scary warning that it should never be used in production), and a thin wrapper around some Azure service - Important tooling like the debugger (which wouldn't be so necessary if .NET had halfway decent support for printf debugging, but here we are...) is locked to be compatible with VS and (MS' build of) VSCode, despite both of them using supposedly open (and Microsoft-pushed!) standards like DAP - The community is really culty, the response to "X is broken when using the non-MS-Stack alternative" always seems to be "well use the standard MS solution then" - It's practically open source in name only, because the build engineering is so convoluted that it's nearly impossible to find the canonical source code of core features like the standard libraries |
|
- "Many libraries ship with two implementations..." I've yet to come across these "many" libraries in the 5 years since I've been building services with .NET Core.
"The community is really culty" - I'm not sure where this is coming from. It's hard to refute such vague criticisms.
- "It's practically open source in name only" - Here is the base class library source: https://github.com/dotnet/runtime/tree/main/src/libraries or https://github.com/dotnet/corefx/releases (depending on what version you're looking for)
1. https://docs.microsoft.com/en-us/ef/core/get-started/overvie...