Should we drop netstandard20 support in v11

[iancooper]

There are a lot of niggles around our continued support for netstandard20. To name the most painful of them:

• Poorer support for language features such as nullable or missing support for other features or libs (Timers etc.)
• Lack of EF support for netstandard20 (we multi-target, but to deprecated packages)

Now we could work around this. We could use polyfils to fix the missing language features, and we could just drop support gradually, as an assemblies dependencies drop netstandard20, we follow along. That might allow us to keep the core on netstandard20 longer.

But the real question here is: is it worth it?

• Should we just drop netstandard20 support in V10.

Do we exist in scenarios where the folks who use us need netstandard, and if they do, could persist on v9

[SteveBush]

I'm using Brighter and Darker to build a distributed, consumer application that discovers and manages devices and services on a home network. My shared libraries target .NET 9.0, .NET 6.0, and .NET Standard 2.0. My mobile application targets net9.0 for IOS, Android, WinUI and MacCatalyst. My Windows desktop application targets NET 4.72 to enable support on Windows 7 SP1.

I'm not your typical consumer, so I fully understand if you don't want to do the extra work to maintain support for netstandard2.0.

My feedback would be to follow the xUnit versioning model for packages (see https://xunit.net/docs/getting-started/v3/migration#migrating-to-v3-packages). The xunit.v3 namespace and packages are for the version 3 rewrite. I think the Brighter codebase has evolved similarly to xunit from v9 to v10.

For reference, the minimum requirements for the xunit.v3 runtime and framework libraries are below.

Minimum runtime requirements for xunit.v3:

- .NET Framework 4.7.2 (or later)
- .NET 6 (or later)

Target frameworks for xunit.v3 core libraries:

- .NET Standard 2.0 (netstandard2.0)
- .NET 6 (net6.0)

My feedback would be to move Brighter 10.X to packages ending in *.v10 to handle the divergence of v9 and v10 features. I would also keep the existing target frameworks listed below. However, I do understand that I'm not the typical use case and it may be a lot or work or hinder feature development.

    <BrighterTargetFrameworks>netstandard2.0;net8.0;net9.0</BrighterTargetFrameworks>
    <BrighterFrameworkAndCoreTargetFrameworks>net462;net8.0;net9.0</BrighterFrameworkAndCoreTargetFrameworks>
    <BrighterCoreTargetFrameworks>net8.0;net9.0</BrighterCoreTargetFrameworks>

Scenarios:
I use Brighter as the core messaging framework to handle device and service discovery. For example, I have entities for hosts, devices, services, and network addresses, as well as an entity database that maintains a network graph.

For example, resolving a host (foo.local) to a collection of network addresses involves a DNS resolver handler and/or a MulticastDNS resolver handler, and results in a HostEntity, NetworkAddress entities, a DiscoveredHost event, and the network graph being updated. Queries are against the NetworkGraph using Darker. I use the command pipeline to process discovered network devices and services.

I'm also writing a custom messaging gateway that forwards secure, encrypted messages to instances of my application on other devices. The messages distribute the discovered device and service information and trigger remote discovery commands (discover music library, photo library, etc.).

Thanks for listening.

[iancooper]

Hi @SteveBush

Thanks for taking the time to write this. It is well thought out feedback. We are always grateful to receive that.

I will ponder and discuss a little before replying. It does make a difference to us to know that we have folks who want to consume nestandard20, as it shifts the balance on it being worth the effort. Especially if you tell us, as you probably represent some folks who are not.

So, thanks, we hear you, and will respond soon.

[iancooper]

BTW, @SteveBush V10 will continue to have netstandard20 support. Our current discussion is about V11 support, which will probably be 12-18 months after V10, which should be in the next few months.

The XUnit versioning strategy is worth noting, so thank you.

[SteveBush]

Great, thanks. The discussion title confused me, as I initially thought you were planning to drop support for netstandard2.0 in v10 before public release. As a consumer of xunit, the packaging strategy of using package.version worked well for me. It made the migration from the v2 codebase to v3 explicit, caused me to refactor some code to take advantage of new features, but it forced a major version change of my own. It was painful for a couple of days as I had to get my testing infrastructure migrated but I feel like I'm in a better place by going through the refactoring.

[iancooper]

Yes, now I read it back, there is a lot of ambiguity there.

[PleasantD]

Our internal libraries are moving toward cross compiling for .NET Framework 4.8 and .NET 9
This allows us to maintain backwards compatibility with framework features (such as the static config manager and config sections) and implement newer .NET support.

Support packages, such as Polyfill can help with supporting many new language features in the Framework build, and compile switches can provide ways to supply new API or implementations where only new .NET support is available (like async disposable, etc.)

IMO, .NET Standard is an obsolete way to support multiple target frameworks and only hobbles the ability to improve the code.
In most cases where you have control over the targets for your projects and you are the only consumer of them then you should have very few reasons to still be targeting .NET Standard in any of your projects.

However, as a publicly available library, I can see including .NET Standard as a support framework for any legacy users who are not capable/willing to drop the .NET Standard target.

[SteveBush]

In my experience,you either control your environment or must deploy in an environment you don't fully control. In the former, you can code to latest platform. In the later, you need to pick a development strategy and platform that balances compatibility, performance, and features. If you're developing a shared library you spend a bunch of cycles thinking about the trade offs of development complexity, features, and platform support.

For me, I am developing a consumer app that works on Windows, macOS, iOS, and Android. I want broad reach on Windows so I have a multi-platform build that targets netstandard2.0 for shared libraries, net4.72 for WPF, net8.0, and net9.0.

I often have to code extensions for netstandard2.0 to implement missing features or pick a different API with cross platform support.

I justify the overhead with increasing the reach of my app because as my customer choses where to deploy.

So, my view is shared libraries should figure out the right balance between reach, development complexity, and features.

I think xunit has done a good job with this in moving from v2 to v3.

[iancooper]

I think that the question for us is the "unknown" about what our consumers need. Supporting netstandard20 has pain points, but it does allow us the broadest reach of "backwards compatibility." There might be a point where we could assume .NET Framework 4.8, but I'm not sure if we've reached it yet.

My main concern about nestandard are package warnings and language limitations.