(-s).
configfilegen -ia:RemoteHello.dll -ос:HelloServer.exe.config -s -a
Системный администратор использует утилиту .NET Admin, чтобы реконфигурировать существующие конфигурационные файлы. Утилиту .NET Admin можно запустить с помощью команды:
mmc mecorcfg.msc
При помощи этой утилиты можно изменить значения времени жизни, URI удаленных объектов и свойства канала.
Приложения хостинга
До этого момента все примеры серверов выполнялись на автономных (self-hosted) серверах .NET. Автономный сервер должен запускаться вручную. Удаленный сервер .NET может запускаться во множестве других типов приложений. В службе Windows сервер автоматически запускается во время старта, и кроме того, процесс может выполняться с полномочиями системной учетной записи. Создание служб Windows описано в главе 24.
Хостинг удаленных серверов в ASP.NET
B ASP.NET существует специальная поддержка для серверов .NET Remoting. ASP.NET может использоваться для автоматического запуска удаленных серверов. В противоположность приложениям exe, ASP.NET Remoting использует для конфигурации другой файл.
Для того чтобы использовать инфраструктуру Информационного сервера Интернета (IIS) и ASP.NET, необходимо создать класс, произвольный из System.MarshalByRefObject, который имеет конструктор по умолчанию. Использованный ранее код для нашего сервера с целью создания и регистрации канала больше не требуется; это делается средой выполнения ASP.NET. Необходимо только создать виртуальный каталог на сервере Web, который отображает каталог, куда помещается конфигурационный файл web.config. Сборка удаленного класса должна находиться в подкаталоге bin.
Чтобы сконфигурировать виртуальный каталог на сервере Web, воспользуйтесь Информационными службами ММС. Выберите Default Web Site и, открыв меню Action, создайте новый виртуальный каталог.
Конфигурационный файл web.config на сервере Web должен быть помещен в домашний каталог виртуального сайта Web. Согласно используемой по умолчанию конфигурации IIS, используемый канал слушает порт 80.
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode='SingleCall' type='Wrox.ProfessionalCSharp.Hello, RemoteHello' objectUri = 'HelloService.soap' />
</service>
</application>
</system.runtime.remoting>
</configuration>
Клиент может теперь соединиться с удаленным объектом, используя следующий конфигурационный файл. URL, который должен быть определен здесь для удаленного объекта, является локальным хостом сервера Web, за ним следует имя приложения Web RemoteHello, которое было определено при создании виртуального сайта Web и URI удаленного объекта HelloService.soap, определенного в файле web.config. Не обязательно определять порт номер 80, так как это порт по умолчанию для протокола http:
<configuration>
<system.runtime.remoting>
<application>
<client url='http:/localhost/RemoteHello'>
<wellknown type='Wrox.ProfessionalCSharp.Hello, RemoteHello' url='http://localhost/RemoteHello/HelloService.soap' />
</client>
<channels>
<channel type='System.Runtime.Remoting.Channels.Http.HttpChannel, System.Runtime.Remoting' />
</channels>
</application>
</system.runtime.remoting>
</configuration>
Хостинг удаленных объектов в ASF.NET поддерживает только хорошо известные объекты.
Классы, интерфейсы и SOAPSuds
В клиент/серверных примерах, которые были выполнены до сих пор, мы всегда ссылались на удаленные объекты в клиентском приложении. В этом случае копируется код CIL удаленного объекта, хотя нужны только метаданные. Также невозможно, чтобы клиент и сервер программировались независимо. Значительно лучшим способом является использование вместо этого интерфейсов или утилиты SoapSuds.exe.
Интерфейсы
Мы имеем четкое разделение клиентского и серверного кода с помощью интерфейсов. Интерфейс просто определяет методы без реализации. Мы отделяем контакт между клиентом и серверов от реализации. Вот необходимые шаги для использование интерфейса:
1. Определить интерфейс, который будет помещен в сборку.
2. Реализовать интерфейс в классе удаленного объекта. Чтобы сделать это, необходимо сослаться на сборку интерфейса.
3. На серверной стороне не требуется больше никаких изменений. Сервер можно программировать и конфигурировать обычным образом.
4. На клиентской стороне сошлитесь на сборку интерфейса вместо сборки удаленного объекта.
5. Клиент может теперь использовать интерфейс удаленного объекта, а не класс удаленного
