Curious why drop netstandard #3341
-
I am evaluating paths forward for data and serialization layers, and As a subscriber, consumer of such packages, I do not generally like to up-lift such components from API surface areas to specific runtimes until the very last possibly moment when it should become more opinionated, such as toward the more user facing layers, UI, web, and so on. I consider |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
.NET Standard was dropped as Marten already didn't run on .NET Framework in v5.0 so there was no benefit in supporting it (.NET Framework support was dropped with v4). There's no point spamming the codebase with preprocessor directives and an extra build/test matrix to "support" .NET Standard if the library doesn't run on anything apart from modern .NET targets. In the same way, you as a user should not be writing libraries that target .NET Standard if they're not going to be shared across .NET Framework/Core, it's shooting yourself in the foot for no benefit. Our support policy is whatever version of (Modern) .NET Microsoft supports and the target framework enforces that. This is also in alignment with Microsoft's own advice:
|
Beta Was this translation helpful? Give feedback.
-
Good to know, I wondered about that as I was somewhat privy to the stand up at the time, personally asked the direct question, which PM response hinting in that direction but not explicitly saying so. At any rate thanks for the background. Cheers 🍻 |
Beta Was this translation helpful? Give feedback.
.NET Standard was dropped as Marten already didn't run on .NET Framework in v5.0 so there was no benefit in supporting it (.NET Framework support was dropped with v4). There's no point spamming the codebase with preprocessor directives and an extra build/test matrix to "support" .NET Standard if the library doesn't run on anything apart from modern .NET targets.
In the same way, you as a user should not be writing libraries that target .NET Standard if they're not going to be shared across .NET Framework/Core, it's shooting yourself in the foot for no benefit.
Our support policy is whatever version of (Modern) .NET Microsoft supports and the target framework enforces that. This is also in…