Ссылки на веб-службу .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
Если вы используете информацию о культуре глобализации для даты, тогда этот тип проблемы не возникает.
в вас оба кода вы будете использовать ту же информацию о культуре для даты и даты и времени. В этом случае вы нашли тот же формат даты и времени в обоих кодах.