RemotingConfiguration::RegisterWellKnownServiceType Method (WellKnownServiceTypeEntry)
Registers an object Type recorded in the provided WellKnownServiceTypeEntry on the service end as a well-known type.
Assembly: mscorlib (in mscorlib.dll)
[SecurityPermissionAttribute(SecurityAction::Demand, Flags = SecurityPermissionFlag::RemotingConfiguration)] public: static void RegisterWellKnownServiceType( WellKnownServiceTypeEntry^ entry )
Parameters
- entry
- Type: System.Runtime.Remoting::WellKnownServiceTypeEntry
Configuration settings for the well-known type.
| Exception | Condition |
|---|---|
| SecurityException | At least one of the callers higher in the callstack does not have permission to configure remoting types and channels. |
Any client that knows the URI of a registered well-known object can obtain a proxy for the object by registering the channel it prefers with ChannelServices, and activating the object by calling new or the Activator::GetObject method. To activate a well-known object with new, you must first register the well-known object type on the client using the RegisterWellKnownClientType method. Calling the RegisterWellKnownClientType method gives the remoting infrastructure the location of the remote object, which allows the new keyword to create it. If, on the other hand, you use the Activator::GetObject method to activate the well-known object, you must supply it with the object's URL as an argument, so no prior registration on the client end is necessary.
When the call arrives at the server, the .NET Framework extracts the URI from the message, examines the remoting tables to locate the reference for the object that matches the URI, and then instantiates the object if necessary, forwarding the method call to the object. If the object is registered as SingleCall, it is destroyed after the method call is completed. A new instance of the object is created for each method called. The only difference between Activator::GetObject and new is that the former allows you to specify a URL as a parameter, and the latter obtains the URL from the configuration.
The remote object itself is not instantiated by the registration process. This only happens when a client attempts to call a method on the object or activates the object from the client side.
For a detailed description of well-known objects, see [<topic://cpconServerActivation>].
#using <system.dll> #using <system.runtime.remoting.dll> using namespace System; using namespace System::Runtime::Remoting; using namespace System::Runtime::Remoting::Channels; using namespace System::Runtime::Remoting::Channels::Http; using namespace System::Runtime::Remoting::Messaging; using namespace System::Runtime::Serialization; public ref class RemoteObject: public MarshalByRefObject { public: void Method1( LocalObject^ param ) { Console::WriteLine( "Invoked: Method1( {0})", param ); } }; int main() { ChannelServices::RegisterChannel( gcnew HttpChannel( 8090 ) ); WellKnownServiceTypeEntry^ wkste = gcnew WellKnownServiceTypeEntry( RemoteObject::typeid,"RemoteObject",WellKnownObjectMode::Singleton ); RemotingConfiguration::RegisterWellKnownServiceType( wkste ); RemoteObject^ RObj = dynamic_cast<RemoteObject^>(Activator::GetObject( RemoteObject::typeid, "http://localhost:8090/RemoteObject" )); LocalObject^ LObj = gcnew LocalObject; RObj->Method1( LObj ); Console::WriteLine( "Press Return to exit..." ); Console::ReadLine(); }
- SecurityPermission
for configuration of the remoting infrastructure. Demand value: SecurityAction::Demand; Permission value: SecurityPermissionFlag::RemotingConfiguration
Windows 7, Windows Vista SP1 or later, Windows XP SP3, Windows XP SP2 x64 Edition, Windows Server 2008 (Server Core not supported), Windows Server 2008 R2 (Server Core supported with SP1 or later), Windows Server 2003 SP2
The .NET Framework does not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.