wcf
wcf copied to clipboard
dotnet
Consuming WCF service using net named pipe binding in asp .net core 2.0 api
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
@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.
Do we have any progress on supporting namedpipe binding on .net core? Or do you have a target date for this?
@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.
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
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.
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.
Just out of interest, what timeframe are we looking at for this feature?
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.
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?
@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?
What is the final verdict on this? I have a .Net framework based process hosting a WCF service end point. I like to support a client running in .Net5 process over WCF. Is that possible?
I have a quite large and complex WCF self hosted server process (within a Windows Service) that hosts quite a few services (10+) and only local client processes that consume these services. My default binding for quite some time was net.tcp and, for simplicity, all services use the same (default) port and thus the TCP port-sharing service of the .NET Framework. This worked nicely, as long as no other application on the server machine would use the same port. We than had the situation where some other app did use WCF with net.tcp but without port-sharing so that either to other app or our service could be used, but not both. Since then we use the net.pipe binding succesfully. It would be very useful for our purposes to have the named pipe binding in .Net5 clients available, as porting the server application to gRPC/ASP.Net Core does not seem to be a good idea (this would require to re-implement the whole thing nearly from scratch).
I have a library for extending a third party application that I work with routinely that depends on the Named Pipe binding - but no control over third party application and no option for a different binding. I'd love to use .NET 5 or 6 for working with it, so this is currently a blocker.
@HongGit I do not see any update in the preview 3. Could you confirm anything ?
@HongGit (or @StephenBonikowsky @mconnew ) ? seems no one is answering here. I do not mind if this is the expectation or should I assume this is just dead ?
My understanding is that it is planned for this year, sometime in the .NET 7 timeframe. @HongGit can confirm
@StephenBonikowsky this is a useless github project, there is no communication from anyone. @HongGit after being tag by so many people in this thread has denied any commutation.
I would love to see this as well. Our .NET 6 web applications need to talk to local 3rd party services using NetNamedPipeBinding. Using httpbinding or net.tcp is not possible. We've been very happy so far with named pipes and we are in the process of migrating apps from WPF to Blazor web applications. However, we still need to talk to such services via named pipes which is currently blocking us to make a full transition for some applications. It would be great seeing this in .NET 7.0.
@HongGit do you plan to have any preview too of this as we already have some .net 7.0 preview release ?
I have a Windows service that hosts our licencing mechanism. Some of the admin features are restricted by only making them available through named pipes which means the admin app has to be run on the same box. This has been working really well in .Net 4 but I'd like to migrate the code over to .Net 6 now.
