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?

[videoguy]

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?

[DSanchen]

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).

[patricktownley]

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.

[fforjan]

@HongGit should we expect this to be part of .NET 7 ?

[StephenBonikowsky]

@mconnew and @HongGit do you have an ETA?

[fforjan]

@HongGit I do not see any update in the preview 3. Could you confirm anything ?

[fforjan]

@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 ?

[StephenBonikowsky]

My understanding is that it is planned for this year, sometime in the .NET 7 timeframe. @HongGit can confirm

[fforjan]

@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.

[HongGit]

This feature is still in the plan to ship in .NET 7.0.

[solunicansu]

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.

[fforjan]

@HongGit do you plan to have any preview too of this as we already have some .net 7.0 preview release ?

[fforjan]

@HongGit

[SRichardsonDTech]

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.

[szilvaa]

It looks like some work has started on this: https://github.com/dotnet/wcf/pull/4955

[MeikTranel]

@szilvaa they already have bits available for testing - https://www.nuget.org/packages/System.ServiceModel.NetNamedPipe/6.0.0-preview1.23060.3

[smithmw]

Does anyone know when it will be available? Will this be accessible through .NET Standard so that one library can be created that will work for both .NET Framework and .NET? Or will this only be available in .NET (requiring creating two different libraries for .NET and .NET Framework)?

[mconnew]

@smithmw, we are dropping support for netstandard and you will need to multi-target. We're doing everything we can to make that as pain free as possible by keeping the same api shapes between .NET Framework and .NET 6.0 for existing api's. You shouldn't need to conditionally compile any code as long as the features you are using are the same between .NET Framework and .NET.

[Manka-Muakido]

ok, i am not the smartest cookie in the jar but, everything works simple, practical and fine in 4.8 with traditional WCF, literally 3 lines and the WCF is up, i tried in a separated project to test in .NET 6 to access a 4.8 working WCF and they do not throw exception but get stuck eternally in the call on channel

can someone please illuminate me?

code: .csproj in .NET 6

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net6.0-windows</TargetFramework>
    <RootNamespace>PipeTetst_Net6_donet_WCF</RootNamespace>
    <Nullable>enable</Nullable>
    <UseWPF>true</UseWPF>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.ServiceModel.Duplex" Version="6.0.0-preview1.23060.3" />
    <PackageReference Include="System.ServiceModel.Federation" Version="6.0.0-preview1.23060.3" />
    <PackageReference Include="System.ServiceModel.Http" Version="6.0.0-preview1.23060.3" />
    <PackageReference Include="System.ServiceModel.NetTcp" Version="6.0.0-preview1.23060.3" />
    <PackageReference Include="System.ServiceModel.Primitives" Version="6.0.0-preview1.23060.3" />
    <PackageReference Include="System.ServiceModel.Security" Version="6.0.0-preview1.23060.3" />
    <PackageReference Include="System.Web.Services.Description" Version="6.0.0-preview1.23060.3" />
    <PackageReference Include="System.ServiceModel.NetNamedPipe" Version="6.0.0-preview1.23060.3" />
  </ItemGroup>

</Project>

mainWidnows.xaml.cs:

using System.Windows;

namespace PipeTetst_Net6_donet_WCF
{
    /// <summary>
    /// Interaction logic for MainWindow.xaml
    /// </summary>
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
        }

        private void Button_Click(object sender, RoutedEventArgs e)
        {
            ServiceProxy sp = new ServiceProxy();
            MessageBox.Show(sp.InvokeHelloWorld());
        }
    }
}

IService.cs:

using System.ServiceModel;

namespace PipeTetst_Net6_donet_WCF
{
    [ServiceContract]
    public interface IService
    {
        [OperationContract]
        string HelloWorld();
    }

    public class Service : IService
    {
        public string HelloWorld()
        {
            return "Hello from PipeTest-FrameWork48-WFC-NET6";
        }
    }
}

ServiceProxy.cs

using System;
using System.ServiceModel.Description;
using System.ServiceModel;

namespace PipeTetst_Net6_donet_WCF
{
    public class ServiceProxy : ClientBase<IService>
    {
        public ServiceProxy()
            : base(new ServiceEndpoint(ContractDescription.GetContract(typeof(IService)),
                new NetNamedPipeBinding(), new EndpointAddress("net.pipe://localhost/MyAppNameThatNobodyElseWillUse2/helloservice")))
        {

        }
        public string InvokeHelloWorld()
        {
            try
            {
                return Channel.HelloWorld();
            }
            catch (Exception e)
            {
                //
            }

            return "";
        }
    }
}

