Saturday, November 22, 2008


Remotely Possible

The .NET Remoting services introduced with ASP.NET made interprocess communication much less burdensome for the C# (and C++) developer. Visual Basic developers long had the benefit of COM automation, but C++ developers were stuck with the tedious tasks of writing proxies and marshalling code. So .NET Remoting is life in the fast lane.

However, the Microsoft examples of .NET Remoting and their emulations in most Web logs are only half debuggable (on the client side). With Microsoft's approach, the work on the server side is done in an object encapsulated in a DLL, not accessible to the debugger running a server (actually a server launcher). Beneficiaries of welcome automation must resort to archaic, file-writing techniques to debug a server-side process.

The solution is actually simple. Just insert the remote object code in the server code, and don't put it in a separate project. In the client code, create a reference to the .exe file for the server. The Server code now looks like the following example, using a console application as a test vehicle for a TCP channel server:

using System;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;
namespace Server
    public class ServerFunctions : MarshalByRefObject
        public int ServerFunction1( . . . .
        public bool ServerFunction2( . . . .
        . . . .
    public class ServerLauncher
        static void Main(string[] args)
                TcpServerChannel oTcpChannel = new TcpServerChannel(9000);
                ChannelServices.RegisterChannel(oTcpChannel, true);
                    typeof(ServerFunctions), "RemoteService",
                Console.WriteLine("Type Enter to exit");
            catch (Exception oException)
                Console.WriteLine("Error: " + oException.Message);

Be sure to add a reference to System.Runtime.Remoting.dll in a .NET Remoting project, when using ASP.NET 2.0 typically found in C:\Windows\Microsoft.NET\Framework\v2.0.50727. With code structured this way running under the Visual Studio debugger, functions in the ServerFunctions class can be debugged as usual. Corresponding client programs will acquire copies of the entire server .exe instead of just a .dll; that is the difference.

Comments: Post a Comment

Subscribe to Post Comments [Atom]

Links to this post:

Create a Link

<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]