Building a Basic .NET Remoting Application 之二 Building a Host Application
2010-01-04 15:14
495 查看
Building a Host Application
By itself, the
Choose and register a channel, which is an object that handles the networking protocols and serialization formats on your behalf.
Register your type with the .NET remoting system so that it can use your channel to listen for requests for your type.
The .NET Framework includes two default channels, HttpChannel (which uses SOAP formatting) and TcpChannel (which uses binary formatting). HttpChannel is a good channel to start with because in some scenarios it can be used through firewalls without opening a port, and it supports standard security and authentication protocols. For more information about choosing channels that suit your scenario, see Channels.
You can build listener applications using any type of application domain — a Windows Forms application, an ASP.NET Web application, a console application, a Windows Service (also known as a Windows NT Service), or any other managed application domain. Because remote configuration is done on a per-application-domain basis, the application domain must be running to listen for requests.
Configuration can be done programmatically or by using an application or machine configuration file. The following code implements a simple
[C#]
// Listener.cs
using System;
using System.Runtime.Remoting;
public class Listener{
public static void Main(){
RemotingConfiguration.Configure("Listener.exe.config");
Console.WriteLine("Listening for requests. Press Enter to exit...");
Console.ReadLine();
}
}
To compile this class into a host or listener executable using the command-line tools that ship with the .NET Framework SDK, save it as
[C#]
csc /noconfig /r:RemotableType.dll Listener.cs
In this example, the file name is:
[C#]
Listener.cs
The
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown
mode="Singleton"
type="RemotableType, RemotableType"
objectUri="RemotableType.rem"
/>
</service>
<channels>
<channel ref="http" port="8989"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>
The remoting system uses the information in this file to listen for and route remote requests to an instance of a remotable type. The file specifies the Singleton server-activation mode, the type name and assembly of the type on behalf of which it is to listen, and the object Uniform Resource Identifier (URI) or external name of the object. (For more details about object URIs and remoting, see Activation URLs.) The file also tells the remoting system to listen for requests on port 8989 using the system-provided HttpChannel.
By itself, the
RemotableTypeclass defined in the Building a Remotable Type topic is not special. To enable objects in other application domains to create instances of this object remotely, you must build a host or listener application to do two things:
Choose and register a channel, which is an object that handles the networking protocols and serialization formats on your behalf.
Register your type with the .NET remoting system so that it can use your channel to listen for requests for your type.
The .NET Framework includes two default channels, HttpChannel (which uses SOAP formatting) and TcpChannel (which uses binary formatting). HttpChannel is a good channel to start with because in some scenarios it can be used through firewalls without opening a port, and it supports standard security and authentication protocols. For more information about choosing channels that suit your scenario, see Channels.
You can build listener applications using any type of application domain — a Windows Forms application, an ASP.NET Web application, a console application, a Windows Service (also known as a Windows NT Service), or any other managed application domain. Because remote configuration is done on a per-application-domain basis, the application domain must be running to listen for requests.
Note Unlike COM, remoting does not start the host or server application for you. This is an important difference between .NET remoting and remote activation in COM.
Configuration can be done programmatically or by using an application or machine configuration file. The following code implements a simple
RemotableTypehost application domain that uses a configuration file. (Using a configuration file enables you to change the remoting configuration without recompiling your executable, among other things.) For details on the configuration of the .NET remoting infrastructure, see Configuration.
[C#]
// Listener.cs
using System;
using System.Runtime.Remoting;
public class Listener{
public static void Main(){
RemotingConfiguration.Configure("Listener.exe.config");
Console.WriteLine("Listening for requests. Press Enter to exit...");
Console.ReadLine();
}
}
To compile this class into a host or listener executable using the command-line tools that ship with the .NET Framework SDK, save it as
Listener.language-extension (or use another file name of your choice, where the language extension is the language you want to compile). Save the file in the same directory in which you saved the
RemotableType.dllthat you built in the Building a Remotable Typetopic. At the command prompt in that directory, type the following command:
[C#]
csc /noconfig /r:RemotableType.dll Listener.cs
In this example, the file name is:
[C#]
Listener.cs
The
Listenerclass must be able to find the
Listener.exe.configfile to load the configuration for the
RemotableTypeclass. This configuration file should be saved in the same directory as
Listener.exe, or it will not be found and an exception will be thrown. The following code shows the
Listener.exe.configconfiguration file for this listening or host application domain.
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown
mode="Singleton"
type="RemotableType, RemotableType"
objectUri="RemotableType.rem"
/>
</service>
<channels>
<channel ref="http" port="8989"/>
</channels>
</application>
</system.runtime.remoting>
</configuration>
The remoting system uses the information in this file to listen for and route remote requests to an instance of a remotable type. The file specifies the Singleton server-activation mode, the type name and assembly of the type on behalf of which it is to listen, and the object Uniform Resource Identifier (URI) or external name of the object. (For more details about object URIs and remoting, see Activation URLs.) The file also tells the remoting system to listen for requests on port 8989 using the system-provided HttpChannel.
Note Although there are only a few settings in the preceding configuration file, most of the problems using .NET remoting occur because some of these settings are either incorrect or do not match the configuration settings for client applications. It is easy to mistype a name, forget a port, or neglect an attribute. If you are having problems with your remoting application, check your configuration settings first.
相关文章推荐
- Building a Basic .NET Remoting Application 之一 Building a Remotable Type
- Building a Basic .NET Remoting Application 之五 Basic Remoting Task List
- Building a Basic .NET Remoting Application 之三 Building a Client Application
- Building a Basic .NET Remoting Application
- Building a Basic .NET Remoting Application 之四 Compiling and Running the Basic Application
- 资料:OpenNETCF 和 OpenNETCF Building a Wi-Fi Discovery Application with the .NET Compact Framework
- .NET Remoting Basic(4)-客户端调用方式
- Microsoft .Net Remoting系列教程之二:Marshal、Disconnect与生命周期以及跟踪服务
- Self-Host c#学习笔记之Application.DoEvents应用 不用IIS也能執行ASP.NET Web API
- Microsoft .Net Remoting系列专题之二:Marshal、Disconnect与生命周期以及跟踪服务
- Microsoft .Net Remoting系列专题之二:Marshal、Disconnect与生命周期以及跟踪服务
- Microsoft .Net Remoting系列专题之二
- How to deploy a .Net Remoting Host Server(Server Activated Objects)
- Microsoft .Net Remoting系列专题之二
- .Net Remoting Application Architecture
- Microsoft .Net Remoting系列专题之二 (转载)
- Microsoft .Net Remoting系列专题之二:Marshal、Disconnect与生命周期以及跟踪服务
- Building the DotNetNuke Module in Normal Asp.net Application
- .NET Remoting Basic(5)-多服务器访问和程序集共享
- Microsoft .Net Remoting系列专题之二:Marshal、Disconnect与生命周期以及跟踪服务