NetFramework 4.6.1 to 4.8 with System.Net.Http regression

[ladeak]

Description

I have been updating a .net framework 461 application to net48. In the medium future to updating to net6.0 as well, currently many projects are already multi-targeted.

Due to nuget package dependencies in the net461 build System.Net.Http.dll with AssemblyVersion 4.2.0.0 is placed in the output folder and being used at runtime. I also have a corresponding binding redirect in web.config file.

After switching to net48, I have to add a reference

<ItemGroup Condition="'$(TargetFramework)' == 'net48'">
     <Reference Include="System.Net.Http" />
</ItemGroup>

to the csproj to get things compile. I also have to remove the assembly binding redirect in the web.config. In the new compilation, System.Net.Http.dll is not placed in the output folder, during runtime it is picked up from the GAC with version 4.1.x.x. This is a version downgrade, which has regression:

HttpClient does not dispose the request content in 4.2.0.0 or net6.0, but in net48, it calls dispose

I would like to keep the 4.2.0.0 behavior, because that matches with net6.0. Adding System.Net.Http as a nuget package is not an option, as those versions have this regression too.

What are the options to keep the net461/net6.0 behavior of System.Net.Http with net48?

Reproduction Steps

• Create a net461 asp.net application.
• Add nuget package which brings a transitive dependency on System.Net.Http. During runtime version 4.2.0.0 is used.
• Update the application to net48.
• An older version of System.Net.Http is being used at runtime.

Expected behavior

I would like to have the same behavior as in net461 which stands closer to net6.0, while net48 has a regression in this sense.

I would expect HttpClient not to dispose the request's HttpContent in net48.

Actual behavior

HttpClient disposes the request's HttpContent in net48.

Regression?

Yes, it seems so.

Known Workarounds

No known workarounds.

Configuration

• net461, net48, net6.0
• Windows Server 2019
• x64
• Visual Studio 2022

Other information

I understand why the dll is picked up from the GAC related to net48 being netstanard2.0 compatible. How can I "override" this net48 behavior anad keep the one I experience in net461?

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

I have been updating a .net framework 461 application to net48. In the medium future to updating to net6.0 as well, currently many projects are already multi-targeted.

Due to transitive nuget package dependencies in the net461 build System.Net.Http.dll with AssemblyVersion 4.2.0.0 is placed in the output folder and being used at runtime. I also have a corresponding binding redirect in web.config file.

After switching to net48, I have to add a reference

<ItemGroup Condition="'$(TargetFramework)' == 'net48'">
     <Reference Include="System.Net.Http" />
</ItemGroup>

to the csproj to get things compile. I also have to remove the assembly binding redirect in the web.config. In the new compilation, System.Net.Http.dll is not placed in the output folder, during runtime it is picked up from the GAC with version 4.1.x.x. This is a version downgrade, which has regression:

HttpContent's Dispose() method does not seem to check _contentReadStream in net48.

I would like to keep the 4.2.0.0 behavior, because that matches with net6.0. Adding System.Net.Http as a nuget package is not an option, as those versions have this regression too.

What are the options to keep the net461/net6.0 behavior of System.Net.Http with net48?

Reproduction Steps

• Create a net461 asp.net application.
• Add nuget package which brings a transitive dependency on System.Net.Http. During runtime version 4.2.0.0 is used.
• Update the application to net48.
• An older version of System.Net.Http is being used at runtime.

Expected behavior

I would like to have the same behavior as in net461 which stands closer to net6.0, while net48 has a regression in this sense.

I would expect HttpContent's Dispose method to test _contentReadStream task.

Actual behavior

HttpContent's Dispose method does not test _contentReadStream task.

Regression?

Yes, it seems so.

Known Workarounds

No known workarounds.

Configuration

• net461, net48, net6.0
• Windows Server 2019
• x64
• Visual Studio 2022

Other information

No response

Author:	ladeak
Assignees:	-
Labels:	area-System.Net.Http, untriaged
Milestone:	-

[ladeak]

So for now, I am migrating to net462 because that still has the same behavior as net461, but this seems to only postpone the issue.

[ladeak]

@karelz , do you have any suggestions?

[karelz]

2 things interact here:

• Call to content Dispose in HttpClient has been discussed in Why does HttpClient dispose HttpContent? #14612 and removed PR Stop disposing of request content in HttpClient corefx#19082 ... in nutshell, it was a fix to a long-existing design bug which we couldn't simply fix in .NET Framework due to compatibility, but we could fix it in .NET Core (and temporarily in NuGet package).
• System.Net.Http.dll stopped shipping any code for .NET Framework -- see problems it caused in Inheritance security rules violated by type: 'System.Net.Http.WebRequestHandler'. Derived types must either match the security accessibility of the base type or be less accessible. #18280. The NuGet package is something Networking team wanted to use to deliver fixes faster out of the box for .NET Framework, but it turned into major pain for everyone and a huge mistake for .NET ecosystem overall (more on the backstory in Broken System.Net.Http 4.1.1-4.3.0 post-mortem #20777 (comment)) -- as a result, our recommendation is to NOT use the NuGet package at all (if possible) and/or downgrade the version to the one shipped in .NET Framework (which I believe is 4.0.0.0).

To be honest, I would be surprised if latest NuGet package would have any code even for net460 or net461. IMO it should be same story as on net48 -- use the one inbox.

That said, as a result, we cannot have the nice new behaviors on .NET Framework with latest NuGet package. Using older NuGet package means that you are dropping support (no security fixes, or any other fixes in the area).
The only way forward to get the kind of innovation you need is to migrate to .NET (Core), where we have easier time to fix problems and innovate, because it is not in-place update like .NET Framework.

I understand that this is likely not the answer you expected, but sadly, this is where we are.
If we had a time machine, we would go back and never ship System.Net.Http.dll as standalone Nuget package.

[ladeak]

Thank you for the detailed description.

[karelz]

Here's even more details about the whole story: #20777 (comment)

(sorry, it took a while to page in all the relevant parts of this ugly story ... I didn't have to answer any questions about it for couple of years now and it is something that I am more than happy to forget about)