with the two desktop winforms 4.8 wcf program one can communicate with the other, but with the 4.8 running and a .net 6 code above when i press the button to try get the hello world from 4.8....it get stuck for eternity, no error, no exception, just frozen in time, can someone give me some hints? i have literally 13 legacy winforms desktop app that uses wcf and from those 13 of which 9 is 3ª party (that i can't change the code, only use/consume the app) and i need to communicate in WCF classic (net.pipe:) and the new project in .net 6 and .net 7, i going crazy trying to make this work

[smithmw]

@mconnew, I am attempting to use the preview package (https://www.nuget.org/packages/System.ServiceModel.NetNamedPipe/6.0.0-preview1.23060.3) in a .NET 6 client. I tried to use the "Add Connected Service"->"Add a service reference"->"WCF Web Service". However, when attempting to use this, after starting my service and then after entering the service URL and typing pressing "Go", I get the following error:

An error occurred while attempting to find services at 'net.pipe://localhost/MyService/v1'. The service Uri is not valid: 'net.pipe://localhost/MyService/v1'.

Is using the "Add new WCF Web Service service reference" dialog the correct way to add this service reference to the client or is there another approach I should be using?

[mconnew]

@HongGit, is there a timeline for when named pipes support is being added to dotnet-svcutil (which Add Connected Services uses as the implementation).

[mconnew]

@Manka-Muakido, it's possible there's a bug related to where continuations are being executed. WPF apps use a single threaded execution context. WCF is implemented async only internally so calling WCF using a sync method ends up doing sync over async internally. You can verify if this is the problem by changing ServiceProxy.InvokeHelloWorld() to this:

        public string InvokeHelloWorld()
        {
            try
            {
                return Task.Run<string>(() => { return Channel.HelloWorld(); }).GetAwaiter().GetResult();
            }
            catch (Exception e)
            {
                //
            }

            return "";
        }

If that works, then that confirms this is the problem and we'll fix it before we come out of preview. If that isn't the problem, can you open a new issue to track this. In that case, it would be helpful if you could provide your test app to help with the investigation.

[smithmw]

@mconnew @HongGit, do either of you have an estimate of when a preview would be available that includes the ability to "Add Service Reference" for a named pipe service? Or is there some workaround we can use to with our service to try out the preview package.

We need this information to be able to make a decision on whether continuing with WCF names pipes is viable as we move our client from .NET Framework to .NET.

Thanks for any information you can provide.

[fforjan]

I have been using the preview -6.0.0-preview1.23060.3- for hacking our application and our basic scenario seems to work :) in our case, just compiling the existing C# code, not regenerating anything

[mconnew]

@smithmw, you could temporarily launch your service using NetTcp, generate a client, then switch the service back to NetNamedPipe. Then in your app you could either edit the generated code to use NetNamedPipe instead (you need to change the endpoint address to use net.pipe as well as change the binding), or use a different overload of the generated client constructor which takes an endpoint address and binding to override the one it generated with.

[smithmw]

@smithmw, you could temporarily launch your service using NetTcp, generate a client, then switch the service back to NetNamedPipe. Then in your app you could either edit the generated code to use NetNamedPipe instead (you need to change the endpoint address to use net.pipe as well as change the binding), or use a different overload of the generated client constructor which takes an endpoint address and binding to override the one it generated with.

@mconnew, This approach worked well. Thank you for the suggestion. While testing, we encountered the issue described previously in this thread: https://github.com/dotnet/wcf/issues/2535#issuecomment-1426196355

I've logged a defect with a sample here: https://github.com/dotnet/wcf/issues/5080

It is possible that it might already be solved by https://github.com/dotnet/wcf/pull/5044 Is there a new preview package we could test with?

[Deeepakhn]

can anyone share a sample project? We are in process of Migrating our SelfHostedWCF which use NetNamedPipe Bindings to CoreWCF. We have more than one SelfHostedService listening at different Base Addresses.

When we try to launch the second CoreWCF service , it says the Address already in use . What are the key differences in NetNamedPipes between WCF to CoreWCF.