Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove System.Net.Connections and related features #41648

Merged
merged 4 commits into from
Sep 2, 2020

Conversation

geoffkizer
Copy link
Contributor

System.Net.Connections is being removed from 5.0, along with the features in SocketsHttpHandler that relied on this (ConnectionFactory and PlaintextFilter).

To simplify the removal, I added a simplified internal version of SocketConnectionFactory to SocketsHttpHandler.

NetworkException/Error is removed also. I moved these to System.Net.Connections so that code can continue to work with minimal changes. The places in NetworkStream etc that were using NetworkException have been reverted to IOException.

@dotnet/ncl please review

@ericstj @danmosemsft FYI. Also @ericstj could you review and ensure my project-level changes are correct?

@geoffkizer geoffkizer added this to the 5.0.0 milestone Sep 1, 2020
@ghost
Copy link

ghost commented Sep 1, 2020

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

@Dotnet-GitSync-Bot
Copy link
Collaborator

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

@geoffkizer
Copy link
Contributor Author

/azp run runtime-libraries outerloop

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

src/libraries/System.Net.Http/src/System.Net.Http.csproj Outdated Show resolved Hide resolved
@@ -79,3 +79,24 @@ public partial class SocketsConnectionFactory : System.Net.Connections.Connectio
protected virtual System.Net.Sockets.Socket CreateSocket(System.Net.Sockets.AddressFamily addressFamily, System.Net.Sockets.SocketType socketType, System.Net.Sockets.ProtocolType protocolType, System.Net.EndPoint? endPoint, System.Net.Connections.IConnectionProperties? options) { throw null; }
}
}
namespace System.Net
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does it work if we remove System.Net.Connections from shared framework but still depend on it? Or is it still present? Do we still expose it to the user?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not exposed to the user. It's still part of the tree, but not dropped.

@karelz karelz modified the milestones: 5.0.0, 6.0.0 Sep 1, 2020
@karelz
Copy link
Member

karelz commented Sep 1, 2020

Thanks @geoffkizer! This PR is against master, I wonder if we should make it directly against release/5.0 branch ...

@geoffkizer
Copy link
Contributor Author

/azp run runtime-libraries outerloop

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Comment on lines -229 to -256
public async Task Connection_Stream_FailingOperation_ThowsNetworkException()
{
using var server = SocketTestServer.SocketTestServerFactory(SocketImplementationType.Async, IPAddress.Loopback);
using SocketsConnectionFactory factory = new SocketsConnectionFactory(SocketType.Stream, ProtocolType.Tcp);
using Connection connection = await factory.ConnectAsync(server.EndPoint);

connection.ConnectionProperties.TryGet(out Socket socket);
Stream stream = connection.Stream;
socket.Dispose();

Assert.Throws<NetworkException>(() => stream.Read(new byte[1], 0, 1));
Assert.Throws<NetworkException>(() => stream.Write(new byte[1], 0, 1));
}

