Wcf: Consuming WCF service using net named pipe binding in asp .net core 2.0 api

[prashantalhat]

Is it possible to consume WCF service using net named pipe binding in asp .net core 2.0 api?

There is always option to make WCF service to use http enabled binding. But I have a specific requirement to do that?

I didnt find any useful resources on google.

https://stackoverflow.com/questions/48555371/consuming-wcf-service-using-net-named-pipe-binding-in-asp-net-core-2-0-api

[zhenlan]

@prashantalhat, this is currently not supported.

Technically, this can be supported on Windows. Because WCF is client only on .NET Core, there will be no usage scenarios on other platforms.

[ligengatms]

Do we have any progress on supporting namedpipe binding on .net core? Or do you have a target date for this?

[Lxiamail]

@ligengatms Currently, there is no plan to support it in the near future. However, we prioritize work item based on customer feedbacks. As @zhenlan mentioned earlier, it would be windows only if we support it since WCF is client only on .NET Core. For anyone, who likes to request this feature, please share your usage scenario, which will help us to prioritize the work.

[dhawalk1981]

I have a WCF service that validates SAML. This code cannot be moved to .NET Core as the assemblies for validating SAML are missing in Core. So, I need to call to this from Web API which is in .NET Core. Both the WCF Service and Web API are on the same machine and hence it will be better on performance to call this WCF over named pipe.

the other alternative is porting the assemblies need for SAML validation to Core which removes the requirement of this call out

[bbarry]

I have a service which validates users as being in specific active directory roles which runs under a limited domain account in order to expose a check for credentialed users of our application and give them additional privileges based on AD claims while keeping the application running under a local IIS user (who cannot query AD).

We can switch the service to net tcp easily enough.

[brentafis]

Following up from here.

I'm not opposed to replacing p/invokes. I understand the concerns with integrating Windows-specific code into a cross-platform system.

To outline my thoughts a bit:

• My immediate thought was to deal with the platform specific implementation details via injection.
• This would require exposing the IConnectionFactory and IConnection interfaces as well as a new interface that would return an IConnectionFactory (I'll call it IConnectionFactoryProvider).
• My plan was to create a scaffolding version of NetNamedPipeBinding that took an IConnectionFactoryProvider which would be implemented by platform specific code.
• Those interfaces and the scaffolding for NetNamedPipeBinding would be provided via a new nuget package, System.ServiceModel.NetNamedPipe.
• I could then consume that nuget and feed it an implementation of IConnectionFactoryProvider that was ported from the netframework namedpipe stack.

That may or may not align with how you've thought about bringing this in. I am sure there are more details here to work out but these were my initial thoughts. The advantage with this approach from my perspective is that I can leverage the existing implementation details of the netframework namedpipe stack. There are quite a few files involved in that stack and I was/am concerned about being able to communicate properly with the server end. My main goal was to provide this support without having to modify any server code at all; so that existing clients could simply migrate to this solution without the risk of breaking the client/server communication. While I'm sure that is likely possible using something like System.IO.Pipes.NamedPipeClientStream I was hesitant to attempt to do so (at least initially) and felt porting the netframework code was more likely to result in success.

I'd be happy to discuss things further in more detail but I also realize this isn't a top priority for you at this time. It would however be nice to get some feedback on whether the team is on-board with the approach outlined or if they may have other suggestions.

[jeremy-morren]

Just out of interest, what timeframe are we looking at for this feature?

[MeikTranel]

One point to underline the importance here:
Right now all means of communication require that a service is run with elevated privilege. People using WCF with named pipes for inter process communication are utterly blocked by this, because most desktop application vendors cannot ask their customers to run something with elevated privilege because most of the time they don't even that option available to them.
Not even speaking about the security implications of relying on opening up ports in applications made for layman.
This feature is a strong blocker for a migration task of mine and i would personally be fine with having to take additional dependencies onto platform extension packages for example.

[rsankardayal]

Dynamics GP eConnect has a WCF service with an netnamedpipebinding endpoint (net.pipe://localhost...). I am very much interested if there is a solution to consume this service with .Net Core.

Is there any way this class could be added to the compatibility pack?

[MeikTranel]

@HongGit this issue is assigned to no milestone since the future milestone was removed by @StephenBonikowsky - may i suggest given the above mentioned reasons that we consider this for 6.0 with a higher priority?