Introduction
I have come across couple of good articles that tell us about creating .NET remote application, but none of these use ASP.NET application as client. Even the MSDN example, Hosting in Internet Information Services (IIS), uses a console application as client.
Background
If the remote object is to be accessed through the internet, one should implement their own security to authenticate the user as .NET remote applications require FullTrust permissions to execute. By hosting remote application under IIS, implementing security becomes much easier especially when the intranet is protected from the outside world by a firewall and the allowed communication channel is HTTP.
Using the Code
Here are the steps to create a server application and client application.
Server Object
- Create a new VB.NET or C# class library
IServer
and replace code in Class1.vb with the following. Compile the project to IServer.dll.
Public Interface IServer
Function getServerTime() As DateTime
End Interface
- Create new VB.NET or C# Class Library project with
clsServer
class which will implement getServerTime
function of interface IServer
.
Public Class clsServer
Inherits MarshalByRefObject
Implements IServer.IServer
Public Overridable Function getServerTime() _
As DateTime Implements IServer.IServer.getServerTime
Return Now.ToString()
End Function
End Class
- I have also included one more function in the demo project to create a file in the server. This will convince the user beyond any doubt that remote object did get activated through transparent proxy. Please make sure that the folder where you want to create the file has write permissions.
- Compile this project into "Server.dll" or any other name that is appropriate.
- Create a new virtual directory, Server under IIS - either by using "Virtual Directory Creation Wizard" or
- Create new folder under c:\Inetpub\wwwroot and rename it to Server.
- Open IIS management console, view properties of the Server folder.
- Click on the Create button against the "Application name", by default new application name will be the name of the folder. Click on OK button to close the properties window.
- Navigate to Server folder in Windows Explorer and create a sub folder "bin" under Server folder.
- Copy "Server.dll" into the bin folder.
- Create new text file, type the following XML code and save it as "web.config" and not as web.config.txt (by selecting "All files" in the Save As dialog box or by enclosing the file name in double quotes in the save dialog box). This XML code declares the service and channel. MSDN has a lot of information about each of these XML attributes that we are coding here.
="1.0" ="utf-8"
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode="Singleton" type="Server.clsServer,
Server" objectUri="server.soap" />
</service>
<channels>
<channel ref="http" />
<serverProviders>
<formatter href="binary" />
</serverProviders>
</channels>
</application>
</system.runtime.remoting>
</configuration>
- The most important attribute that we need to understand is "
type
". In the above example, its value is "Server.clsServer, Server
" which is nothing but "RootNamespace.ClassName, Assembly name
". To find out what these value are for an existing project, just right click on the project name in solution explorer and choose properties. ObjectUri
is something that uniquely identifies this object which is required to invoke this object from client. We can use the other format "Server.rem" .
- The channel that we are using is HTTP and formatter is binary. Please refer to MSDN for alternative channels and formatters. We need to use HTTP here as we are hosting our server object under IIS and binary formatter is more efficient over SOAP formatter.
- At this stage, if you type the URL http://localhost/Server/Server.soap?wsdl in the explorer address bar (assuming that you are hosting the server object in your local system, else replace "localhost" with valid webserver name), you should see the XML output. This XML is what describes the service that we are hosting under IIS.
- It's about time to talk about the client.
ASP.NET Client Application
- Create a new ASP.NET web application.
- We need a reference to the server object before coding any of the function calls. Now we have several options at this stage, you could actually add the server.dll to the references (even though we are not going to use the local objects, this is the laziest way), create a proxy using soapsuds.exe tool or create an interface and reference that interface. Soapsuds tool has a limitation in that you need to create a proxy for each of the class objects in an assembly. Try the following command at .NET command prompt, you should have "proxy.dll" created for you by soapsuds.exe and you can add a reference to this proxy object. But this will not work for assemblies that encapsulate several classes.
- We can also use a more powerful WSDL.exe tool to create proxy class source code which can be included in the project. The remote objects can be created as if they are local to the client.
If you open this file, you will find the URL, http://localhost/server/server.soap in the class constructor. This proxy class will also have other methods like BegingetServerTime
and EndgetServerTime
which are used for making asynchronous calls.
- The other recommended method is to use Interfaces as we are doing in this case. In the client ASP.NET project, add a reference to the ISever.dll.
- Type...
Imports System.Runtime.Remoting
... at the top of the page to use .NET remoting infrastructure.
- Now type the following code in the
Page_Load
event of the WebForm1
.
Private Sub Page_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
Dim objRemote As IServer.IServer
objRemote = Activator.GetObject(GetType(IServer.IServer), _
"http://localhost/server/server.soap")
Response.Write(objRemote.getServerTime())
End Sub
- Press F5 to execute and you should see the time displayed.
Points of Interest
You may be surprised that there is no mention of Client.exe.config or Global.aspx files so far. Client.exe.config file is required only when you want to use "new
" operator instead of Activator.GetObject
method. Having this file is a good idea when the server hosting remote objects is changing often and your code will execute normally by modifying ObjectUri
in client.exe.config file without recompiling the server objects. This can also be achieved (as I do) by specifying remote object's URL as key under appSettings
tag in web.config. This technique is extremely useful when copying projects from development/testing to production environment, all that you have to do is modify these config files to change the remote object's URL!
Another important aspect to remember is, if you want to pass custom class objects as parameters between the client and server application, these objects should be serialized at one end and deserialized at the other end. This can be achieved by implementing ISerializable
interface or by implementing your own methods to convert objects into byte arrays.
References
- Absolute beginner's introduction to remoting
- Simple but potentially useful example of .NET Remoting
- .NET Remoting - Basic Maneuvers
- MSDN
History
- 3rd March, 2005: Initial post
- 1st August, 2009: Updated download file