Moving from .Net Remoting to Anonymous Pipes, equivalent of Activator.GetObject

I'm rewriting an old application that used .Net Remoting to control a second application. The rewrite involves changing from VB to C# (so apologies for the mixed languages in this post) and targeting core rather than a framework. Core doesn't support .Net Remoting and the advise seems to be to use Anonymous Pipes. I'm not familiar with either of these so it's a bit of a baptism of fire. I've been following the example here and have got it sending a simple string from one app to the other.

Here's my server app code:-

c# Code:

public void StartAquatorXV(string exePath, int port)
        {
            mAquatorXVPipe = new AnonymousPipeServerStream(PipeDirection.Out, HandleInheritability.Inheritable);
            ProcessStartInfo psi = new ProcessStartInfo(exePath, $"/anonymousPipe:{mAquatorXVPipe.GetClientHandleAsString()}");
            psi.UseShellExecute = false;
            mProcess = Process.Start(psi);
            mAquatorXVPipe.DisposeLocalCopyOfClientHandle();
            mProcess.WaitForInputIdle();
            mAquatorXVWriter = new StreamWriter(mAquatorXVPipe);
            mAquatorXVWriter.AutoFlush = true;
            mAquatorXVWriter.WriteLine("SYNC");
            mAquatorXVPipe.WaitForPipeDrain();
 
 
            mAquatorXVWriter.WriteLine("Test");
        }

Here's the client app code:-

C# Code:

PipeStream mAquatorServerPipe;
        StreamReader mAquatorServerReader;
        public static void ListenForAquatorServer(StreamReader reader)
        {
            string input;
            while ((input = reader.ReadLine()) != null)
            {
                Console.WriteLine(input);
            }
        }
        public void SetUpClientPipe(string serverHandle)
        {
            mAquatorServerPipe = new AnonymousPipeClientStream(PipeDirection.In, serverHandle);
            mAquatorServerReader = new StreamReader(mAquatorServerPipe);
            string input;
            do
            {
                input = mAquatorServerReader.ReadLine();
            }
            while (!input.StartsWith("SYNC"));
 
            Thread listener = new Thread(() => ListenForAquatorServer(mAquatorServerReader));
            listener.Start();
        }

Note, all the examples I could find dispose of the pipes and streams as soon as they're used which doesn't work for me, I need the client app to continue running but be able to interrupt it to send messages so I'm keeping those objects alive and will explicitly dispose of them on shutdown.

My next problem is that I'd like to be able to communicate with the client app in a strongly typed fashion. The original app used to do this to get an interface to work against:-

VB.Net Code:

' Start AquatorXV, tell it to listen on the designated port, and wait for it to be ready
            Dim psi As ProcessStartInfo = New ProcessStartInfo(location, $"/remoting:{port}")
            psi.UseShellExecute = False
            m_process = Process.Start(psi)
            m_process.WaitForInputIdle()
 
            ' Create the one remote AquatorXVInterfaces object
            If m_channel Is Nothing Then
                m_channel = New TcpChannel()
                ChannelServices.RegisterChannel(m_channel, True)
            End If
            Dim url As String = $"tcp://localhost:{port}/OSS.AquatorXV.Server"
            Dim o As Object = Activator.GetObject(Type.GetType("AquatorXVInterfaces.IServer, AquatorXVInterfaces"), url)  '<<<This is the bit I need to mimic
            m_aquatorXV = CType(o, AquatorXVInterfaces.IServer)

So if I understand that right it uses Activator.GetObject to retrieve the client application from the uri and then cast it to a known interface to get strong typing. I'm looking for an equivalent of that which will work in Core using Anonymous Pipes. Is that possible or am I going to have to couch all the communication in untyped strings?

Quote:

---

Originally Posted by FunkyDexter

I'm rewriting an old application that used .Net Remoting to control a second application. The rewrite involves changing from VB to C# (so apologies for the mixed languages in this post) and targeting core rather than a framework. Core doesn't support .Net Remoting and the advise seems to be to use Anonymous Pipes. I'm not familiar with either of these so it's a bit of a baptism of fire. I've been following the example here and have got it sending a simple string from one app to the other.

Here's my server app code:-

c# Code:

