. NET Core 2.0 learning Note (vi): Remoting core class library RealProxy migration

In the process of learning. NET core, we have been explicitly told that remoting will not be supported. The official explanation is that the. NET Framework type contains too many runtime content and is a very heavyweight service implementation that has been identified as a problematic architecture. Plainly, migration is difficult, and not directly available in. NET Core. Microsoft's recommendation is that if it is in-process or cross-process communication, we recommend using pipes or a memory-mapped file (Mapped files). If it is a call between machines, we recommend that we use network communication schemes, such as HTTP, WCF, and so on.

Well, since the official Microsoft does not support, we can only find a way to fix it.

OK, before we say the migration scenario, let's look at the code in the. NET Framework that uses remoting:

Through the remoting encapsulated service invocation method, we can directly get the implementation of a service interface by invoking the local proxy implementation of the secondary interface to execute the remote call.

static void Main (string[] args)
{
Iuserservice service = invokeserice.proxy<iuserservice> ();
String uName = service. Getcurrentusername ();

Console.WriteLine ($ "Current user name: {uName}");
Console.ReadLine ();
}

The declaration of the Iuserservice interface is as follows:

public interface Iuserservice
{
String Getcurrentusername ();
}

The core implementation logic of the Invokeservice method is as follows:

Remote Invoke Service provider class

public class Invokeservice
{

Gets the local call proxy object for a service
public static T proxy<t> ()
{
var proxy = new invokeproxy<t> ();
Return (T) proxy. Gettransparentproxy ();
}
}

Service local proxy object implementation class

public class Invokeproxy<t>: RealProxy
{
Private type type = NULL;
Public Invokeproxy (): This (typeof (T))
{
Type = typeof (T);
}

Protected Invokeproxy (Type classtoproxy): Base (Classtoproxy)
{
}

Receives a local call request and then forwards the remote access

public override IMessage Invoke (IMessage msg)
{
Console.WriteLine ("Invoke Remote service invocation!") ");
ReturnMessage message = new System.Runtime.Remoting.Messaging.ReturnMessage ("Test", Null,0,null, (IMethodCallMessage ) msg);

Return (IMessage) message;
}
}

Using. NET Portability Analyzer to analyze this project, we get results that the system does not support.

Since. NET core already does not support RealProxy, it can only be started anew. By flipping through the code of. NET core, we finally found an assembly: System.Reflection.DispatchProxy. In this program, there is a type dispatchproxy. (inspiration still comes from WCF.) WCF is a heavyweight API in. NET, and Microsoft cannot support it by flipping through the implementation logic and finally to the RealProxy alternative. ）

Well, with the features provided by Dispatchproxy, it's easy to replace the realproxyp,remoting problem and finally the perfect solution. Let's paste the replacement service implementation code below.

public class Invokeserice
{
public static T proxy<t> ()
{
Return dispatchproxy.create<t, invokeproxy<t>> ();
}
}

public class Invokeproxy<t>: Dispatchproxy
{
Private type type = NULL;
Public Invokeproxy ()
{
Type = typeof (T);
}

protected override Object Invoke (MethodInfo targetmethod, object[] args)
{
Console.WriteLine ("Invoke Remote service invocation!") ");

return "Test";
}
}

. NET Core 2.0 learning Note (vi): Remoting core class library RealProxy migration