I'm trying to create a new Service Reference from a WSDL and all of the properties I expect to be DateTime instead of string.
For example, this xsd definition for Contact:
<s:complexType name="Contact">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="Address" type="tns:Address" />
<s:element minOccurs="0" maxOccurs="1" name="Email" type="s:string" />
...
<s:element minOccurs="1" maxOccurs="1" name="BirthDate" type="s:date" />
</s:sequence>
The type of BirthDate is s:date, but the generated type (in Reference.cs) is a string.
internal partial class Contact : object, IExtensibleDataObject, INotifyPropertyChanged
{
[OptionalField]
private MembershipMgmtMediator.Address AddressField;
[OptionalField]
private string EmailField;
private string BirthDateField;
}
If i create a web project and add it as a Web Reference instead of a Service Reference, it correctly becomes a DateTime. I assume that has something to do with the way wsdl.exe and svcutil.exe work behind the scenes, but regardless, I'm stuck on trying to figure out how to correctly get Visual Studio to recognize that this property should be a DateTime.
There is some good info in these questions: How to generate xs:Date in WCF OperationContract parameter and Best practices for DateTime serialization in .NET 3.5.
As Alex states in his comment to the question, WCF does not support
xs:date
types. However, it is perhaps more accurate to say that the defaultDataContractSerializer
does not support that type, while the above questions indicate that theXmlSerializer
can handle it.See this link for a
DataContractSerializer
againstXmlSerializer
comparison.If I run:
Then a WSDL fragment like this:
Has this class generated:
That
svcutil
invocation produces two files:Service1.cs
andoutput.config
. If I include the code file in the project and add thesystem.serviceModel
bits into the configuration file (i.e., web.config or app.config) I can then call the service as normal. For example:This approach is not without disadvantages. The
Service1.cs
file is markedly different if generated without the/ser:XmlSerializer
parameter, where you will get additional classes such asWebMethodNameRequest
,WebMethodNameRequestBody
,WebMethodNameReponse
,WebMethodNameReponseBody
and so on. If these classes are important in your interactions with the service, my approach may not work for you.Edit:
In terms of nullable properties, there is some good information in this question: svcutil.exe - Proxy generated not allowing for nullable fields
To get a property nullable in the generated proxy class, the
nillable
field needs to be set in the WSDL. So something like this:Would generate a property called
public System.Nullable<System.DateTime> SomeProperty
in the proxy class.However in your case you can use the
SomePropertySpecified
property to indicate the presence or absence of the property. These kinds of properties are generated when you haveminOccurs="0"
.In terms of date formatting I'm not sure.
xs:date
values are intended to be yyyy-mm-dd with optional timezone information (w3.org). If Oracle is expecting dates in a different format then I wonder how they can bexs:date
values at all.Is there any documentation or other information you can provide regarding the service you are trying to consume?
Edit 2:
I am a little unclear on exactly what "Dates must be in the database format." means in the Oracle docs. If the type is an
xs:date
then serializing them to the database format would surely mean that it was no longer anxs:date
?Still, there are some things you try in that regard:
You may need to simply experiment sending a few queries to the web service to see just how this date business affects things.
Are you sure those
*IsSpecified
parameters aren't there? To use myContact
class above as the example,minOccurs=0
on theBirthDate
property would give theContact
class an extra property calledBirthDateIsSpecified
.While this is not a real solution, I think that it may work as a workaround. It is dirty and ugly, and I know that, but it may be better than having String in your code.
Since your own classes (like
Address
) are properly processed, you could build a simple wrapper aroundDate
class that you would include in your project and schema. The class would have only aDate
property or a field and a getter to it.Although I believe nick_w's answer covers the question quite well (and I'm awarding him the bounty), I'm providing the solution I'm going to use in my specific case, where just using
XmlSerializer
isn't enough. In the end, I think I'm going to go with an extension that convertsDateTime
objects to string, using a custom format specifier.