Generating Metadata from a Compiled Assembly in .NET

Generation QR Code JIS X 0510 in .NET Generating Metadata from a Compiled Assembly

Let s see how we can use the SoapSuds utility to generate a proxy for RemoteCompo nents.dll:

The /ia (Input Assembly) option must be followed by the name of the assembly without the .exe or .dll, whereas the /oa (Output Assembly) option specifies the complete name of the metadata-only assembly you want to create. The /nowp (No Wrapped Proxy) tells SoapSuds to include only the metadata instead of generating a wrapped proxy. (Read on for more information about wrapped proxies.) You can also sign the assembly with a strong name, by using the /sn option:

If you explore the new metadata.dll assembly with ILDASM, you ll see that it contains all the classes and methods in RemoteComponents.dll, but method bodies contain only a minimum amount of code. For all practical purposes, the proxy.dll exposes only metadata. Open the client application with Visual Studio .NET, remove the reference to RemoteComponents.dll, and add a reference to the new metadata.dll. Because the old and the

32:

new assembly expose classes with the same name (including the namespace) and the same methods, the client application will recompile flawlessly. What happens when you run the program, however, depends on whether the client application registers the remote object programmatically or by means of a configura tion file. If you register the remote type programmatically, you don t have to change anything in the client application to have it work with the remote object. In this case, in fact, the client contains a block of code like this:

Dim url As String = tcp://localhost:50000/calculator.rem"

RemotingConfiguration.RegisterWellKnownClientType(GetType(Calculator), url)

The Calculator class is now the one defined in metadata.dll; therefore, the type passed to the RegisterWellKnownClientType method and the type passed to the New keyword match perfectly. If the client application registers the object via a configuration file, you must adjust the identity of the assembly containing the type that is to be requested to the remote server. For example, if the configuration file is

<client> <wellknown type="RemoteComponents.Calculator, RemoteComponents url="tcp://localhost:50000/Calculator.rem /> </client>

you must edit it as follows to have it work with the SoapSuds-generated assembly:

<client> <wellknown type="RemoteComponents.Calculator, Metadata url="tcp://localhost:50000/Calculator.rem /> </client>

When you expose a remote object through an HTTP channel, the .NET remoting archi tecture can intercept requests at the object s URL and react accordingly. If you append WSDL to the object s URL, the .NET Framework responds by sending you a block of XML text that defines the object. You can prove this easily by launching Internet Explorer and typing this URL in its Address field (after starting the host application if necessary):

The XML text returned to the browser is in the same format as the WSDL document that Web services expose. (See Figure 32-7.) The SoapSuds utility can use this WSDL docu ment to generate a metadata-only assembly from a type that is exposed by a remote

Part VII:

server, even if you don t have the original compiled DLL at hand. This feature is espe cially useful if you expose a remote object on your Internet Web site and want to give remote clients the ability to use it.

Figure 32-7

When using SoapSuds to generate the metadata for a remote assembly, you specify the /url option instead of the /ia option:

Check the .NET Framework documentation for more information about other options you can use with SoapSuds for example, the /domain, /username, and /password options that are necessary when accessing a server that requires authentication, or the /httpproxyname and /httpproxyport options that you must use when accessing a remote system through a proxy server.

The two examples illustrated in the previous sections used the /nowp option to tell SoapSuds not to generate a wrapped proxy. A wrapped proxy is a local class that the client application can use in lieu of the remote class, because all its methods and prop erties automatically dispatch the call to the remote object. Here s how you can generate a wrapped proxy for an object at a given URL: