[
https://issues.apache.org/jira/browse/THRIFT-6202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18113044#comment-18113044
]
Jens Geyer edited comment on THRIFT-6202 at 9/8/26 10:55 PM:
-------------------------------------------------------------
Replacing my earlier one-word rejection with the reasoning that should have
gone with it. The concern behind it was breaking .NET Framework consumers;
checked against the published packages, that concern does not hold.
h3. Consumers of the core library on .NET Framework are unaffected
The dependency runs one way only: {{ApacheThrift.AspNetCore}} ->
{{ApacheThrift}}, never the reverse. The published 0.24.0 nuspec for
{{ApacheThrift}} confirms that its {{netstandard2.0}} group carries no ASP.NET
Core dependency at all:
{noformat}
ApacheThrift 0.24.0, .NETStandard2.0 dependency group:
Microsoft.Extensions.Logging.Abstractions
System.IO.Pipes.AccessControl
System.Net.Http.WinHttpHandler
{noformat}
A net472/net48 application using sockets, named pipes, {{THttpClientTransport}}
or the async servers therefore keeps resolving the core {{netstandard2.0}}
asset and is untouched by this change. Nothing reaches it transitively.
The only scenario actually removed is a .NET Framework application that hosts
ASP.NET Core 2.x middleware and uses {{THttpServerTransport}}:
* ASP.NET Core 3.0 dropped .NET Framework, so such an application is pinned at
ASP.NET Core 2.1, whose runtime reached end of life on 2021-08-21; the extended
servicing window for running those packages on .NET Framework has since closed
as well.
* Classic ASP.NET was never a consumer in the first place:
{{THttpServerTransport.Invoke()}} takes a
{{Microsoft.AspNetCore.Http.HttpContext}} and a {{RequestDelegate}}, not a
{{System.Web.HttpContext}}. Web Forms, MVC 5 and Web API 2 applications could
never use the class.
* {{netstandard2.1}} is irrelevant to the question by definition - .NET
Framework tops out at {{netstandard2.0}} and can never load a 2.1 asset.
h3. The impact that is worth recording
Dropping {{netstandard2.1}} also removes the fallback asset for
{{netcoreapp3.1}}, {{net5.0}}, {{net6.0}} and {{net7.0}} consumers, which will
get {{NU1202}} at restore time. All of those are out of support (net7.0 on
2024-05-14, net6.0 on 2024-11-12), and they were resolving to an asset that
pulls the standalone ASP.NET Core 2.x packages into an application whose shared
framework already provides them - so removing it is arguably a correctness
improvement too. Still, a stranded {{net6.0}} consumer is a good deal more
likely than a stranded ASP.NET-Core-2.1-on-.NET-Framework one, so that is the
breaking surface worth naming.
{{ApacheThrift.AspNetCore}} 0.24.0 is already on nuget.org carrying both the
{{netstandard2.0}} and {{netstandard2.1}} assets, so this is a genuine breaking
change rather than a no-op, and it should show up in the 0.25.0 release notes.
h3. On the wording in the description
"legacy standalone packages" understates it slightly:
{{Microsoft.AspNetCore.Http.Abstractions}} 2.3.x is still actively serviced -
2.3.13 was published on 2026-09-08, after 2.3.12 (2026-08-11) and 2.3.11
(2026-06-09), the latter being what we currently pin. That is arguably the
stronger argument for the change: keeping the {{netstandard}} leg means chasing
a roughly monthly patch cadence for a target that nothing in the repository
builds or tests against - {{tutorial/netstd/Server}} and {{test/netstd}} are
{{net10.0}} only.
_Drafted with AI assistance (Claude Opus 5); reviewed and posted by Jens Geyer._
was (Author: jensg):
Replacing my earlier one-word rejection with the reasoning that should have
gone with it.
The concern behind it was breaking .NET Framework consumers; checked against
the published
packages, that concern does not hold.
h3. Consumers of the core library on .NET Framework are unaffected
The dependency runs one way only: {{ApacheThrift.AspNetCore}} ->
{{ApacheThrift}}, never
the reverse. The published 0.24.0 nuspec for {{ApacheThrift}} confirms that its
{{netstandard2.0}} group carries no ASP.NET Core dependency at all:
{noformat}
ApacheThrift 0.24.0, .NETStandard2.0 dependency group:
Microsoft.Extensions.Logging.Abstractions
System.IO.Pipes.AccessControl
System.Net.Http.WinHttpHandler
{noformat}
A net472/net48 application using sockets, named pipes, {{THttpClientTransport}}
or the
async servers therefore keeps resolving the core {{netstandard2.0}} asset and
is untouched
by this change. Nothing reaches it transitively.
The only scenario actually removed is a .NET Framework application that hosts
ASP.NET Core
2.x middleware and uses {{THttpServerTransport}}:
* ASP.NET Core 3.0 dropped .NET Framework, so such an application is pinned at
ASP.NET Core 2.1, whose runtime reached end of life on 2021-08-21; the extended
servicing window for running those packages on .NET Framework has since closed
as well.
* Classic ASP.NET was never a consumer in the first place:
{{THttpServerTransport.Invoke()}} takes a
{{Microsoft.AspNetCore.Http.HttpContext}} and a {{RequestDelegate}}, not a
{{System.Web.HttpContext}}. Web Forms, MVC 5 and Web API 2 applications could
never use the class.
* {{netstandard2.1}} is irrelevant to the question by definition - .NET
Framework tops out at {{netstandard2.0}} and can never load a 2.1 asset.
h3. The impact that is worth recording
Dropping {{netstandard2.1}} also removes the fallback asset for
{{netcoreapp3.1}},
{{net5.0}}, {{net6.0}} and {{net7.0}} consumers, which will get {{NU1202}} at
restore time.
All of those are out of support (net7.0 on 2024-05-14, net6.0 on 2024-11-12),
and they were
resolving to an asset that pulls the standalone ASP.NET Core 2.x packages into
an
application whose shared framework already provides them - so removing it is
arguably a
correctness improvement too. Still, a stranded {{net6.0}} consumer is a good
deal more
likely than a stranded ASP.NET-Core-2.1-on-.NET-Framework one, so that is the
breaking
surface worth naming.
{{ApacheThrift.AspNetCore}} 0.24.0 is already on nuget.org carrying both the
{{netstandard2.0}} and {{netstandard2.1}} assets, so this is a genuine breaking
change
rather than a no-op, and it should show up in the 0.25.0 release notes.
h3. On the wording in the description
"legacy standalone packages" understates it slightly:
{{Microsoft.AspNetCore.Http.Abstractions}} 2.3.x is still actively serviced -
2.3.13 was
published on 2026-09-08, after 2.3.12 (2026-08-11) and 2.3.11 (2026-06-09), the
latter
being what we currently pin. That is arguably the stronger argument for the
change:
keeping the {{netstandard}} leg means chasing a roughly monthly patch cadence
for a target
that nothing in the repository builds or tests against -
{{tutorial/netstd/Server}} and
{{test/netstd}} are {{net10.0}} only.
_Drafted with AI assistance (Claude Opus 5); reviewed and posted by Jens Geyer._
> Drop netstandard2.0 and netstandard2.1 targets from ApacheThrift.AspNetCore
> ---------------------------------------------------------------------------
>
> Key: THRIFT-6202
> URL: https://issues.apache.org/jira/browse/THRIFT-6202
> Project: Thrift
> Issue Type: Improvement
> Components: netstd - Library
> Reporter: Sylwester Lachiewicz
> Assignee: Jens Geyer
> Priority: Minor
>
> With THRIFT-4534, the ASP.NET Core HTTP server transport was moved into a
> separate package (`ApacheThrift.AspNetCore`).
> Currently, `ApacheThrift.AspNetCore` targets
> `netstandard2.1;netstandard2.0;net8.0;net9.0;net10.0`.
> Because Microsoft discontinued ASP.NET Core support on .NET Standard after
> 2.x (moving ASP.NET Core into the `Microsoft.AspNetCore.App` shared framework
> in .NET Core 3.0+), supporting `netstandard2.0` and `netstandard2.1` forces
> `ApacheThrift.AspNetCore` to reference legacy standalone packages
> (`Microsoft.AspNetCore.Http.Abstractions`). Furthermore, .NET Core 2.1 (the
> last runtime hosting ASP.NET Core via .NET Standard) reached End-of-Life in
> August 2021.
> Dropping `netstandard2.0` and `netstandard2.1` from `ApacheThrift.AspNetCore`
> will:
> 1. Limit `ApacheThrift.AspNetCore` to actively supported .NET runtimes
> (`net8.0`, `net9.0`, `net10.0`), referencing `<FrameworkReference
> Include="Microsoft.AspNetCore.App" />`.
> 2. Completely eliminate the dependency on
> `Microsoft.AspNetCore.Http.Abstractions` across the repository.
> 3. Simplify multi-targeting in `Thrift.AspNetCore.csproj`.
> Note: The core `ApacheThrift` library will continue targeting
> `netstandard2.0` for .NET Framework compatibility.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
