2011-08-15 19 views
11

Escribí un servicio web JAX-WS en Java generando un WSDL y clases desde un esquema XML.Las clases generadas de referencia del servicio web .NET no funcionan con dateTime tipo

Estoy agregando el servicio como referencia web en Visual Studio, para usarlo con una aplicación de cliente C# .NET.

El esquema XML original utiliza un par de tipos de fecha/hora: xs: date y xs: dateTime para algunos de los elementos.

Mi problema es que mi tipo 'dateTime' no funciona correctamente. Se convierte en un objeto .NET DateTime (correctamente) en las clases generadas (producidas por XMLSerializer en Visual Studio 2010), y luego puedo crear mi propio objeto DateTime y configurar el DateTime en una de estas clases. Sin embargo, al enviar la solicitud al servidor, la aplicación cliente envía un valor nulo en lugar del objeto DateTime al que lo configuré. Así que supongo que no se está serializando correctamente.

No tengo el mismo problema con el tipo 'fecha', que serializa/deserializa bien.

me di cuenta de algo que podría ser el problema, pero no está seguro:

El objeto DateTime en la clase generada tiene el siguiente aspecto: [System.Xml.Serialization.XmlElementAttribute (Orden = 10)] sistema público .DateTime MyDateTime {...}

mientras que el objeto de fecha en la clase generada tiene el siguiente aspecto: [System.Xml.Serialization.XmlElementAttribute (tipo de datos = "fecha", Orden = 12)] System.DateTime pública MyDate {...}

Entonces, hay algo de información adicional en el objeto de fecha - DataType = "date", pero no hay DateType para el objeto dateTime. ¿Podría ser este el problema? Si es así, ¿por qué no está generando las clases correctamente?

Gracias por cualquier ayuda

+0

Nota: el problema de dateTime es solo una cuestión de sentido único. El problema ocurre cuando la aplicación del cliente (.NET) envía un objeto de solicitud con un elemento dateTime al servidor y el servidor recibe un valor nulo. La otra forma parece estar bien (si el servidor envía un objeto de respuesta con un elemento dateTime, el cliente recibe la respuesta con el objeto DateTime con la información correcta de fecha/hora) – Josh

+3

Asegúrese absolutamente de que está configurando un Valor de fecha y hora válido en la solicitud. A continuación, valide su solicitud de salida al servidor ejecutando Fiddler en su sistema cliente y verificando la solicitud. Por favor regresa con tus hallazgos. – kroonwijk

+2

Tuve un problema similar. En mi caso, el miembro dateTime se saltó en xml que se envió al servidor. Estaba relacionado con el hecho de que wsdl contenía minOccurs = "0". Como resultado, el cliente generado de Visual contiene indicadores de que este campo está 'especificado'. Debo haber agregado: fieldNameSpedified = true; para cada campo. Puede ser también tu caso. – bart

Respuesta

2

Me encontré con este problema antes y después de mucho trabajo duro encontré que un extremo de la comunicación estaba usando un formato de fecha UK (dd/MM/aaaa) y el otro estaba usando un US (MM/dd/aaaa) formato. Esto está establecido en la cultura de la globalización en la máquina (como la respuesta de @Gaurav) sin embargo, el siguiente no era tan obvio:

cuando ejecuté mi código bajo VS corrí como yo mismo y por lo tanto mi propia cultura de en- GB. Como puede saber cuando ejecuto el código en IIS, se ejecuta bajo la cuenta ASPNET (o SERVICIO DE RED, etc., según la versión de IIS). Resulta que la cuenta ASPNET tiene una cultura de en-US, de ahí el problema.

La solución simple es agregar una etiqueta de globalización a la Web.configurar y establecer los atributos de cultura y uicultura.

3

estaba trabajando con Livecycle en una máquina de JBoss. Conecté los servicios web desde allí a .net. Descubrí que DateTime y Booleans no se tradujeron correctamente. Sé que no es una buena forma, pero puse el atributo serialize datatype en string. Esa era la forma en que podía hacer que los datos se transmitieran.

Verificaría qué escribió kroonwijk. Fiddler es una buena herramienta para verificar las idas y venidas de los servicios.

+0

+1 para enviar DateTime como una cadena independiente de la configuración regional. – SlavaGu

0

Si está utilizando la información de la cultura de globalización para la hora de fecha, este tipo de problema no se produce. en los dos códigos usará la misma información cultural para la fecha & datetime. En ese caso, encontró el mismo formato de fecha y hora en ambos códigos.

4

Tenía un elemento dateTime que no era obligatorio en el wsdl, y aunque establecí la propiedad en el objeto .NET que se enviaría, no se pasó como XML. (Hice la depuración con .NET Trace log viewer).

Más tarde me di cuenta de que tenía que establecer el booleano que se suministraba junto a DateTime-property en true, y funcionaría. xxxSpecified. Vea el código a continuación.

/// <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"); 
    } 
} 
Cuestiones relacionadas