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)
{
try
{
TcpServerChannel oTcpChannel = new TcpServerChannel(9000);
ChannelServices.RegisterChannel(oTcpChannel, true);
RemotingConfiguration.RegisterWellKnownServiceType
(
typeof(ServerFunctions), "RemoteService",
WellKnownObjectMode.Singleton
);
Console.WriteLine("Type Enter to exit");
System.Console.ReadLine();
}
catch (Exception oException)
{
Console.WriteLine("Error: " + oException.Message);
Console.ReadLine();
}
}
}
}
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.
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)
{
try
{
TcpServerChannel oTcpChannel = new TcpServerChannel(9000);
ChannelServices.RegisterChannel(oTcpChannel, true);
RemotingConfiguration.RegisterWellKnownServiceType
(
typeof(ServerFunctions), "RemoteService",
WellKnownObjectMode.Singleton
);
Console.WriteLine("Type Enter to exit");
System.Console.ReadLine();
}
catch (Exception oException)
{
Console.WriteLine("Error: " + oException.Message);
Console.ReadLine();
}
}
}
}
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:
<< Home
Implementing the DashboardFacade
Building Client-Side Widgets
Delaying Server-Side Widget Loading
Content Proxy
Building a Client-Side RSS Widget
Building a Client-Side Flickr Widget
Optimizing ASP.NET AJAX
Combining Multiple Ajax Calls into One Call
Timing and Ordering Ajax Calls to the Server
Using HTTP GET Calls Instead of HTTP POST
Working with the this Function
Creating Asynchronous, Transactional, Cache-Friendly Web Services
Scalability Challenges with Web Services
Asynchronous Web Methods
Modifying the ASP.NET AJAX Framework to Handle Web Service Calls
Post a Comment
Building Client-Side Widgets
Delaying Server-Side Widget Loading
Content Proxy
Building a Client-Side RSS Widget
Building a Client-Side Flickr Widget
Optimizing ASP.NET AJAX
Combining Multiple Ajax Calls into One Call
Timing and Ordering Ajax Calls to the Server
Using HTTP GET Calls Instead of HTTP POST
Working with the this Function
Creating Asynchronous, Transactional, Cache-Friendly Web Services
Scalability Challenges with Web Services
Asynchronous Web Methods
Modifying the ASP.NET AJAX Framework to Handle Web Service Calls
Subscribe to Post Comments [Atom]
<< Home
Subscribe to Posts [Atom]