Drop unsupported frameworks

[SimonCropp]

Drop

• net462
• netstandard2.0
• netcoreapp3.0
• netcoreapp2.2
• netcoreapp2.1
• net5.0
• netstandard2.1
• netcoreapp3.1

And only support

• net472+
• net6+

[AdrianJSClark]

Technically if you're looking to drop all unsupported frameworks, netcoreapp3.1 should be included as .NET Core 3.1 is out of support as of last December.

[andrewlock]

As someone who needs to support out of date framework versions, I totally get your pain, and understand the need to move forward.

However as we can't drop out of support frameworks, that gives us a hard ceiling of where we can update to, and may mean we need to fork verify longer term or look for alternatives. Not saying you shouldn't do it obviously, just our position.

That said, I think we're way behind on updates as IIRC we ran into too many breaking changes in earlier versions that couldn't be easily resolved (as dependency related) so may never make it up to date anyway 😅

[SeanKilleen]

My personal opinion, though it may be unpopular --

It is the responsibility of downstream software projects to update their frameworks if they want their software to move forward in time. Not undertaking this work is like freezing the project in time; your available options also may be frozen in time.

I think there are 3 categories/themes:

• For some projects, this time capsule is inevitable. Something ships and is considered "done". While I might disagree with that approach, the chances are that in this case the project's libraries can remain relatively the same, as not much is changing.
• For some projects, they are blocked from updating the framework due to some additional dependencies or needs that aren't met (and by this I mean "it doesn't exist" -- not "it's hard" or "it would take a long time"). I think this used to be a larger category but has since gotten much smaller. These projects are unintentionally time-capsuled, maybe through no fault of their own.
• Some projects are perfectly capable of upgrading but do not choose to value it and believe tooling should just work without them doing their part and expect maintainers to shoulder this burden.

The communication challenge comes when projects aren't clear about (or don't know) which bucket they're in.

But regardless -- in my opinion these projects are chaining themselves to a baseline that lives in the past. The implicit trade-off there, IMO, is that these projects don't also get to use the latest and greatest things from the future. I wouldn't be able to get digital audio out of an old sound blaster card; I don't get 4K video from a graphics card that is 10 years old; I don't get to take advantage of multi-threading on a single core CPU. People respect the physical limitations of hardware but don't always translate that into the world of software where it seems like anything should be possible (and is -- if maintainers wreck themselves for it.)

So in summary: do what works for you to help you be productive for those who are on the same timeline as you and not anchored to a past timeline. Maybe they'll move on from your tool, maybe they'll be upset. That's their prerogative. But I hope these points can help you frame that discussion when it comes up.

Side thought: maybe if enough OSS projects can frame the conversation this way, the ecosystem-wide message will be driven home. And for those projects truly stuck in that second box of being unable to move forward, maybe the community or MS can step in in other ways to help them with that.

[stsrki]

I would update the project to v20, as a major version, and then support only .NET 6+.

[SimonCropp]

@AdrianJSClark

Technically if you're looking to drop all unsupported frameworks, netcoreapp3.1

while i would like to. i think some period of grace is fair

[SimonCropp]

@andrewlock

may mean we need to fork verify longer term or look for alternatives

I would really prefer no one need to do this

That said, I think we're way behind on updates as IIRC we ran into too many breaking changes in earlier versions that couldn't be easily resolved (as dependency related) so may never make it up to date anyway

are there any breaking change i need to do a better job of explaining? or writing better upgrade guides? do u need help upgrading? we could jump on a call, or if u need some more dedicated time, i could do a short term contract to do the upgrade for you.

However as we can't drop out of support frameworks,

• What "out of support frameworks" do you target?
• If u target net46x what is stopping u from updating to net472?
• If u target netcore2 what is stopping you from updating to netcore3.1?
• If u target net5 what is stopping you from updating to net6?
• Do u have a timeline for moving off any of those unsupported frameworks?

[SimonCropp]

@stsrki

I would update the project to v20, as a major version, and then support only .NET 6+.

