"Add service reference" vs "Add connected service" issues

[Ramin2c]

Hi What is the difference between "Add service reference" in Visual Studio 2015 and "Add connected service" in Visual Studio 2017 I wonder? The thing is I am porting a project from VS 2015 with .net framework 4.5.2 to VS 2017 with .net Core 2.0 which contains calls to some enterprise web service. The first thing I noticed is that the latter only creates Async method so I had to update the client code as well to call the *Async version for every method which went well. Just for my own curosity I also update the legacy code to use the same Async methods, tested it and was OK. However, the same method and exactly the same client code fails when executed on .net core. I don't understand why. It fails with an error returned from the service stating that the WS security header is missing and that's while the security header is provided via the OperationContext exactly the same way we did it before for the 2015 version and worked. I cannot reveal the details about the service we are using but look below for how the service is being called and the secuity header is injected:

var securityHeader = new SecurityHeader("id", "", ""); var client = new TerminalPortTypeClient(); var clientChannel = client.InnerChannel; using (new OperationContextScope(clientChannel)) { OperationContext.Current.OutgoingMessageHeaders.Add(securityHeader);
var resAsync = client.GetTerminalsAsync(...); var svar = resAsync.Result; // here it fails on .net core }

To me it looks like the .net core proxy some where on the way drops out the injected header. Hope someone can help me understand the reason behind the failure or suggest a way out.

regards R.

[dasetser]

@Ramin2c The difference between "Add Service Reference" and "Add Connected Service" is whether the generated proxy can run on .NET Core (Connected Service) or on the full .NET Framework (Service Reference). WCF on .NET Core does not support all the same features as WCF on the full framework, so the proxy has to be generated differently.

The reason you're seeing an error when calling the service is because WS Security is not supported by WCF on .NET Core.

[Ramin2c]

@dasetser thanks for the hint. So, how different should the proxy be generated for .net core? Is there any new tool?

[dasetser]

@Ramin2c Add Connected Service is the new tool for generating .NET Core proxies. It sounds like you generated your proxy correctly to use it on .NET Core, but since you're using a feature not supported by the .NET Core runtime you run into a problem communicating with the service. WCF on .NET Core doesn't support WS Security, so if the service you're trying to communicate with requires it you won't be able to port the client to .NET Core.

[Code-DJ]

Are there plans to make "Add Connected Service" work for VB.NET Core projects? Thanks.

[Ramin2c]

We managed to solve the issue by injecting a SecurityHeader class (attached). Now we can inject Username and Password to the outgoing SOAP header. The proxy classes are generated with "Add Connected Service" tool. @Code-DJ The same should work for your VB.Net project, I guess/hope ;)

[Code-DJ]

@Ramin2c I tried, the option is not available in a VB.NET Core Project. Maybe I should open a separate issue. The workaround I used is to Add it to a C# project then convert Reference.cs to Reference.vb using an online C# to VB.NET converter. Thanks.

[dasetser]

@Ramin2c I'm glad you found a workaround for the issue you were running into. I'll close this issue.

@Code-DJ Supporting VB.NET Core projects with Add Connected Service is in the backlog to investigate, but we don't have any concrete plans yet. This doesn't seem related to this issue, so please file a separate issue if you want to give feedback about it.

[Ramin2c]

@dasetser OK. Thanks for your support and quick replies.