Before I jump into this, I just want to explain that Remoting is an old .Net v1.1 technology and it is no longer supported. However it still gets the job done if that is what you are using already or if you need a really old code to talk to a really new code and you are not at liberty to use WCF. The following example I am going to provide shows .Net v2.0 talking to .Net v4.0. If you have the opportunity to design something from scratch with the time to learn how to do it correctly; please use WCF instead of Remoting. There is no point in using old coding if you can use the new stuff.

Introduction to Remoting

In this example you need to understand that there are two parts to Remoting always, there is the Client or Consumer and the Proxy or Remoting Server. Remoting is great for exposing parts of a dll to an older .Net version or to avoid dll hell in a sense. You can have a centralized location for your main or base dll and just have other components point to it. The benefit here is to not have to make sure that all locations have an exact copy of the latest dll (hence the mention of dll hell).

Remoting Anatomy

There are some basic parts that are involved in remoting and keep in mind a lot of these same concepts are now used in WCF. Remoting requires the following to work:

1. You must use Remoting locally, it will not work across the net and it isn’t safe to attempt it either. Not to mention that it would kill performance.
2. You must have an Interface Library and that library must be identical for the client and the proxy.
3. You must have a Remoting Project (you could probably get away without having it, but for simplicity’s sake just have one).
4. You must be able to host these projects in IIS. I have done this with IIS 5, 6 and 7. Trying to use casini in this case is just a pain in the ass, just use IIS.

Project Descriptions:

On to the Code. How does this all work?

Code Snippets

BaseWebApp

I like returning the current time because it is something that is constantly updating without me having to do it myself and it lets you know if something is working right now.

RSInterfaceLibrary

1. Take the stock class and rename it to “InterfaceLibrary.cs” (for this example I am not using the proper naming convention of IClassName to be more clear)
2. Use the following code:

public interface InterfaceLibrary
{
    string GetUsefulData();
}

RemotingServer

1. Take the stock class and rename it to “Gateway.cs”
2. Make a project reference or dll reference to the “BaseWebApp.dll”
3. Make a project reference to the “RSInterfaceLibraray” project
4. Open “Gateway.cs” and replace the code with this code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using BaseWebApp.BusinessObjects;

namespace RemotingServer
{
    public class Gateway : MarshalByRefObject, RSInterfaceLibrary.InterfaceLibrary
    {
        public string GetUsefulData()
        {
            return BaseObject.UsefulData();
        }
    }
}

PublicWebService

1. Make a project reference to the “RSInterfaceLibraray” project
2. Add a class called “RemotingLogic.cs”
3. Add the following code to this class:

   public static InterfaceLibrary GetProxyObject()
   {
       string strURL = System.Configuration.ConfigurationManager.AppSettings["remotingServerURL"];
   
       return (InterfaceLibrary)Activator.GetObject(typeof(InterfaceLibrary), strURL);
   }
   

4. Add the following code to the “Service1.asmx.cs” code behind:

   [WebMethod]
   public string GetUsefulInfoViaRemoting()
   {
       InterfaceLibrary proxy = RemotingLogic.GetProxyObject();
   
       return proxy.GetUsefulData();
   }
   

5. Host this web service in IIS using what ever name you want.

Configuration Files

• Client or Consumer Side – You can use this configuration in any kind of consumer that I know of. Web.Config or App.Config. Here is the configuration value for the Web Service side:

    
  Missing snippet    
    
  
  

  This indicates the direction or location of the remoting server. If you navigate to it you will get an HTTP 500 error, so don’t bother it doesn’t work that way.

• Proxy or Remoting Server Side – I have only ever used this configuration with a web application, I don’t know what else this could be used with.

      
        Missing snippet
          
        
      
   
  

  This is what exposes the remoting server on the web application. It piggy backs off of it, like a parasite on its host.

After implementing all of the above, make sure to compile everything and most importantly for the BaseWebApp and the RemotingServer you need to move the “RemotingServer.dll” and “RSInterfaceLibrary.dll” to the BaseWebApp’s bin folder. If you did everything right then this should work right off the bat.

One of the most confusing parts about the configuration is the Web Application’s side. Here is the explanation:

Missing snippet - lost when porting from Blogger.

I got this information from here: http://social.msdn.microsoft.com/Forums/eu/netfxremoting/thread/cb2681e7-2b06-4dcd-af65-fed5981b93d8

There is ton’s more that can be done with this stuff. I recommend that if you are going to have multiple remoting servers for the same application don’t bother creating multiple projects, you can just use the same projects and just make sure to configure them properly. Here is an example:

    
Missing snippet - lost when porting from Blogger.

This indicates that you have two additional classes “Gateway2.cs” in the remoting server project and “InterfaceLibrary2.cs” in the interface library project. I used the number 2 just to indicate that it is a second pipeline, but you can call it what ever you want.

Enjoy.