В Visual Studio 2008® и .NET Framework 3.5® появились новые средства и возможности поддержки, расширяющие функциональность среды Windows® Communication Foundation (WCF). Базовые возможности WCF 1.0 (выпущенной вместе с .NET Framework 3.0) не подверглись изменениям - они были расширены и дополнены.
В Visual Studio 2008 были автоматизированы некоторые задачи, которые прежде выполнялись в WCF вручную (в частности обновление ссылок прокси). Разработчикам теперь не придется по несколько раз выполнять одни и те же задачи, например создавать элементарные проекты размещения. Кроме всего прочего, в Visual Studio были решены такие непростые проблемы, как перекрестное нацеливание и совместное использование типа контракта данных. В данное статье мы рассмотрим новые функции, перечислим их преимущества и коснемся возможных проблем и путей их решения. Хотя в примерах будут использоваться параметры проектов на языке C#, все сказанное будет относиться и к Visual Basic® (если в статье не оговорено обратное).
Перекрестное нацеливание в .NET Framework
В предыдущих выпусках Visual Studio можно было создавать программы, нацеленные только на ту версию платформы .NET Framework, вместе с которой система Visual Studio и поставлялась. К примеру, в Visual Studio 2005 можно было создавать сборки только для .NET Framework 2.0. В действительности же разработчики сталкиваются с несколько иными задачами: им зачастую приходится поддерживать старые версии приложений, созданные в предыдущих версиях платформы .NET, а в то же время при обновлении приложений они уже работают с новой версией Visual Studio.
Кроме того, такое однозначное нацеливание не позволяло разработчикам, обеспечивающим поддержку приложений, созданных в старых версиях платформы .NET Framework, пользоваться преимуществами новых версий, например возможностью переработки кода, реализованной в Visual Studio 2005.
Проблема, строго говоря, состояла в отсутствии возможности перекресного нацеливания при выборе версий .NET Framework. Разработчику приходилось либо устанавливать несколько версий Visual Studio одновременно, либо компенсировать отсутствие этой возможности раздельным тестированием и развертыванием сборок. В Visual Studio 2008 была реализована адекватная (хотя и несовершенная) поддержка нескольких версий .NET Framework. Поскольку .NET Framework 3.0 и .NET Framework 3.5 фактически используют ту же версию среды CLR, что и .NET Framework 2.0, и различие состоит только в связанных сборках, Visual Studio по-прежнему позволяет разрабатывать приложения для текущей версии исполняющей среды и при этом обеспечивает поддержку .NET Framework версий 2.0, 3.0 и 3.5 (обратите внимание: номера серий .NET Framework соответствуют номерам выпусков, а не версиям исполняющей среды; исполняющая среда остается прежней - CLR 2.0).
В Visual Studio 2008 в панели приложений (в свойствах проекта) появилось новое поле со списком под названием Target Framework, в котором можно выбрать требуемую версию .NET Framework: 2.0, 3.0 или 3.5 (см. рис. 1).
Рис. 1 Свойство целевой версии платформы в Visual Studio 2008
Это значение используется только во время разработки; во время выполнения оно не играет никакой роли, поскольку версия среды (.NET 2.0 CLR) не изменилась. Значение, которые вы выберете, должно соответствовать самой старой версии платформы .NET Framework, на основании которой будет создаваться сборка. Для новых проектов по умолчанию задается версия .NET Framework 3.5. При добавлении ссылок возникают дополнительные сложности: если вы выбираете более старую версию в панели приложений, а ссылки создаете для сборки, созданной в более новой версии платформы, то Visual Studio 2008 выдает предупреждение, ссылка помечается как недействительная, и сборка не создается. Visual Studio 2008 не позволяет добавлять ссылки на сборки .NET Framework, требующие более высокой версии платформы, нежели та, в которой создается проект. Если вы добавите ссылку на проект, требующий более высокой версии платформы, Visual Studio 2008 сообщит вам о том, что возможен конфликт версий. Если же вы добавите ссылку путем непосредственного перехода к сборке, Visual Studio 2008 вас не станет останавливать.
Что касается влияния языков на возможность перекрестного нацеливания, обратите внимание на то, что в C# (в отличие от Visual Basic) вы можете ограничить использование, например, анонимных типов и методов расширения в проекте, создаваемом в .NET Framework 2.0 или 3.0, указав версию компилятора. Для этого нужно в панели Build (Сборка) нажать кнопку Advanced (Дополнительно) и выбрать версию языка ISO-2 (C# 2.0) вместо той, которая установлена по умолчанию (пока единой для всех стандартной версии нет).
Когда вы открываете проект Visual Studio 2005 WCF в Visual Studio 2008, версия платформы (2.0) сохраняется. Хотя с проектом можно работать и так (поскольку версия исполняющей среды не изменилась), я рекомендую вручную выбрать версию 3.0 или 3.5 - в зависимости от имеющихся требований.
Версия требуемой среды .NET Framework больше всего отражается на возможности использовать новые шаблоны проектов. Проекты рабочих процессов и распределений WCF должны создаваться для .NET Framework 3.5, проекты библиотеки служб - для .NET Framework 3.0 или 3.5. Функция добавления ссылки на службу (ее мы рассмотрим далее) доступна, только если для проекта выбрана версия платформы 3.0 или 3.5.
Узел, предоставляемый WCF
В Visual Studio 2008 имеется готовый универсальный узел для размещения служб WcfSvcHost.exe. Он расположен в папке C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE. Чтобы удобнее было работать с ним, можно этот адрес добавить в системную переменную Path. WcfSvcHost - это простая программа командной строки, имеющая два параметра: путь к файлу сборки .NET, содержащей классы службы, и путь к файлу CONFIG узла, на котором размещаются службы. Например так:
WcfSvcHost.exe /service:MyService.dll /config:App.config
Сборка службы может представлять собой сборку библиотеки классов (DLL) или сборку приложения (EXE). Узел WcfSvcHost запустит новый процесс, в котором будут автоматически размещаться все классы, перечисленные в файле CONFIG в разделе служб. Стоит отметить, что классы служб, равно как и контракты служб и данных, не обязательно должны быть открытыми - это могут быть внутренни классы. Кроме того, при саморазмещении службам не обязательно предоставлять метаданные, но в случае необходимости они могут это делать.
WcfSvcHost - это приложение Windows Forms. При его запуске в области уведомлений появляется значок. Чтобы закрыть узел, нужно щелкнуть этот значок правой кнопкой мыши и в контектсном меню выбрать команду "Выход". Выход таким способом выполняется довольно жестко: узел WcfSvcHost прерывает все выполняемые вызовы, а клиенты с высокой долей вероятности получают исключение. Если щелкнуть значок WcfSvcHost в области уведомлений, появится диалоговое окно со списком размещенных служб (см. рис. 2).
Рис. 2 Список WcfSvcHost Services
В этом же окне отображается состояние службы и адрес ее метаданных - его можно скопировать в буфер, и использовать, к примеру, для добавления ссылки на службу. Если закрыть окно WcfSvcHost, то оно просто свернется в значок в области уведомлений.
WcfSvcHost был создан для того, чтобы во время разработки можно было не использовать дополнительный узел для размещения библиотеки службы. Разработка подобных проектов размещения - задача, которую выполняют постоянно. Размещающие узлы обычно содержат один и тот же код, а при наличии нескольких библиотек служб решение значительно разрастается. Для целей разработки и тестирования узел WcfSvcHost можно интегрировать в проекты создания библиотек служб в Visual Studio 2008. Для этого в панели отладки (в свойствах проекта) нужно задать WcfSvcHost.exe в качестве внешней вызываемой программы, а указать имя библиотеки классов и файла CONFIG (он автоматически создается и копируется в папку bin).
После этого при запуске библиотеки классов (раньше это было вообще невозможно) она автоматически размещается на узле WcfSvcHost, и к процессу прикрепляется отладчик. Если остановить отладку, работа узла в Visual Studio 2008 завершится некорректно.
Узел WcfSvcHost можно даже использовать в приложениях .NET Framework 3.0 и проектах Visual Studio 2005, поскольку для работы узла требуется только платформа .NET Framework 3.0. Для этого узел WcfSvcHost нужно просто скопировать с того компьютера, на котором установлена система Visual Studio 2008. Чтобы упростить работу, можно добавить WcfSvcHost в глобальный кэш сборок на том компьютере, где установлена платформа .NET Framework 3.0.
И последняя функция WcfSvcHost - это возможность автоматического запуска клиентских приложений и предоставление клиенту дополнительных параметров, используемых в приложении:
WcfSvcHost.exe /service:MyService.dll /config:App.config
/client:MyClient.exe /clientArgs:123,ABC
Эта функция может использоваться при автоматическом тестировании и в простейших сценариях развертывания для обеспечения запуска обеих частей системы - и размещающего узла, и клиента.
Главным недостатком узла WcfSvcHost является его способность работать только с простейшими задачами, не предполагающими ни программного доступа к экземпляру узла перед его открытием, ни программного доступа к модели событий после. В отличие от служб IIS или службы активации Windows этот узел не поддерживает размещение фабрики узла службы. Вследствие этого отсутствует возможность динамически добавлять базовые адреса, настраивать конечные точки, ускорять вызовы, настраивать пользовательские варианты поведения на уровне узла и т. д. Опыт работы с WCF показывает, что лишь в какиех-то простейших ситуациях можно обойтись без программного доступа к экземпляру хоста, поэтому я не считаю, что узел WcfSvcHost может полноценно применяться в производственной среде наравне со службой активации Windows или выделенным размещающим узлом.
Тестовый клиент, предоставляемый WCF
Кроме узла для размещения служб в Visual Studio 2008 имеется универсальный тестовый клиент, позволяющий выполнять простейшее тестирование операций большинства служб. При стандартной установке тестовый клиент, WcfTestClient.exe, располагается в папке C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE. Ему требется единственный аргумент командной строки с указанием адреса метаданных службы, которую вы намерены тестировать:
WcfTestClient.exe http://localhost:9000/
В качестве значения аргумента можно указать любой адрес метаданных, к примеру HTTP-GET, или конечную точку метаданных с доступом по пртоколу HTTP, TCP или IPC (именованные каналы). Можно указывать сразе несколько адресов:
WcfTestClient.exe http://localhost:8000/ net.tcp://localhost:9000/MEX
Клиент WcfTestClient - это приложение Windows Forms 3.5 (см. рис. 3). Дерево в левой части содержит тестируемые службы и соответствующие конечные точки. Вы можете открыть контракт любой конечной точки и выбрать операцию. Информация, связанная с подобным вызовом, отображается на вкладке в правой панели. В качестве примера можно привести элементарный контракт и реализацию, представленные на рис. 4.
Figure 4 A Sample Service
[ServiceContract]
interface IMyContract
{
[OperationContract]
string MyMethod(int someNumber,string someText);
}
class MyService : IMyContract
{
public string MyMethod(int someNumber,string someText)
{
return "Hello";
}
}
Рис. 3 Использование WcfTestClient
На вкладке методов, в разделе Request (Запрос) указывается целочисленное значение и строка, выступающие в роли параметров операции (см. рис. 3). Когда вы нажмете кнопку Invoke (Вызвать), будет выполнен вызов службы, а в разделе Response (Ответ) появятся возвращенные значения или выходные параметры. Если операция является односторонней, клиент WcfTestClient уведомит об успешном выполнении операции. В случае исключения появится сообщение с информацией о нем, и вам будет предложено выполнить повторный вызов.
Клиент WcfTestClient не поддерживает сеансы транспортного уровня (равно как и любые другие сеансы) с тестируемой службой. Все вызовы выполняются с использованием нового экземпляра прокси. Кроме того, вызовы выполняются асинхронно, поэтому интерфейс продолжает работать, но несмотря на это клиент WcfTestClient не позволяет выполнять несколько вызовов одновременно.
Клиент WcfTestClient создает сборку на основании файла прокси и файла CONFIG, а затем загружает ее из временной папки. Если щелкнуть в дереве элемент Config File, можно увидеть тот самый файл CONFIG, который использвоался при создании сборки (он создавался при добавлении ссылки на службу). Файл можно открыть на отдельной вкладке.
В отличие от старой тестовой страницы веб-служб ASMX в Visual Studio клиент WcfTestClient позволяет вызывать операции, содержащие перечисления, составные параметры, к примеру классы и структуры, состоящие из нескольких классов или структур, и даже коллекции и массивы параметров. Для этого нужно раскрыть соответствующие узлы в разделе Request, задать значения в раскрывающихся списках (к примеру перечисления) и выполнить вызов. Если операция допускает использование коллекции или массива, вам также нужно будет указать его длину. К примеру, запрос и ответ для следующей операции показаны на рис. 5:
Рис. 5 Указание длины и значений массива
[OperationContract] bool ProcessNumbers(int[] numbers
На панели Response также будут указаны возвращенные составные значения или выходные параметры. Здесь мы сталкиваемся с определенным недостатком клиента WcfTestClient: чтобы протестировать другую службу, приходится закрывать клиент, менять аргументы командной строки и снова запускать его. Было бы удобнее иметь возможность указывать адрес службы и в графическом интерфейсе тоже.
Клиент WcfTestClient можно интегрировать в решение Visual Studio 2008. Для этого сначала нужно добавить проект библиотеки классов в решение и удалить все ссылки, папки и исходные файлы: они вам не понадобятся. После этого нужно установить клиент WcfTestClient.exe в качестве внешней вызываемой программы и указать адрес метаданных (или несколько адресов) теструемой службы (или служб), к примеру адрес SVC проекта, размещенного на IIS или WAS, или любой другой адрес метаданных проекта размещения, неважно, входит он в ваш проект или нет.
Следует отметить, что клиент WcfTestClient невозможно использовать, если на компьютере установлена только платформа .NET Framework 3.0, поскольку клиент использует внутренний элемент управления .NET Framework 3.5 типа "сетка" (используемый для представления составных параметров).
Клиент WcfTestClient и узел WcfSvcHost можно использовать вместе для автоматического размещения службы в библиотеке служб и для ее тестирования:
WcfSvcHost.exe /service:MyService.dll /config:App.config
/client:WcfTestClient.exe
/clientArgs:http://localhost:9000/
При использовании узла WcfSvcHost указывать аргументы метаданных необязательно. По умолчанию узел WcfSvcHost передает в указанное клиенткое приложение адреса метаданных, прописанные в файле CONFIG размещаемой службы. Указывать адреса явным образом нужно, только если они не указаны в файле CONFIG или если вы хотите, чтобы тестовый клиент использовал другие адреса. Если в файле CONFIG указано несколько конечных точек метаданных для выбранной службы, то использоваться они будут в следующем порядке: HTTP, TCP, IPC, HTTP-GET. Описанные этапы можно включить в Visual Studio 2008 для упрощения процедур размещения и тестирования служб. Чтобы это сделать, нужно указать WcfSvcHost.exe в качестве запускаемой программы (вместе с файлом CONFIG), а WcfTestClient.exe - в качестве клиента.
Библиотеки служб в WCF
В качестве одно из функций целевой платформы Visual Studio 2008 предлагает несколько новых шаблонов проектов WCF. В диалоговом окне New Project (Новый проект) есть поле со списком, в котором можно указать, для какой версии платформы проект создается (2.0, 3.0 или 3.5) - см. рис. 6.
Рис. 6 Шаблоны проектов WCF
Если выбрать Framework 2.0, новые шаблоны доступны не будут. Для Framework 3.0 появился новый шаблон под названием WCF Service Library (библиотека служб WCF). Этот проект представляет собой всего навсего готовый вариант использования узла WcfSvcHost и клиента WcfTestClient. По сути своей он весьма близок к тем методам, которые были описаны выше (при сочетании обоих компонентов). Если вы используете проект WCF Service Library, то ни указывать WcfSvcHost.exe в качестве выполняемого приложения, ни задавать файл CONFIG не нужно, поскольку в файле проекта есть элемент ProjectTypeGuids, предназначенный для библиотеки служб WCF.
Отрицательной стороной этого шаблона является то, что при остановке отладчика работа тестового клиента не завершается, и на компьютере остается масса заброшенных клиентов. Чтобы избежать этого, нужно вручную выполнить те действия, которые были описаны выше.
В библиотеке служб WCF также имеется простейший шаблон, содержащий контракт службы, ее реализацию и соответствующий файл CONFIG.
Библиотека Syndication Service Library позволяет создать поток RSS через конечную точку WCF, и для начала работы вам предлагается элементарный контракт службы, возвращающей поток, ее реализация и соответствующий файл CONFIG. Поток можно размещать и использовать, как любую другую службу. Конечные точки распределения используют новую привязку WebHttpBinding. Она предназначена для получения веб-запросов - для обычного вызова служб она не используется.
Шаблон Sequential Workflow Service Library позволяет реализовать операции контракта конечной точки в виде рабочих процессов, или, фактически, представить рабочий процесс как службу. Проект будет содержать единственное последовательное действие, реализующее контракт и соответствующий файл CONFIG. На первый взгляд кажется, что клиент по-прежнему взаимодействует с традиционной конечной точкой, однако на самом деле реализация управляется исключительно рабочими процессами.
В шаблоне библиотеки State Machine Workflow Service Library для выполнения операций (иициации смены состояний) вместо последовательных рабочих процессов используется конечный автомат. В шаблонах проектов рабочих процессов используется узел WcfSvcHost и клиент WcfTestClient, точно так же как и в обыкновенной библиотеке служб WCF. В них также используются новые контекстные привязки - для управления передачей идентификаторов рабочих процессов и Шаблоны рабочих процессов и повышения их надежности. В следующем выпуске журнала мы рассмотрим эти привязки подробнее.
Добавление ссылки на службу
Расширения Visual Studio 2005 для .NET Framework 3.0 обеспечивают базовые возможности добавления ссылок на службы WCF. Многие дополнительные функции SvcUtil в них отсутствуют. В Visual Studio 2008 появилась новое диалоговое окно добавления ссылок на службы (см. рис. 7).
Рис. 7 Добавление диалога ссылки на службу
Чтобы открыть окно в проекте, нужно щелкнуть правой кнопкой мыши рабочую область проекта в обозревателе решения и в контектсном меню выбрать пункт Add Service Reference (Добавить ссылку на службу). При этом проект должен быть создан для .NET Framework 3.0 или более поздных версий.
В окне добавления ссылки нужно указать адрес метаданных службы (не адрес службы, как говорится в самом окне) и нажать кнопку Go, чтобы просмотреть список доступных конечных точек служб (а не самих служб, как следует из интерфейса). Затем вы должны указать пространство имен (к примеру MyService), в котором будет содержаться прокси, и нажать кнопку OK, чтобы создать прокси и обновить файл CONFIG. В большинстве случает Visual Studio 2008 не может самостоятельно определить оптимальные значения привязок, поэтому система объявляет для них значения по умолчанию, искажая тем самым содержимое файла CONFIG. Эта проблема будет устранена в будущих выпусках Visual Studio. Если для вас важно сохранить файл CONFIG в приличном виде, перед добавлением ссылки откройте его, добавьте ссылку, потом отмените одно действие (нажмите Ctrl+Z) и вручную добавьте нужные данные в части, относящейся к клиенту.
Кнопка Discover позволяет найти службы WCF в созданном вами решении, если службы размещены в проекте веб-узла или в одной из новых библиотек служб WCF. Если речь идет о веб-узле, Visual Studio 2008 либо получает метаданные от IIS, либо запускает сервер разработки на базе файловой системы ASP.NET. Если речь идет о библиотеке служб WCF, для получения метаданных WCF автоматически запускает размещающий узел (WcfSvcHost).
Кнопка Advanced открывает диалоговое окно, позволяющее настроить создание прокси, причем его функциональность мало отличается от SvcUtil (см. рис. 8). Используя интуитивно понятные параметры, вы настраиваете видимость прокси и контрактов (общие или внутренние); вы можете создать контракты сообщений для типов данных и обеспечить тем самым дополнительные возможности взаимодействия в ситуациях, когда приходится учитывать существующие, зачастую пользовательские, форматы сообщений; кнопка Add Web Reference (Добавить веб-ссылку) позволяет преобразовать ссылку в старый формат ссылок на веб-службы ASMX.
Рис. 8 Дополнительные параметры ссылки на службу
Флажок Generate asynchronous operations (Создать асинхронные операции) для каждой операции импортированного контракта добавляет пару элементов Begin<операция> и End<операция>, тем самым позволяя клиентам выполнять асинхронные вызовы рабочих потоков, а впоследствии синхронизировать результаты операции либо путем обратного вызова, либо путем блокировки завершения. К примеру, рассмотрим следующее определение контракта:
[ServiceContract]
interface ICalculator
{
[OperationContract]
int Add(int number1,int number2);
}
Импортированный контракт показан на рис. 9.
Figure 9 Imported Async Contract
[ServiceContract]
interface ICalculator
{
[OperationContract]
int Add(int number1,int number2);
[OperationContract(AsyncPattern = true)]
IAsyncResult BeginAdd(int number1,int number2,
AsyncCallback callback,object asyncState);
int EndAdd(IAsyncResult result);
//Rest of the methods
}
Соответствующих клиентский код для асинхронного вызова будет выглядеть следующим образом:
CalculatorClient proxy = new CalculatorClient();
int sum;
AsyncCallback completion = (result)=>
{
sum = proxy.EndAdd(result);
Debug.Assert(sum == 5);
proxy.Close();
};
proxy.BeginAdd(2,3,completion,null);
Эти методы можно использовать как есть, однако обратный вызов в методе Begin<операция> обращается к потоку из пула потоков. Это приводит к возникновению серьезной проблемы в том случае, если обратный вызов используется для доступа к ресурсам, связанным с определенным потоком или потоками. Классическим примером является приложение Windows Forms (или WPF), которое выполняет длительный асинхронный вызов службы (чтобы не блокировать пользовательский интерфейс), а затем пытается обновить интерфейс, добавив в него результаты вызова. Использовать метод Begin<операция> недопустимо, поскольку только поток интерфейса пользователя может обновлять интерфейс. Для решения подобных проблем был расширен базовый класс ClientBase<T>: в него был добавлен метод InvokeAsync, получающий контекст синхронизации от клиента и использующий его для обратного вызова при завершении операции, как показано на рис. 10.
Figure 10 Async Callback Management in ClientBase<T>
public abstract class ClientBase<T> : ...
{
protected delegate IAsyncResult BeginOperationDelegate(
object[] inValues,AsyncCallback asyncCallback,object state);
protected delegate object[] EndOperationDelegate(IAsyncResult result);
//Picks up sync context used for completion callback
protected void InvokeAsync(BeginOperationDelegate beginOpDelegate,
object[] inValues,
EndOperationDelegate endOpDelegate,
SendOrPostCallback opCompletedCallback,
object userState)
{}
//More members
}
В классе ClientBase<T> также имеется вспомогательный класс аргументов события и два выделенных делегата, которые используются для начала и завершения асинхронного вызова. Созданный класс прокси (производный от ClientBase<T>) задействует упомянутые базовые функции. Проски получает открытое событие <операция>Completed, в котором используется сильно типизированный класс аргументов события, непосредственно связанный с результатами выполнения асинхронного метода, и два метода <операция>Async, используемые для асинхронного распределения вызова:
partial class AddCompletedEventArgs : AsyncCompletedEventArgs
{
public int Result
{get;}
}
class CalculatorClient : ClientBase<ICalculator>,ICalculator
{
public event EventHandler<AddCompletedEventArgs> AddCompleted;
public void AddAsync(int number1,int number2,object userState);
public void AddAsync(int number1,int number2);
//Rest of the proxy
}
Клиент также может подписать обработчик событий на событие <operation>Completed, чтобы он вызывался по завершении операции. Главная разница в использовании между методами <операция>Async и Begin<операция> состоит в том, что методы <операция>Async получают контекст синхронизации от клиента и вызывают событие <операция>Completed для данного контекста синхронизации, как показано на рис. 11.
Figure 11 UI-Friendly Asynchronous Call Invocation
partial class CalculatorForm : Form
{
CalculatorClient m_Proxy;
public MyClient()
{
InitializeComponent();
m_Proxy = new CalculatorClient();
m_Proxy.AddCompleted += OnAddCompleted;
}
void CallAsync(object sender,EventArgs args)
{
m_Proxy.AddAsync(2,3); //Sync context picked up here
}
//Called on the UI thread
void OnAddCompleted(object sender,AddCompletedEventArgs args)
{
Text = "Sum = " + args.Result;
}
}
Поле со списком Collection type (Тип коллекции) позволяет указать способ представления клиенту отдельных видов коллекций и массивов, существующих в метаданных службы. К примеру, если служба возвращает коллекцию IEnumerable<T>, IList<T> или ICollection<T>, по умолчанию прокси представляет ее как массив. В качестве примера можно привести следующий вариант работы на стороне службы:
[OperationContract] IEnumerable<int> GetNumbers();
Эта коллекция будет представлена на прокси в следующем виде:
[OperationContract] int[] GetNumbers();
Однако Visual Studio 2008 можно настроить так, чтобы использовались другие коллекции: BindingList для привязок, List<T>, Collection, LinkedList<T> и т. д. Если преобразование представляется возможным, прокси будет использовать вместо массива требуемый тип коллекции:
[OperationContract] List<int> GetNumbers();
Аналогичная функция используется для словарей. Обычно служба возвращает сериализуемый словарь, подобный следующему:
[Serializable]
class MyDictionary<K,T> : IDictionary<K,T>
{...}
[OperationContract]
MyDictionary<int,string> GetDictionary();
Затем класс прокси представляется этот словарь в виде Dictionary<T,K> - это значение, установленное по умолчанию в поле со списком Dictionary collection type (Тип коллекции словаря):
[OperationContract] Dictionary<int,string> GetDictionary();
Однако вы можете запросить и другие типы словарей, например SortedDictionary<T,K>, HashTable или ListDictionary - прокси будет их использовать, если это возможно:
[OperationContract] SortedDictionary<int,string> GetDictionary();
Наиболее важной возможностью, предоставляемой новой функцией создания ссылок на службы является возможность обмениваться типами контрактов данных между сборками. В Visual Studio 2005, если клиент добавлял ссылки на две независимые службы, поддерживающие один и тот же контракт данных, он получал два отдельных, хотя и совпадающих, типа, представляющих один и тот же контракт. В Visual Studio 2008, если в какой-либо из сборок, на которые ссылается клиент, уже имеется тип контракта данных, совпадающий с типом контракта, указанным в метаданных службы, на которую создана ссылка, то по умолчанию повторно этот тип не импортируется. Следует еще раз подчеркнуть, что существующая ссылка на контракт данных должна существовать в другой сборке, а не в самом проекте клиента. Это ограничение будет снято в будущих выпусках Visual Studio. Пока что лучшим и наиболее очевидным решением является следующее: вы сводите все совместно используемые контракты данных к одной выделенной быблиотеке классов, и все клиенты ссылаются на эту сборку.
Диалоговое окно дополнительных параметров ссылок на службы позволяет настроить совместное использование контрактов. Флажок Reuse types in the referenced assemblies (Повторно использовать типы в сборках, на которые создаются ссылки) установлен по умолчанию, но вы можете его снять. Несмотря на название этой функции, она влияет только на контракты данных, а не на контракты служб. Кнопки-переключатели сразу под этой функцией (см. рис. 8) позволяют настроить Visual Studio 2008 так, чтобы контракты данных использовались во всех сборках, на которые создаются ссылки, или только в определенных сборках (рядом с ними нужно установить флажки).
После добавления ссылки в проекте появляется папка Service References, в которой хранится элемент ссылки для каждой службы, для которой ссылки созданы (см. рис. 12).
Рис. 12 Папка ссылок на службу
Вы в любой момент можете щедкнуть ссылку правой кнопкой мыши и выбрать пункт Update Service Reference (Обновить ссылку на службу), чтобы повторно создать прокси и обновить файл CONFIG для клиента. Это возможно, поскольку в элементе ссылки на службу кроме всего прочего содержится файл, хранящий исходный адрес метаданных.
Пункт Configure Service Reference (Настроить ссылку на службу) открывает окно, схожее с окном дополнительных параметров, доступным во время добавления ссылки. В окне настройки ссылки на службу можно изменить адрес метаданных службы и прочие дополнительные настройки прокси.