[Fact]
public async Task Connection_Pipe_FailingOperation_ThowsNetworkException()
{
using var server = SocketTestServer.SocketTestServerFactory(SocketImplementationType.Async, IPAddress.Loopback);
using SocketsConnectionFactory factory = new SocketsConnectionFactory(SocketType.Stream, ProtocolType.Tcp);
using Connection connection = await factory.ConnectAsync(server.EndPoint);

connection.ConnectionProperties.TryGet(out Socket socket);
IDuplexPipe pipe = connection.Pipe;
socket.Dispose();

await Assert.ThrowsAsync<NetworkException>(() => pipe.Input.ReadAsync().AsTask());
await Assert.ThrowsAsync<NetworkException>(() => pipe.Output.WriteAsync(new byte[1]).AsTask());
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are keeping the rest of the code anyways, can we preserve these tests by refactoring the assertions for IOException? I would prefer not to loose them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell, the only reason these tests exist is to check for NetworkException specifically. So I'm not sure what we get by checking for IOException.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that the assertion is less valuable in it's current form, but is it more likely that we are about to re-introduce NetworkException eventually? In that case keeping them around will ensure that we don't loose them by accident.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depending on the direction we go, we will make a branch from master that reverts this PR and continue to iterate the API --so, I don't think we will lose anything.

Copy link
Contributor

@scalablecory scalablecory left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm.

@joperezr @safern @ericstj can you verify this change removes the System.Net.Connections assembly from final distro, and that System.IO.Pipeline is back to being out of net50 apps?

src/libraries/pkg/baseline/packageIndex.json Outdated Show resolved Hide resolved
@safern
Copy link
Member

safern commented Sep 1, 2020

Why are we doing this against master? Do we want this on 6.0?

@@ -48,7 +48,6 @@
System.IO.FileSystem.Watcher;
System.IO.IsolatedStorage;
System.IO.MemoryMappedFiles;
System.IO.Pipelines;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is removing pipelines reference here going to require a reaction in aspnetcore? Did we make changes to not reference it ourselves? @halter73 @Tratcher @JunTaoLuo

@geoffkizer
Copy link
Contributor Author

/azp run runtime-libraries outerloop

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@geoffkizer geoffkizer merged commit aaecee0 into dotnet:master Sep 2, 2020
@geoffkizer
Copy link
Contributor Author

/backport to release/5.0-rc2

@github-actions
Copy link
Contributor

github-actions bot commented Sep 2, 2020

Started backporting to release/5.0-rc2: https://github.com/dotnet/runtime/actions/runs/235362717

@geoffkizer
Copy link
Contributor Author

/backport to release/5.0

@github-actions
Copy link
Contributor

github-actions bot commented Sep 2, 2020

Started backporting to release/5.0: https://github.com/dotnet/runtime/actions/runs/235364028

@github-actions
Copy link
Contributor

github-actions bot commented Sep 2, 2020

@geoffkizer backporting to release/5.0-rc2 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: remove System.Net.Connections and related features
error: sha1 information is lacking or useless (src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http2Connection.cs).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 remove System.Net.Connections and related features
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

@github-actions
Copy link
Contributor

github-actions bot commented Sep 2, 2020

@geoffkizer backporting to release/5.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: remove System.Net.Connections and related features
error: sha1 information is lacking or useless (src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http2Connection.cs).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 remove System.Net.Connections and related features
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

geoffkizer added a commit to geoffkizer/runtime that referenced this pull request Sep 2, 2020
* remove System.Net.Connections and related features

* cleanup csproj changes

* Update src/libraries/pkg/baseline/packageIndex.json

Co-authored-by: Cory Nelson <[email protected]>

* Update src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.Tasks.cs

Co-authored-by: Cory Nelson <[email protected]>

Co-authored-by: Geoffrey Kizer <[email protected]>
Co-authored-by: Cory Nelson <[email protected]>
geoffkizer added a commit to geoffkizer/runtime that referenced this pull request Sep 2, 2020
* remove System.Net.Connections and related features

* cleanup csproj changes

* Update src/libraries/pkg/baseline/packageIndex.json

Co-authored-by: Cory Nelson <[email protected]>

* Update src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.Tasks.cs

Co-authored-by: Cory Nelson <[email protected]>

Co-authored-by: Geoffrey Kizer <[email protected]>
Co-authored-by: Cory Nelson <[email protected]>
@danmoseley
Copy link
Member

@akoeplinger Do you happen to know what causes git am to give fake ancestor?

@akoeplinger
Copy link
Member

Hm weird, this normally happens when the repo checkout doesn't contain the commit that the patch was built from (which shouldn't happen since we clone master and the target branch).

It works when I do it locally, but it wouldn't have helped in this case since I got a merge conflict in src/libraries/pkg/baseline/packageIndex.json so a manual backport would've been required anyway.

geoffkizer added a commit that referenced this pull request Sep 2, 2020
* remove System.Net.Connections and related features

* cleanup csproj changes

* Update src/libraries/pkg/baseline/packageIndex.json

Co-authored-by: Cory Nelson <[email protected]>

* Update src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.Tasks.cs

Co-authored-by: Cory Nelson <[email protected]>

Co-authored-by: Geoffrey Kizer <[email protected]>
Co-authored-by: Cory Nelson <[email protected]>

Co-authored-by: Geoffrey Kizer <[email protected]>
Co-authored-by: Cory Nelson <[email protected]>
geoffkizer added a commit that referenced this pull request Sep 2, 2020
* remove System.Net.Connections and related features

* cleanup csproj changes

* Update src/libraries/pkg/baseline/packageIndex.json

Co-authored-by: Cory Nelson <[email protected]>

* Update src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.Tasks.cs

Co-authored-by: Cory Nelson <[email protected]>

Co-authored-by: Geoffrey Kizer <[email protected]>
Co-authored-by: Cory Nelson <[email protected]>

Co-authored-by: Geoffrey Kizer <[email protected]>
Co-authored-by: Cory Nelson <[email protected]>
@jeffdoolittle
Copy link

Is there information anywhere describing the reasoning behind the removal? Thanks.

@halter73
Copy link
Member

halter73 commented Sep 4, 2020

We intend for System.Net.Connections to be a general-purpose abstraction and not something that's only used by HttpClient/SocketsHttpHandler. To help prove System.Net.Connections is a good general-purpose abstraction, the plan is to use it to replace Kestrel's current "Bedrock" transport abstraction (dotnet/aspnetcore#13295). Unfortunately, Kestrel's adoption of System.Net.Connections did not land in time for .NET 5, and we do not want to ship an abstraction with only one consumer. System.Net.Connections is not being removed permanently, but it is being delayed until .NET 6.

@jeffdoolittle
Copy link

we do not want to ship an abstraction with only one consumer

This makes complete sense. Thank you for the backstory. It is very much appreciated.

@mjsabby
Copy link
Contributor

mjsabby commented Sep 4, 2020

@halter73 this is a major impact to Bing. We have taken a dependency on this in RC1 builds. What recourse do we have?

cc @karelz @jeffschwMSFT @danmosemsft

@halter73
Copy link
Member

halter73 commented Sep 5, 2020

@mjsabby If a Stream-based ConnectCallback is added to SocketsHttpHandler as described in #28721, would that meet your needs?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.