Missing ClientBase<TChannel>ClientBase(ServiceEndpoint endpoint) Constructor

[MattB-msft]

Working on a Port of a WCF Client for .net core and am dealing with a missing constructor in the .net core version of WCF.

We required the ClientBase(ServiceEndpoint endpoint) to create the ClientBase object.

Edited

Add protected ClientBase(ServiceEndpoint endpoint) to the public contract.
Add public ChannelFactory(ServiceEndpoint endpoint) to the public contract.
Add scenario test coverage.

Fixed by #3341

[Lxiamail]

Looks like #240 removed ClientBase constructors.

[StephenBonikowsky]

Hi @MattB-msft that constructor was not part of the initial public contract for WCF Core, the code existed initially but was cleaned-up and removed with PR #252

It looks like it was removed because it called into caching code for ChannelFactory which is not used in WCF Core.

@mconnew I don't remember the context around why ChannelFactory caching was not used in Core, is it related to server side code?

[mconnew]

The code change was related to not having configuration available. In order to be able to always cache by default, you need to know that the binding and endpoint of the constructed ClientBase is the same. On .NET Framework, when using the constructor which accepts a configuration name, the configuration isn't going to change so caching is enabled. There's no way to know that you can safely cache with the constructors which are available in our current contract so we removed the caching code.
So the cleanup of caching code was unrelated to the constructor accepting a ServiceEndpoint. That code got cleaned up as we were cleaning up dead code in ClientBase and that constructor isn't in contract.
The same caching situation exists with ServiceEndpoint, there's no easy way to determine that the passed ServiceEndpoint is equivalent so caching is disabled by default. We can add the ServiceEndpoint constructor back and add it into the contract without bringing back the caching code. That's an orthogonal discussion/issue.

[StephenBonikowsky]

@mconnew Thanks for the clarification.

@Lxiamail Do we want to consider bringing that constructor back and adding it to the public contract?

[Lxiamail]

@StephenBonikowsky Yes, we can do consider bringing that constructor back and adding it to the public contract.

[StephenBonikowsky]

I discussed this with @mconnew a little bit, sounds fairly simple. Lets talk timing at our next meeting.

[StephenBonikowsky]

After discussion today we've decided to bring this constructor back and add it to the public API surface area right away for 3.0