Depending on your problem .NET remoting may be an awesome life saver. If you have hundreds of drivers, many configurations and independent client applications it can be the module which holds all the pieces together if your design is more or less correct.

Because it worked so well, somebody came up with the idea to store user controls in those drivers. First it seems like a very cool idea “a driver can provide a piece of GUI abstracted behind an interface which can be shown to the advanced user so he can change options”.

If you think more about it however, it causes more problem than it actually solves (localization + customization, anybody?) and you may get burned by this constant application highjacking where you include anonymous user controls all the time. Anyway, that somebody was from “management” and so I had to implement a prototype.

Well, after a full day of prototyping I can tell you that it won’t work (well it does somehow, but shhh )

The problem we have is that all those user control classes extend indirectly from the type MarshalByRefObject (some kind of remotable proxy) like maybe half of the framework does. Now when you invoke such a control directly from your service two things may happen

• The user control gets invoked in the server’s app domain and fails to set up a message queue when the server is wrapped in a Windows service.
• The user control is able to set up a message queue but cannot run because its distributed logic needs to access private methods which does not work as that part is in the server’s app domain.

The ugly solution:

“Give me the type of the user control and invoke it in my app domain.”

which translates into following code (assuming a constructor with one parameter)

Object o = this.localInstanceOfUIType.GetConstructor(new Type[] { typeof( String) } ).Invoke( new Object[] { "Form1" } );
if( o is Control )
  this.Controls.Add( (Control)o);

Of ):

Tags: c#, remoting