Josh
Josh

Reputation: 707

.NET web service reference generated classes not working with dateTime type

I've written a JAX-WS webservice in Java by generating a WSDL and classes from an XML schema.

I am adding the service as a web reference in visual studio, to use with a C#.NET client application.

The original XML schema uses a couple of date/time types: xs:date and xs:dateTime for some of the elements.

My problem is that my 'dateTime' type is not working correctly. It is converted to a .NET DateTime object (correctly) in the generated classes (produced by XMLSerializer in Visual Studio 2010), and then I can create my own DateTime object and set the DateTime on one of these classes. However when sending the request back to the server, the client application is sending a null value instead of the DateTime object I set it to. So I guess it is not serializing correctly.

I do not have the same problem with the 'date' type, which serializes/deserializes fine.

I noticed something which could be the problem, but not sure:

The dateTime object in the generated class looks like this:

[System.Xml.Serialization.XmlElementAttribute(Order=10)]
public System.DateTime MyDateTime { ... }

whereas the date object in the generated class looks like this:

[System.Xml.Serialization.XmlElementAttribute(DataType="date", Order=12)]
public System.DateTime MyDate { ... }

So, there is some additional info in the date object - DataType="date", but there is no DateType for the dateTime object. Could this be the problem? If so, why is it not generating the classes correctly?

Thanks for any help

Upvotes: 11

Views: 4961

Answers (4)

cederlof
cederlof

Reputation: 7383

I had a dateTime element which was not mandatory in the wsdl, and even though I set the property on the .NET-object that would be sent, it was not passed on as XML. (I did the debugging with .NET Trace log viewer).

Later I realized I had to set the boolean that was supplied next to the DateTime-property to true, and it would work. xxxSpecified. See code below.

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

Upvotes: 5

Paul
Paul

Reputation: 1483

I have ran into this problem before and after a lot of hard work I found one end of the communication was using a UK (dd/MM/yyyy) Date format and the other was using a US (MM/dd/yyyy) format. This is set in globalization culture on the machine ( like the answer from @Gaurav ) however, the following wasn't so obvious:

when I ran my code under VS I run as myself and therefore my own culture of en-GB. As you may know when I run the code under IIS it is run under the ASPNET account (or NETWORK SERVICE, etc depending on the version of IIS). It turns out that the ASPNET account has a culture of en-US, hence the problem.

The simple solution is to add a globalisation tag to the Web.config and set the culture and uiculture attributes.

Upvotes: 2

Gaurav Agrawal
Gaurav Agrawal

Reputation: 4431

If you are using globalization culture info for date time then this type of problem not occurs. in you both code you will use same culture info for date & datetime. In that case you found same datetime format in both of codes.

Upvotes: 0

Omnia9
Omnia9

Reputation: 1573

I was working with Livecycle on a JBoss machine. I connected the web services from there to .net. I found that DateTime and Booleans did not translate correctly. I know that it is not good form, but I put the serialize datatype attribute to string. That was the way that I could get the data to go across.

I would check what kroonwijk wrote. Fiddler is a nice tool for checking the comings and goings of services.

Upvotes: 3

Related Questions