Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

.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

like image 507
Josh Avatar asked Aug 15 '11 14:08

Josh


3 Answers

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");
    }
}
like image 97
cederlof Avatar answered Nov 19 '22 10:11

cederlof


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.

like image 24
Omnia9 Avatar answered Nov 19 '22 11:11

Omnia9


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.

like image 2
Paul Avatar answered Nov 19 '22 10:11

Paul