public void StartAquatorXV(string exePath, int port)
        {
            mAquatorXVPipe = new AnonymousPipeServerStream(PipeDirection.Out, HandleInheritability.Inheritable);
            ProcessStartInfo psi = new ProcessStartInfo(exePath, $"/anonymousPipe:{mAquatorXVPipe.GetClientHandleAsString()}");
            psi.UseShellExecute = false;
            mProcess = Process.Start(psi);
            mAquatorXVPipe.DisposeLocalCopyOfClientHandle();
            mProcess.WaitForInputIdle();
            mAquatorXVWriter = new StreamWriter(mAquatorXVPipe);
            mAquatorXVWriter.AutoFlush = true;
            mAquatorXVWriter.WriteLine("SYNC");
            mAquatorXVPipe.WaitForPipeDrain();
 
 
            mAquatorXVWriter.WriteLine("Test");
        }

Here's the client app code:-

C# Code:

PipeStream mAquatorServerPipe;
        StreamReader mAquatorServerReader;
        public static void ListenForAquatorServer(StreamReader reader)
        {
            string input;
            while ((input = reader.ReadLine()) != null)
            {
                Console.WriteLine(input);
            }
        }
        public void SetUpClientPipe(string serverHandle)
        {
            mAquatorServerPipe = new AnonymousPipeClientStream(PipeDirection.In, serverHandle);
            mAquatorServerReader = new StreamReader(mAquatorServerPipe);
            string input;
            do
            {
                input = mAquatorServerReader.ReadLine();
            }
            while (!input.StartsWith("SYNC"));
 
            Thread listener = new Thread(() => ListenForAquatorServer(mAquatorServerReader));
            listener.Start();
        }

Note, all the examples I could find dispose of the pipes and streams as soon as they're used which doesn't work for me, I need the client app to continue running but be able to interrupt it to send messages so I'm keeping those objects alive and will explicitly dispose of them on shutdown.

My next problem is that I'd like to be able to communicate with the client app in a strongly typed fashion. The original app used to do this to get an interface to work against:-

VB.Net Code:

' Start AquatorXV, tell it to listen on the designated port, and wait for it to be ready
            Dim psi As ProcessStartInfo = New ProcessStartInfo(location, $"/remoting:{port}")
            psi.UseShellExecute = False
            m_process = Process.Start(psi)
            m_process.WaitForInputIdle()
 
            ' Create the one remote AquatorXVInterfaces object
            If m_channel Is Nothing Then
                m_channel = New TcpChannel()
                ChannelServices.RegisterChannel(m_channel, True)
            End If
            Dim url As String = $"tcp://localhost:{port}/OSS.AquatorXV.Server"
            Dim o As Object = Activator.GetObject(Type.GetType("AquatorXVInterfaces.IServer, AquatorXVInterfaces"), url)  '<<<This is the bit I need to mimic
            m_aquatorXV = CType(o, AquatorXVInterfaces.IServer)

So if I understand that right it uses Activator.GetObject to retrieve the client application from the uri and then cast it to a known interface to get strong typing. I'm looking for an equivalent of that which will work in Core using Anonymous Pipes. Is that possible or am I going to have to couch all the communication in untyped strings?

---

Perhaps this isn't directly helping but... If you haven't invested too much time in this already grpc might be a better option.

https://docs.microsoft.com/en-us/asp...aspnetcore-6.0 is a decent starting point.

Not sure if this will be of any assistance...

App I wrote a while ago had 4 services running listening on HTTPListener's - that's besides the point.

For transmitting data, I created a CLASS, made it SERIALIZABLE and implemented ICloneable.

I have a serializer class that turns this other "CLASS" into a memory stream with a BinaryFormatter.

I can share code if this is in anyway connected with what you are asking, lol!

@szlamany, that sounds roughly like what I'm currently considering for the actual data as I think that the pipes are only capable of transmitting text. So I guess I'll have to serialize the parameters of any calls before writing to the stream and then deserialise on the other side. Similarly with responses but in reverse. I'm pretty confident I can work that out myself but if you've got any code I can use as a template I'd definitely appreciate it.

My concern here, though, is how I expose and police the API the client offers. I.e. how does the server know what methods are available, what their signatures are etc. Ideally I want to do it in a way that's strongly typed so I can catch any errors at compile time rather than run time. I'm hoping there's something built into core that will assist me with this but, if not, I can probably come up with something myself. As a fall back I can add a RESTful API to the client app and use that but I'd rather something strongly typed.

@PlausiblyDamp, I had seen people mention gRPC when I was investigating what the replacement for remoting was but didn't really take it on board as I came across Microsoft recommending Anonymous Pipes. A quick look at that link is intriguing. I think I'll spend some time digesting that today and might switch if it looks like it'll do what I want. Thanks.

Quote:

---

