Служба WCF с 4 входными и 3 выходными параметрами переупорядочивается путем добавления ссылки на службу в проекте класса прокси

Question

Я посмотрел в SO и в других местах и ​​видел вопросы об этом вместе с некоторыми ответами, которые все еще не имеют смысла для меня в моем случае.

Я рефакторинг моего рабочего решения VStudio 2010, которое имеет:

• один проект с веб-сервисом ASMX
• другой отдельный проект для прокси-класса (здесь нет кода, кроме того, что генерируется Add Web Reference
• другой отдельный проект для клиента (содержит ссылку на ProxyClass.dll

Новое решение VStudio 2010 имеет:

• один проект библиотеки служб типа WCF для контракта сам по себе (IFileService.cs) один проект библиотеки служб типа WCF для реализации договора (FileService.cs)
• другой отдельный проект для прокси-класса (здесь нет кода, кроме того, что генерируется Add Service Reference)
• другой отдельный проект для клиента (содержит ссылку на WCFProxyClass.dll)

Вот контракт, который заканчивается с 3 выходными параметрами (и выполнение того же самого заказа):

[ServiceContract(Name = "IFileService", Namespace =  "http://www.cbmiweb.com/TrimWCF/2011/11")]
public interface IFileService
{
    [OperationContract]
        public string DownloadFile(string trimURL
         , string TrimRecordNumber
         , string CallerPC
         , string RequestorID
         , out byte[] docContents
         , out string returnFiletype
         , out string returnFilename)
    {

Вот то, что Add Service Reference сгенерировано в моем проекте класса прокси:

public string DownloadFile(
  out byte[] docContents
, out string returnFiletype
, out string returnFilename
, string trimURL
, string TrimRecordNumber
, string CallerPC
, string RequestorID) 
{
    return base.Channel.DownloadFile(out docContents, out returnFiletype, out returnFilename, trimURL, TrimRecordNumber, CallerPC, RequestorID);
}

Я прочитал ответы в диапазоне от "вы не можете использовать parms в WCF" до "вы не должны использовать Add Service Reference, а вместо этого использовать svcutil.exe" до "порядок параметров не имеет значения... он все равно будет работать".

Я не понимаю, что делать здесь (и что я сделал неправильно, что привело к этому измененному порядку и ПОЧЕМУ это произошло).

Answer 1

Прежде всего, вы не сделали ничего плохого:). Несмотря на то, что подписи в методах на клиенте и на сервере различны, они эквивалентны сообщениям, которые они будут производить / потреблять. Вы можете использовать этот прокси-класс без каких-либо проблем, и он должен работать так же хорошо.

Почему это происходит, другая история - в описании службы (WSDL) есть два "сообщения" для каждой (не односторонней) операции: одно с входными параметрами, одно с выходными параметрами. Сообщения содержат соответственно входные данные и выходные данные операции, но в WSDL нет ничего, что указывало бы их порядок. Поэтому, когда такой инструмент, как Add Service Reference или svcutil, генерирует клиентский прокси, он просто "выберет" один заказ (сначала из параметров), но запрос, который прокси отправит службе, будет совместим с тем, что ожидает сервер. (а также, ответ от сервера будет правильно понят прокси).

Если вы хотите сохранить порядок параметров, вы можете создать прокси-класс самостоятельно. Для этого вы можете использовать ChannelFactory<T> или создайте свой собственный класс клиента, полученный из ChannelBase<T>, Но вам не нужно этого делать, как я упоминал ранее.