Using Soapsuds.exe with Remoting
This topic is specific to a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using the Windows Communication Foundation (WCF).
You can use Soapsuds.exe to generate an assembly or source code that contains the required metadata to call a remote object.
Note
Soapsuds.exe only works with remote objects that use the HttpChannel.
To generate an assembly, type a command like the following:
soapsuds.exe -url:https://SomeServer/MyObject.rem?wsdl -oa:MyProxy.dll
Where the remote object is hosted on a machine called SomeServer and the URL for the object is MyObject.rem. Notice the ?wsdl added to the end of the URL. This is required for Soapsuds.exe to work. You then take the generated MyProxy.dll and reference it in your client application.
To generate source code, type a command like the following:
soapsuds.exe -url:https://SomeServer/MyObject.rem?wsdl -gc
Where the remote object is hosted on a machine called SomeServer and the URL for the object is MyObject.rem. Notice the ?wsdl added to the end of the URL. This is required for Soapsuds.exe to work. You can then add the generated Server.cs and add it to your client application project. This has the added benefit of not having to ship a separate proxy assembly with your client application.
Regardless of the type of output (assembly or source code), Soapsuds.exe generates what is called a wrapped proxy by default. The wrapped proxy is a class derived from RemotingClientProxy. The URL to the remote object is hard coded into this derived class. Alternatively you can specify -nowp on the command line to generate a non-wrapped proxy. The class generated for a non-wrapped proxy is an empty class. You can see the differences between wrapped and unwrapped proxies by generating the source code for a remote object twice, once with -nowp and once without (make sure you rename the generated .cs file or else it is overwritten when you run Soapsuds.exe again. You must generate non-wrapped proxies because the URL to the remote object should not be hard coded.
For more information about soapsuds.exe command line options see: Soapsuds Tool (Soapsuds.exe).