9.7 Hosting Objects in IIS | Object-Oriented Programming with Visual Basic .NET

only for RuBoard

One of the biggest benefits of using IIS over a Windows Service is security. It is trivial to configure the remote object to use Windows Authentication to validate an incoming call. Drawbacks include limited configuration options and communication that is restricted to the HttpChannel (which means slower performance). However, you can configure the channel to use binary formatting (versus SOAP), which is somewhat better, performance-wise. The only other requirement is that the hosted object be derived from MarshalByRefObject .

IIS should already be configured at this point. All the necessary assemblies should be in place. If not, review Section 6.1 earlier in the chapter and configure accordingly . Only one addition should be made; a configuration file containing the appropriate entries must be placed in the ServerInfo virtual directory.

9.7.1 Web.config

The good news is that the configuration file from Example 9-10 can be used as a starting point; just copy it and rename the copy to Web.config . Before placing it in the ServerInfo virtual directory, make these two important changes:

Remove the name attribute from the <application> element. The application name is determined by the name of the virtual directory defined in IIS, not the configuration file. An exception will be thrown otherwise .
Make sure the objectUri is unique. If the Windows Service is still used concurrently with this example, change the objectUri value to something that denotes that it is served from IIS.

When all is said and done, Web.config should look similar to this:

 <configuration>   <system.runtime.remoting>  <application> <! --  cannot define application name  -- >  <service>         <wellknown mode="Singleton"             type="ObjectServerSpace.ServerInfoFactory, ServerInfo"           objectUri="ServerInfoFactoryWeb.rem" />       </service>     </application>   </system.runtime.remoting> </configuration>

That's all there is to it. Copy the file to ServerInfo and make sure the bin directory contains a version of ServerInfo that is derived from MarshalByRefObject . To be safe, restart the web server. Many sources say that restarting the server is not necessary, but testing indicates otherwise.

9.7.2 Client for IIS-Hosted Remote Object

To work, the client configuration file from Example 9-12 needs a few modifications. First, an HttpChannel must be added that uses the binary formatter ( slightly better performance). The formatter does not have to be specified on the server side because the HttpChannel is set up to use both. The client decides which one to use. The modified configuration file is as follows :

 <!-- remoteclient.exe.config --> <configuration>   <!-- No longer used   <appSettings>     <add key="location" value="http://192.168.1.100/ServerInfo/bin/" />     <add key="assembly" value="ServerInfo" />   </appSettings> -->  <system.runtime.remoting>   <application>   <channels>   <channel ref="http">   <clientProviders>   <formatter ref="binary"/>   </clientProviders>   </channel>   </channels>   </application>   </system.runtime.remoting>  </configuration>

Until now, the client has used its configuration file only for custom application settings. Now that there are remoting settings, the client must be modified in order to use them. This modification is done in exactly the same manner as the server, by calling RemotingConfiguration.Configure .

The client from Example 9-13 can be modified easily to accommodate these changes. Remove the block marked "Download ServerInfo.dll" and replace it with the following line of code:

 RemotingConfiguration.Configure("remoteclient.exe.config")

The only other mandatory change is the call to Activator.GetObject . The URL needs to be changed to point to the <wellknown> object exposed from IIS:

 Dim factoryObj As Object = _       Activator.GetObject(GetType(IServerInfoFactory), _         "http://192.168.1.100/ServerInfo/ServerInfoFactoryWeb.rem") Example 9-14 contains the final client listing. Example 9-14: Client for IIS-hosted object     'vbc /t:exe /r:system.dll /r:system.runtime.remoting.dll '/r:ServerInterfaces.dll remoteclient.vb     Imports System Imports System.Net Imports System.Runtime.Remoting Imports System.Threading     Imports ServerInterfaces     Public Class Client       Public Shared Sub Main( )         Try           RemotingConfiguration.Configure("remoteclient.exe.config")           Dim factoryObj As Object = _       Activator.GetObject(GetType(IServerInfoFactory), _         "http://192.168.1.100/ServerInfo/ServerInfoFactoryWeb.rem")           Dim factory As IServerInfoFactory = _          CType(factoryObj, IServerInfoFactory)           Dim si As IServerInfo = factory.CreateServerInfo( )           If Not (si Is Nothing) Then         Console.WriteLine(si.MachineName)         Console.WriteLine(si.IPAddress)         Console.WriteLine(si.GetMachineTime)         Console.WriteLine("{0}MB Free", si.GetAvailableMemory)         Console.WriteLine("Processor Used: {0}", si.GetProcessorUsed)       End If             Catch e As Exception       Console.WriteLine(e.GetType( ).FullName)       Console.WriteLine(e.Message)     End Try         Console.WriteLine("Hit ENTER to continue...")     Console.ReadLine( )       End Sub     End Class

Rewriting the Windows Service to accept the application name as a custom configuration setting would be better than specifying it in the <application> element. The application name could be retrieved from the config file and registered programmatically. This would allow the server config file to be used interchangeably as a Web.config file.

only for RuBoard