as much as i would like to, i think it is a bit soon. I even work on a project that cant move off net48 because it targets on prem sharepoint

[AdrianJSClark]

@SimonCropp wrote:

while i would like to. i think some period of grace is fair

That's 100% fair. I was being a bit pedantic is all.

[distantcam]

FWIW roslyn libraries (analyzers, source generators etc) are told to use NetStandard 2.0 (https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview#get-started-with-source-generators for example)

This doesn't really affect the test libraries, as they can still be on current frameworks, but still, it's an odd case where MS still recommends using an old target framework.

[bruno-garcia]

This would be bad news for Sentry which has the philosophy 'compatibility is king'. So far we managed to build (since 2018) with net461 and ns2.0 as a baseline, while adding new things. Verify was added (thanks for the contribution Simon) but we certainly can't drop all unsupported tfs because of it. Hope you can consider keeping them for longer.

[AdrianJSClark]

FWIW roslyn libraries (analyzers, source generators etc) are told to use NetStandard 2.0 (https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview#get-started-with-source-generators for example)

This doesn't really affect the test libraries, as they can still be on current frameworks, but still, it's an odd case where MS still recommends using an old target framework.

I think that the reason that netstandard2.0 is recommended is because that's the most recent NetStandard version which .NET Framework 4.7.2 supports and it is still very much a supported framework.

[SimonCropp]

@bruno-garcia

net461 and ns2.0 as a baseline

but do you use Verify with either of those targets?

[duncand]

I have several semi-alternative suggestions:

1. If you're going to support netstandard anything, make it 2.0, because 2.0 is the latest one that's truly significant, because it supports both Framework and Core, while 2.1 does not. I see no good reason for anything to target netstandard at all unless its in order to support Framework plus Core. If you're going to drop Framework support then you might as well just require a net6 minimum instead.

2. Your best option may be to have multiple branches, where the mainline branch has very aggressive requirements, specifically net6+ period and doesn't support anything else, and a legacy LTS branch is just your current version without dropping support for anything you listed, and that branch becomes semi-frozen, getting only critical security and bug fix updates; other stuff only if someone who needs that bankrolls the back-porting of other features.

[SimonCropp]

@duncand

see no good reason for anything to target netstandard at all unless its in order to support Framework plus Core.

netstandard2.1 give us Xamarin and unity support

Your best option may be to have multiple branches...

this sounds like too much work. people on the legacy branch will always want all bug fixes and features. and as soon as u start using new language features and APIs in the mainline branch, porting those changes back to the legacy branch is essentially coding them twice. ie u will rarely be able to make use of pulling commits from mainline to legacy

but i am more interested in if you target any of the legacy frameworks that are being planned to be dropped

[duncand]

@duncand

Your best option may be to have multiple branches...

this sounds like too much work. people on the legacy branch will always want all bug fixes and features. and as soon as u start using new language features and APIs in the mainline branch, porting those changes back to the legacy branch is essentially coding them twice. ie u will rarely be able to make use of pulling commits from mainline to legacy

The whole point of having multiple branches is saying no to porting features, meaning almost all further work would happen on the mainline supporting net6+ only, and only the relatively small and less frequent security/bug fixes are back ported.

If consuming projects are stuck on older frameworks then that generally means they are in maintenance mode and their users just need something to keep working the same as before, and just need security fixes. If they are not going to update their frameworks then why would they substantially need to update anything else, besides for security?

So my suggestion minimizes how much actual work you have to do while letting you keep moving forward, and without abandoning any current users on older frameworks who need this to just keep working as well as before and securely.

[duncand]

@duncand
but i am more interested in if you target any of the legacy frameworks that are being planned to be dropped

Speaking for myself personally, all .NET projects I create or maintain these days, which are relatively new, use only net6+, which is the best for combining the maximum feature set with cross-platform portability.

[andrewlock]

may mean we need to fork verify longer term or look for alternatives

I would really prefer no one need to do this

Me too, obviously! 😄

That said, I think we're way behind on updates as IIRC we ran into too many breaking changes in earlier versions that couldn't be easily resolved (as dependency related) so may never make it up to date anyway

are there any breaking change i need to do a better job of explaining? or writing better upgrade guides? do u need help upgrading? we could jump on a call, or if u need some more dedicated time, i could do a short term contract to do the upgrade for you.

I must have been mis-remembering the issue. I thought that you updated a reference to one of the Microsoft.Extensions.* libraries, which caused us issues for multi-targeting. But AFAICT there is no such dependency. There has been no push to look into upgrading since, because Verify works so well! (Thank you 🙏)

However as we can't drop out of support frameworks,

• What "out of support frameworks" do you target?
• If u target net46x what is stopping u from updating to net472?
• If u target netcore2 what is stopping you from updating to netcore3.1?
• If u target net5 what is stopping you from updating to net6?
• Do u have a timeline for moving off any of those unsupported frameworks?

The trouble is, we (Datadog .NET Tracer team) produce a library that our customers consume. That means we can only upgrade as fast as they do.

• .NET 461
• .NET Standard 2.0 (for .NET Core 2.0 support)
• .NET Core 3.1
• .NET 6

We obviously also need to test against those frameworks (we actually test net462, netcoreapp2.0, netcoreapp2.1, netcoreapp3.0, netcoreapp3.1, net5.0, net6.0, net7.0).

Obviously, we are a special case in many ways (sounds like Sentry may be similar) so I totally understand that you can't keep the ancient stuff around forever. It just means we'll either need to stick to old versions, which is fine generally IMO. The issue comes if we run into a bug we can't workaround. At that point we'd have to look into forking/alternatives.

To be clear, I'm very much not suggesting you should keep support for older versions. I think it's actually libraries like Verify that have the power to drive the ecosystem forward as you can potentially force the laggards forward. And there's certainly precedent with how aggressively Microsoft are dropping older TFMs in their newer NuGet packages. Just know that "library vendors" don't fall neatly into the categories that Sean outlined - our customers do, but we can't upgrade even though we would love to.

[duncand]

The trouble is, we (Datadog .NET Tracer team) produce a library that our customers consume. That means we can only upgrade as fast as they do.

• .NET 461
• .NET Standard 2.0 (for .NET Core 2.0 support)
• .NET Core 3.1
• .NET 6

We obviously also need to test against those frameworks (we actually test net462, netcoreapp2.0, netcoreapp2.1, netcoreapp3.0, netcoreapp3.1, net5.0, net6.0, net7.0).

Obviously, we are a special case in many ways (sounds like Sentry may be similar) so I totally understand that you can't keep the ancient stuff around forever. It just means we'll either need to stick to old versions, which is fine generally IMO. The issue comes if we run into a bug we can't workaround. At that point we'd have to look into forking/alternatives.

The suggestion I made before I can make to any library vendor, which is branch your library. The consumers who want most of the latest features update to net6+, and those who don't want to update can get an LTS branch which has the backwards compatibility and has updates limited to security fixes.

I am also a library vendor, but because it is new libraries I am starting with net6+ as the base requirement, assuming that the majority of the time anyone who would adopt these new libraries would do so in a project that is either new or that has been uplifted to net6. And if I decided there was the market for supporting older .NET versions, I would do so as a second parallel version while keeping the mainline requiring relatively new .NET versions. I feel this is the best way for me to keep up to date and have older system support, which is exactly 2 and not more parallel versions optimized for those use cases.

[SimonCropp]

Ok. given the feedback in this issue (and directly to me), i am going to put this on hold for 6 months and then revisit.

Thank you everyone for the feedback

[mattjohnsonpint]

@bruno-garcia - Sentry wouldn't be impacted by this change. It doesn't affect which frameworks Sentry can use. But rather it only affects which frameworks Sentry's test projects can target - which currently are net48, netcoreapp3.1, net6.0 and net7.0. Verify could target only netstandard2.0 and Sentry would be fine. We'd also be fine with netstandard2.1;net48 (or any lower version of .NET Framework).

Also, just a note about running tests on .NET Framework targets - the target version actually only controls the SDK that's used to compile the test app - not the runtime that the tests run under. For example, if you make a test project targeting net461, and you run that test on any recent version of Windows (May 2019+), it will use the .NET Framework 4.8 runtime. You would need an older version of Windows to actually test on an older .NET runtime.

Similarly on Mac and Linux, it doesn't matter what framework version you target, the tests will run on whatever version of the Mono runtime installed on the machine.

In other words, just because a library targets net461 doesn't mean its test projects also have to target net461. Doing so only tests that the library can be installed into a .NET 4.6.1 app - it doesn't actually run the tests on the .NET 4.6.1 runtime.

Contrast that with .NET Core and modern .NET. If you build a test project targeting netcoreapp3.1;net6.0;net7.0 and you've only installed the .NET 7 SDK - the entire app will compile, but you'll get a runtime error when trying to run the tests, because no runtimes are installed for the lower targets. It doesn't automatically upgrade to use the .NET 7 runtime. So conversely, if you do have those runtimes installed, then you are assured you are testing on the versions you're targeting.

This is why with Sentry, we're testing net48;netcoreapp3.1;net6.0;net7.0. There's no point in testing older .NET Framework, even though the library targets it.

[mattjohnsonpint]

The more interesting discussion IMHO is netcoreapp3.1 and net5.0. Both are out of support from Microsoft, but I suspect that netcoreapp3.1 is worth testing on for some time longer, given that it was an LTS release. But not necessarily the same for net5.0, since it was never LTS.

[SimonCropp]

@mattjohnsonpint yeah i left netcoreapp3.1 in there for that reason. i removed net5.0 since moving to net6 is pretty trivial

[SimonCropp]

@andrewlock

Also, just a note about running tests on .NET Framework targets - the target version actually only controls the SDK that's used to compile the test app - not the runtime that the tests run under. For example, if you make a test project targeting net461, and you run that test on any recent version of Windows (May 2019+), it will use the .NET Framework 4.8 runtime. You would need an older version of Windows to actually test on an older .NET runtime.

#784 (comment)

so this is the approach you are using to test on .NET 461?

[andrewlock]

so this is the approach you are using to test on .NET 461?

Yeah exactly. We're targeting net462 in the tests, but we're (mostly) running against net48 (as that's what's installed in the CI machines)

[Aaronontheweb]

.NET Standard 2.0 is still pretty widely used - we use Verify in several Akka.NET projects that target .NET Standard 2.0. We're trying to work on dropping .NET Standard 2.0 support ourselves but it's taking a while to get our enterprise users to make the jump with us without a sufficiently large carrot on the end of the stick.

[mattjohnsonpint]

@Aaronontheweb - Sure, but only the targets used by the test projects are relevant here.

From Akka.API.Tests.csproj:

<PropertyGroup>
  <TargetFrameworks>$(NetFrameworkTestVersion);$(NetTestVersion);$(NetCoreTestVersion)</TargetFrameworks>
</PropertyGroup>

From common.props:

<NetCoreTestVersion>netcoreapp3.1</NetCoreTestVersion>
<NetTestVersion>net7.0</NetTestVersion>
<NetFrameworkTestVersion>net471</NetFrameworkTestVersion>

So Verify could either target only netstandard2.0 or it could target netstandard2.1;net471 and Akka would be ok, right?

[SimonCropp]

@Aaronontheweb yeah i have already decided to put this on hold for for at least 6 months. i added an "Update" to the issue to clarify for the next person.

but i think @mattjohnsonpint makes a valid point. although it is technically possible to "run only on netstandard" (i learned this last week), i dont think anyone does this. so in this context, only the top level targets u use for testing are relevant? or am i missing something?

[andrewlock]

Note that when you wrote that post, dotnet/runtime packages emitted an error instead of a warning, which changed since then.

It's true, it's definitely better, I just still don't like it 😉 IMO if your package doesn't "support" netstandard2.0, it shouldn't target netstandard2.0. I realise there's subtelties, and this is as much a NuGet issue, but IMO it just makes an (already complex) thing even harder for anyone to understand.

do you see an alternative to my above proposal that mitigates your concerns and makes it possible for @SimonCropp to drop EOL frameworks?

In terms of "my concerns", if you're referring to my initial comment, then no, there's no solution, as I need to support EOL frameworks, so there's no solution forward there for me.

If you're referring to the issue of netstandard2.0 implying support for EOL frameworks, then IMO, the solution is to specifically target the supported frameworks instead of netstandard. i.e. drop netstandard from the original list (as that's covered by netcoreapp3.1) and add the appropriate xamarin etc targets if that's what we want. That seems feasible for this library (I know you have analyzer issues doing the same in the runtime). But at this point, are there _any_ non-EOL TFMs that support netstandard2.0but _not_netstandard2.1`?

[ViktorHofer]

If you're referring to the issue of netstandard2.0 implying support for EOL frameworks

Sorry for my ambiguous question. I meant the latter, yes.

If you're referring to the issue of netstandard2.0 implying support for EOL frameworks, then IMO, the solution is to specifically target the supported frameworks instead of netstandard. i.e. drop netstandard from the original list

By doing that, component authors would lock out customers that target netstandard2.0 but then run on a supported runtime. netstandard2.0 is one of the most popular target frameworks as it supports both .NET Framework and modern .NET and offers a large API set. By dropping support for targeting netstandard2.0 we would disrupt the entire .NET ecosystem. We talked about this internally (in the .NET team) and agreed upon that we aren't even near the point where dropping netstandard2.0 is appropriate.

[mattjohnsonpint]

I wonder if anyone has proposed new TFMs to address this? Something like netstandard2.0-minsupported or netstandard2.0-net462min-net6.0min etc.

[mattjohnsonpint]

@mattjohnsonpint can u comment on how many of you clients are still on unsupported frameworks?

For business reasons, I can't release exact counts. However, I can release percentages:

That reflects the runtime version of events we've received from our customers over the last 3 months. For .NET Framework, the version is the installed runtime where the app is executing, not the target version used at compile time. Likewise, I can't tell you how many of those are targeting .NET Standard.

We'd have to collect values from TargetFrameworkAttribute to get the exact target versions, which we don't currently.

The chart on the right is classifying .NET 6, 7, 8 and .NET Framework 4.6.2+ as supported, and everything else as unsupported.

[mattjohnsonpint]

FYI, there's a few errors in that data I need to clean up.

Also it does get better over time if I break it down version by version of our library. As we get to newer versions of our library, we find those that are on unsupported drops considerably.

Specifically, I find that if I look at all versions, we have about 30% unsupported runtimes still in use. But remove versions of our library over a year old, it drops to about 16% on unsupported runtimes. If I go even further and remove versions more than 3 months old, it drops to 10%. I take away from this that those who choose to upgrade regularly, tend to stay on supported runtimes also. Those who choose to run on unsupported runtimes tend to be the same who don't update their libraries regularly anyway.

I need to write a blog post to cover all the data and interpretation. There's too much to just dump it here. 😅

[SimonCropp]

note that xunit.runner.visualstudio has dropped netcore3.1 support. moving to a min of net6

[ViktorHofer]

@SimonCropp do you have an update to share around the TFM deprecation plan for Verify? Just curious what your current thinking is on that.

[SimonCropp]

@ViktorHofer my current plan it re-evaluate in Jan 2024.

[Tyrrrz]

In my case, tests are always running against the latest version of .NET (7.0 as of today) except a few projects where I test against legacy .NET Fx as well (usually when there's a lot of complex polyfilling in the project). So for me, and I imagine many other people, legacy .NET Fx is the primary anchor. I don't care about .NET Standard or older versions of .NET Core.

That said, if libraries start a trend of dropping .NET Fx support completely, I will drop it from my libraries too, because the only reason I have it in the first place is because the effort it takes to maintain those targets is not too high currently. If I have to start pinning dependencies, I'd just drop .NET Fx support instead. I long for the day where we can all forget .NET Fx ever existed.

[SimonCropp]

@andrewlock @bruno-garcia @ViktorHofer any chance of Datadog, Sentry, or Microsoft sponsoring Verify?

[Kielek]

@SimonCropp do you see any chance to revisit set of supported .NET Framework versions? .NET Framework 4.6.2 will be supported till Jan 12,2027.

It is the version supported also by OpenTelemetry (Automatic Instrumentation). The agreement on OTel side was to support all versions supported by Microsoft.

Sorry for reopening topic post/merge release, but it was detected yesterday after debendabot opened this PR.

[SimonCropp]

@Kielek what is stopping you from updating to net472?

[Kielek]

OTel AutoInstrumentation can be used without code/build changes. It can be injected to .NET (Framework) process by env. variables.
Our goal is to support the broadest possible set of applications to make DevOps scenarios more user friendly.

What is more OTel .NET SDK/API is also supporting all officially supported .NET versions.
I do not see any good reason to narrow this for now. We have end-users reporting issues related to this version. Few examples:

• Enable Logging for .NET Framework applications open-telemetry/opentelemetry-dotnet-instrumentation#2310
• netfx assembly System.Net.Http.dll is not redirected to version 4.2.0.0 open-telemetry/opentelemetry-dotnet-instrumentation#2400
• ASP.NET intrumentation failed on .NET framework open-telemetry/opentelemetry-dotnet-instrumentation#2833
• Manual Traces no longer working in 1.0.0-rc1 open-telemetry/opentelemetry-dotnet-instrumentation#2780

[ViktorHofer]

Note that xunit will only support net472 and above as well: https://xunit.net/docs/v3-alpha. There are reasons why people drop support for older .NET Framework versions, even if they are officially still in support. I.e. issues with .NET Standard compatibility, limited API set, etc.

[SimonCropp]

@Kielek regarding the point by @ViktorHofer will you be moving off xunit when it drops net462?

[Kielek]

I do not have a clear answer for this. It depends on timeline of releasing xunit.v3 (based on what I see, it is in alpha stage). If drop support for net462 became a fact before official MS EOL we will probably stick with 2.* version.

We will do the same probably with Verify, as long as there will be no information about security issues in dependencies/Verify itself.

[SimonCropp]

@Kielek would splunk consider consider supporting financially? so it is worth my time to keep net462 ?

[ViktorHofer]

@ViktorHofer any chance of Microsoft sponsoring Verify?

Unfortunately, I can't speak to that. We do have the FOSS program. Microsoft employees select open source projects to sponsor. Aside from, I don't know about other potentials. cc @jeffwilcox

[Kielek]

@Kielek would splunk consider consider supporting financially? so it is worth my time to keep net462 ?

@SimonCropp, I am not in the position to make a response in the name of Splunk.
My perspective is that OpenTelemetry is fully open sourced project. Contributors to this project are from corporate developers, fully or partially dedicated to the OTel but also done on private time, which means no financial support for such contributors.

Your support by bringing back .NET Fx 4.6.2 support is to support open source project, not the particular corporate.

I can help you with creating PR which brings back support for .NET Framework 4.6.2.

[SimonCropp]

@Kielek given net462 was released in 2016, i think 7 years is enough time to expect people to upgrade. if OpenTelemetry is fully OSS, and has no monetary incentive, i suggest you also drop support for anything below net48

[bruno-garcia]

@andrewlock @bruno-garcia @ViktorHofer any chance of Datadog, Sentry, or Microsoft sponsoring Verify?

I nominated Verify and Polyfil, looks like it went through:

Not sure about the amounts, Sentry I believe the blog post announcing this years sponsorship program is in the works.

Btw sorry for the late replies, I skim GH notifications every few months these days

[bruno-garcia]

Sponsorship program isn't done yet, it's tracked here: getsentry/team-ospo#108

[SimonCropp]

@bruno-garcia thanks