Originally Posted by FunkyDexter

@szlamany, that sounds roughly like what I'm currently considering for the actual data as I think that the pipes are only capable of transmitting text. So I guess I'll have to serialize the parameters of any calls before writing to the stream and then deserialise on the other side. Similarly with responses but in reverse. I'm pretty confident I can work that out myself but if you've got any code I can use as a template I'd definitely appreciate it.

My concern here, though, is how I expose and police the API the client offers. I.e. how does the server know what methods are available, what their signatures are etc. Ideally I want to do it in a way that's strongly typed so I can catch any errors at compile time rather than run time. I'm hoping there's something built into core that will assist me with this but, if not, I can probably come up with something myself. As a fall back I can add a RESTful API to the client app and use that but I'd rather something strongly typed.

@PlausiblyDamp, I had seen people mention gRPC when I was investigating what the replacement for remoting was but didn't really take it on board as I came across Microsoft recommending Anonymous Pipes. A quick look at that link is intriguing. I think I'll spend some time digesting that today and might switch if it looks like it'll do what I want. Thanks.

---

I have only had a quick play with gRPC but it does try to enforce the ideas of interfaces and DTOs quite well, the link does show how you can build strongly typed objects etc. pretty similar in some respects to how WCF used to do things (but without all the junk that came with WCF)

I am using NATS as pub-sub server to create "control plane" for multiple apps on single computer or inside network(s). You can serialize your strictly defined classes and pass the message to listeners. The message is transferred as byte array so you can use your choice of serializing library to JSON, protobuf or MessagePack format.

NATS is multiplatform pub-sub server and is distributed as really small single executable. There are client libraries for many languages, including .NET platform. The libraries are generic but you can add small library on top of it to automate (de)serializing and manage the boilerplate code.

Example server definition with my simple library that works on top of NATS:

C# pseudocode Code:

var host = NatsHost.CreateBuilder()
  .AddServer("server1_ip")
  .AddServer("server2_ip")
  .UseSecureConnection()
  .Build();
var pubsub = host.Connect();
 
// Sample replier - receives RequestClass and returns ResponseClass object. Generates some response using request data
pubsub.AddReplier<RequestClass, ResponseClass>("service.comm.channel", "workqueue", req =>
{
  Console.WriteLine(req.SomeField);
  return GenerateResponse(req);
});
 
// Replier that don't receive request but only returns response - this one returns server time
// The service is listening on channel Services.System.GetServerTime
string serverName = "tech01";
pubsub.AddReplier<DateTime>($"Services.System.GetServerTime.{serverName}",
() => DateTime.UtcNow());

To consume the "pubsub" service my lib has also simplified methods:

C# Code:

// Query the first example service
var request = new RequestClass { Field1-"some data", Field2 = 123 };
ResponseClass response = pubsub.RequestReply("service.comm.channel", request);
 
// Get server time 
DateTime serverTime = pubsub.RequestReply<DateTime>($"Services.System.GetServerTime.tech01");
 
