После конфигурирования среда Remoting обеспечивает прозрачное использование удаленных объектов. Однако, для такого прозрачного использования клиент должен иметь доступ к сборке с самим объектом, сборка с его интерфейсом недостаточна. Для решения данной проблемы можно либо пожертвовать прозрачностью, воспользовавшись классом System.Activator, или организовать веб службу Remoting на основе SOAP, что позволяет создать посредника на клиенте по спецификации веб службы в формате WSDL. Вариант с веб службой представляется более разумным – если клиент не имеет доступа к сборке удаленного объекта, то, вероятно, клиент и сервер находятся на разных предприятиях, и видимо речь идет о взаимодействии вне доверенной сети.
При использовании класса форматирования SoapFormatter, канала HttpChannel и активируемых сервером объектов среда Remoting позволяет организовать веб службу на основе SOAP, WSDL и кодирования SOAP-RPC (а не SOAP Document, в отличие от служб ASP.NET). В этом случае нет необходимости иметь сборку на клиенте, поскольку, используя методы класса System.Runtime.Remoting.MetadataServices.MetaData, можно получить сборку из описания веб-службы. Для упрощения данной задачи существует утилита soapsuds.exe. Нижеследующая команда записывает в текущий каталог файл с классом, который является наследником System.Runtime.Remoting.Services.RemotingClientProxy, имеет интерфейс удаленного объекта и может быть использован для сборки клиента Remoting.
soapsuds.exe -url:http://localhost:2080/endpoint?wsdl -gc
Следует отметить, что в файле конфигурации клиента по прежнему должно быть указано имя сборки на сервере (оно совпадает с именем файла, созданного утилитой soapsuds.exe). Созданный утилитой soapsuds.exe посредник не будет использоваться в ходе выполнения программы, если используется конфигурация Remoting. Если же клиент не использует метод RemotingConfiguration.Configure, то будет использован посредник, который попытается использовать тот же сервис, который был указан при его создании в его конструкторе.