ASP.NET 2.0 does great things but like its ancestors also has holes: things we need to do but can't -- or can't without dodging around it with inside knowledge, JScript and other tricks. AspNet2Holes is about those holes and the ways to step around them.

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( . . . . . . . . }

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.

About Me

Craig BolonCommercial software development over 25 years in Windows and Linux, before that in DOS, Unix, VMS and several others, more than 20 languages. Working now mostly in ASP.NET with C#, SQL and JavaScript.
View my complete profile