pubsub.Publish("Servers.Control.Command.Update.*", new UpdateCommand { Version="1.2.3",
DownloadURL="https://storage/files/services/MyService/updates/v1.2.3/MyService.v1.2.3.zip });

With proper design of listening channels for services you can design the communication between apps. Some services don't return response so you can just send (publish) message that they will receive - for example you can send "update app to ver 1.2.3" command so the app will download specified version and autoupdate itself.

Finally, one important difference from other approaches is that you don't have to configure apps to know other apps IPs. They must know only server(s) addresses. The pub-sub server do the job to redirect the messages to the proper listener(s). Also NATS can be configured in cluster mode so even single instance is stopped for some reason (server down, network split, NATS crashed), the rest of the cluster will serve the requests so your system will be much more resilient.

Gah! I was sold on gRPC and I've been trying it out today but I don't think it's going to work for me. The app being controlled would need to be converted to a gRPC server but it can't be because it's targetting a traditional .Net framework rather than core. I'm writing the controlling app (which would be the client in this scenario) to target core but I don't have freedom to change the target of the controlled app.

I thought about adding the server as a separate project in the same solution but that doesn't work either. The server project would need a reference to the controlled project to do it's work but the controlled app also needs a reference to the server project to start up the server so circular reference.

I think I'll post in their community before I give up though.

@peterst, I'm taking a look at the NATS site. I can see it handles the request response process but does it provide a typesafe experience or does it require the requests and responses being correctly formed by hand? Looking at their docs it looks like you simply pass a string or set of strings to a request and get a string back as a reply. That's not really what I'm after. I want to be able to pass complex types and have the type checking and serialisation concerns abstracted away. Otherwise I'll just use the anonymous pipes and go RESTful.

I've created small library on top of NATS to do the type specific conversion. The same way ASPNET Core handles http requests with type specific parameters - invisible for the developer. gRPC also works the same under the hood.

If you directly use NATS library, you work with byte arrays. The same way you will work with the Context.Request.Body in aspnet core. But having higher level support of specific data types in library, you just don't care how the library handle them. You work with strong data types - just check the examples in my previous post. You may find them pretty similar to minimal web API in .NET Core 6, as my new version of the library is evolving during the years and I really like that way of defining services. Add the service and pass lambda of the handler. Put the parameter types in Action(Of TRequest) or Func(Of TRequest, TResponse) and the compiler will do the strict type checks for you.

Here is definition from my library of method to add replier - function that takes request and returns response (replies to message):

C# Code:

public ChannelListener AddReplier<TRequest, TResponse>(string channel, Func<TRequest, TResponse> subscriber)
{
    var listener = new ChannelListener(channel, _conn.SubscribeAsync(channel, (s, e) =>
    {
        TResponse reply = subscriber.Invoke(_serialzier.Deserialize<TRequest>(e.Message.Data));
        var serializedReply = _serialzier.Serialize(reply);
        PublishMessage(e.Message.Reply, serializedReply);
    }));
        
    _listeners.Add(listener.Guid, listener);
    return listener;
}

I forgot to mention another advantage of pub-sub pattern. You open ports only on server. Clients connect to server and don't need to open ports locally. Zero configuration required to "call" (send messages) to listeners as they can be everywhere in the network even with changing IP addresses (DHCP or just new machines with new IPs). If you want to identify specific listener - define proper channel name with specific listener name inside - this is just one of the access patterns for pub-sub messaging.

In another thread here someone asked how to ping multiple servers. I proposed to do the opposite - each server to "ping" the listener using pub-sub messaging. This way the developer will not care if there are 1, 5 or 3000 servers in the network and where they are located (it could be NATS edge connections between multiple data centers). The listener will receive pings, mark servers down when ping was not received for specified amount of time and perform some actions.

Also on server (as hardware machine) the app (that sends the pings) can collect local for the OS data without exposing opened ports or when that is impossible - UPS status info, SQL server status, CPU and memory usage, free disk space, etc. Collect the info and send it regularly to the listeners which will aggregate into centralized database so admins can watch what happens with the machines. Also use these messages instead of pings. Or do whatever you need.

But using messaging requires re-thinking of apps structure and how the communication is performed. Just imagine it like room with people where you can tell (send message) to someone to do something or to everyone. Ask for information and get response. Ask everyone and get multiple responses. Or just listen what others say.

gRPC ended up being a dead end for the reasons given above. I've decided to cut my losses, fall back on targeting the framework rather than core and switch to using WCF. However, I'm still running in to a problem (the client is failing to connect to the end point - I suspect the endpoint may be being set up and immediately dropped).

As the topic of my question has substantially changed I'm going to post a new question and link to it from here.

Edit>Scratch that, I spotted the problem just after posting.:rolleyes:

Quote:

---

Originally Posted by FunkyDexter

gRPC ended up being a dead end for the reasons given above. I've decided to cut my losses, fall back on targeting the framework rather than core and switch to using WCF. However, I'm still running in to a problem (the client is failing to connect to the end point - I suspect the endpoint may be being set up and immediately dropped).

As the topic of my question has substantially changed I'm going to post a new question and link to it from here.

Edit>Scratch that, I spotted the problem just after posting.:rolleyes:

---

https://github.com/CoreWCF/CoreWCF might be an option if you are wanting to move to core, not tried it but from a few articles I have read it seems a decent port of WCF to core.

Thanks for the suggestion but I'll probably pass. 2 Reasons really:-
1. I don't really need to move to core. As I was approaching this tool as a new project it seemed sensible to target it but the truth is that the controlled application is already targeting a framework so is kinda locked to Windows anyway. If that changes we'd need to revisit both apps any way.
2. The way I want to use it is a bit non-standard (i.e. it needs to self host the service and the client can't have a web reference at design time). I don't know if a third party lib will support that and I notice that the docs and walkthroughs don't seem to cover it so it'll be an ache to work out.

Using WCF seems to be working great for now so I think I've reached a comfortable happy ground.

Thanks to everyone for the suggestions.