Ссылки на веб-службу .NET. Сгенерированные классы, не работающие с типом даты

Я написал веб-сервис JAX-WS в Java, создав WSDL и классы из XML-схемы.

Я добавляю службу как веб-ссылку в visual studio, чтобы использовать ее с клиентским приложением С#.NET.

В исходной схеме XML используются несколько типов даты/времени: xs: date и xs: dateTime для некоторых элементов.

Моя проблема в том, что мой тип dateTime не работает правильно. Он преобразуется в объект .NET DateTime (правильно) в сгенерированных классах (создается XMLSerializer в Visual Studio 2010), а затем я могу создать свой собственный объект DateTime и установить DateTime в одном из этих классов. Однако при отправке запроса на сервер клиентское приложение отправляет нулевое значение вместо объекта DateTime, на который я его установил. Поэтому я предполагаю, что это неправильно сериализуется.

У меня нет той же проблемы с типом даты, который сериализует/десериализует штраф.

Я заметил что-то, что может быть проблемой, но не уверен:

Объект dateTime в сгенерированном классе выглядит следующим образом: [System.Xml.Serialization.XmlElementAttribute(заказ = 10)] public System.DateTime MyDateTime {...}

тогда как объект даты в сгенерированном классе выглядит следующим образом: [System.Xml.Serialization.XmlElementAttribute(DataType = "date", Order = 12)] public System.DateTime MyDate {...}

Итак, в объекте даты есть дополнительная информация - DataType = "date", но нет DateType для объекта dateTime. Это может быть проблема? Если да, то почему он не генерирует классы правильно?

Спасибо за любую помощь

Ответ 1

Я столкнулся с этой проблемой до и после тяжелой работы, я обнаружил, что один конец сообщения использует формат даты в Великобритании (dd/MM/yyyy), а другой - в США (MM/dd/yyyy). Это установлено в культуре глобализации на машине (как и ответ от @Gaurav), однако следующее не было так очевидно:

когда я запускал свой код под VS, я запускаю как себя и, следовательно, свою собственную культуру en-GB. Как вы знаете, когда я запускаю код под IIS, он запускается под учетной записью ASPNET (или NETWORK SERVICE и т.д., В зависимости от версии IIS). Оказывается, что учетная запись ASPNET имеет культуру en-US, поэтому проблема.

Простое решение - добавить тег глобализации в Web.config и установить атрибуты культуры и урожая.

Ответ 2

У меня был элемент dateTime, который не был обязательным в wsdl, и даже если я установил свойство на .NET-объект, который будет отправлен, он не передавался как XML. (Я выполнил отладку с помощью просмотра журнала трассировки .NET).

Позже я понял, что мне нужно установить логическое значение, которое было поставлено рядом с атрибутом DateTime, в значение true, и это сработает. xxxSpecified. См. Код ниже.

/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Order=6)]
public System.DateTime Created {
    get {
        return this.createdField;
    }
    set {
        this.createdField = value;
        this.RaisePropertyChanged("Created");
    }
}

/// <remarks/>
[System.Xml.Serialization.XmlIgnoreAttribute()]
public bool CreatedSpecified {
    get {
        return this.createdFieldSpecified;
    }
    set {
        this.createdFieldSpecified = value;
        this.RaisePropertyChanged("CreatedSpecified");
    }
}

Ответ 3

Я работал с Livecycle на машине JBoss. Я подключил веб-службы оттуда в .net. Я обнаружил, что DateTime и Booleans не переводили правильно. Я знаю, что это не хорошая форма, но я поместил атрибут serialize datatype в строку. Именно так я мог бы получить данные, чтобы перейти.

Я бы посмотрел, что написал kroonwijk. Fiddler - отличный инструмент для проверки приходов и услуг.

Ответ 4

Если вы используете информацию о культуре глобализации для даты, тогда этот тип проблемы не возникает. в вас оба кода вы будете использовать ту же информацию о культуре для даты и даты и времени. В этом случае вы нашли тот же формат даты и времени в обоих кодах.