I have a WSDL I need to write a WCF client against (in C#). In the WSDL one of the elements is:
<xs:element name="TransactionDateTime" type="xs:date" />
For the moment I'm using a mock service created through SoapUI with that wsdl, so I can get mock responses where I'm trying to populate that TransactionDateTime using a groovy script.
My problem is whatever I use it seems to raise an exception in the client when trying to deserialize the reply body
String was not recognized as a valid DateTime
These are examples of what I've tried to return in the groovy script
new java.text.SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ").format(new Date())
javax.xml.datatype.DatatypeFactory.newInstance().newXMLGregorianCalendar(GregorianCalendar.getInstance())
If I try to hardcode it in the xml that I use as a response as
2014-09-11T10:11:555
which is by the way the format specified in the docs that came along with the WSDL it raises the same exception
Further more if I just hard code in the response a date like this '2014-09-12' instead of raising an exception it populates it as 01/01/0001 00:00:00 in the DateTime property of the C# class the response is populating
Can anyone give me any hint on which path should I follow?
UPDATE:
Wasn't 100% sure but I reckon the reason is the same as for this question or explained in other webs, WCF doesn't support xs:date. So I would ask the third party to change the WSDL and send the date as a string that I will parse. Can't thinkg of a better option
How can I remove specific types from the the generated WSDL document of a WCF service?
I already have a System.Web.Services.Description.ServiceDescription for my service in a custom IWsdlExportExtension. Where can I find the types in the service description?
Thanks
When you're creating your .NET proxy class using the svcutil command line utility, you can define a command-line switch
/excludeType:<type>
Specifies a fully-qualified or assembly-qualified type name
to be excluded from referenced contract types.
When using this switch together with /r from separate DLLs,
the full name of the XSD class is referenced.
Short Form: /et
See the complete and freely available MSDN documentation for svcutil for more details.
I am developing a WCF Service application with basicHttpBinding option. I chosed basicHttpBinding because my client could be a Java client, a Visual Basic Client etc.
Now i want to be sure that the datatypes which i used in my application are compatible and consumable with Java clients or other platform languages.
For instance, Which of the following .NET datatypes can be used without affacting interoperatablitiy?
DateTime
int
double
double?
float
float?
string
I answer my own question.
I found a resource which tells the interoperability of data types between .Net server and Java client.
The documantation
The documantation says that using nullable data types wont make any headache to developers. However, i wont use nullable datatypes like double? int? etc. I will assing default values insead.
I am using WCF Web API Preview 6 with its inbuilt Test Client to request a resource by Id. The object returns with all its data except for the ‘CreateDate’ and ‘LastModifiedDate’ properties which are of type DateTimeOffset and are empty. I have tried setting the values manually by calling DateTimeOffset.UtcNow and DateTimeOffset.Now and although the values are set on the object they never make it through to the other end in the response.
I have also tested this by changing my property types to DateTime and manually setting their values by using DateTime.Now and everything works fine and I get what looks like a DateTimeOffset value.
<CreateDate>2011-12-13T16:15:47.4269538+00:00</CreateDate>
<LastModifiedDate>2011-12-13T16:15:47.4269538+00:00</LastModifiedDate>
Does anybody know if there is a problem with the use of the DateTimeOffset type in Preview 6 or is it something I am doing wrong? I have had a similar problem with filtering the fields using oData (see SO question)
I have also submitted this bug report to the WCF Web API codeplex site on the filtering issue. However that was over two weeks ago and haven’t had any response.
After many hours of testing and debugging I am running out of options on this one! So if anybody out there can provide me with some helpful hints it would be much appreciated.
It's not a Web API issue, it's Microsoft serialization issue. The XmlSerializer does not handle DateTimeOffset. I believe it has the same issue with TimeSpan.
Just implement IXMLSerializable on your object and handle it yourself.
See here How can I XML Serialize a DateTimeOffset Property?
We're attempting to move to VS 2010 and we've noticed some odd behavior with our WCF services.
In VS 2008, when I add a given WCF service reference, for each object field that's not a reference type, the Object browser shows a fieldNameSpecified bool property. I realize that this exists so that there's a way to determine whether or not the value coming back from the service actually has a value, since DateTime, ints, etc can't be null.
When I try to add the same reference in VS 2010 (set to .Net 3.5), all of these fieldNameSpecified fields are missing. We have code that we wrote in VS 2008 that look at these fieldNameSpecified fields which causes our apps to be broken when attempting to use VS 2010 (because the proxies generated in VS 2010 don't have these fieldNameSpecified fields).
Is there a way to get VS 2010 to put these specified fields back in? Is there some other solution that won't require us to rewrite our code?
Also, what is the proper VS 2010 way of determining whether or not a value type field (int or DateTime) actually has valid data in it coming back from the service?
Any help GREATLY appreciated!
Clarification: The fieldNameSpecified fields are NOT part of the WSDL. VS 2008 apparently adds these into the proxy for you as a convenience...
I ran into an opposite situation recently. There wasn't any xxxspecified field before, but now they showed up. And we have only used VS2008. This acutally cause the value of the optional fields not being passed to the client application, since the xxxspecified fields are default to false.
If you look at both versions of the auto generated reference.cs file under your service reference, you should notice the difference. One uses DataContractSerializer, the other uses XMLSerializer.
When you add the service reference, if you use the URL for the service, e.g. http://localhost/MyService.svc, it would use DataContractSerializer. If you use the URL for the WSDL, e.g. http://localhost/MyService.svc?wsdl, it would use XMLSerializer.
You can use an attribute called EmitDefaultValue to resolve your problem as well. Follow these instructions:
http://bukovics.wordpress.com/2007/03/23/exposing-nullable-fields-to-net-11-web-service-clients/
This also explains why you get a fieldNameSpecified property. It's exactly what you need to fix your problem.
As I understand it, if the data contract requires the properties (for example, if you're using a [DataMember(IsRequired=true)] attribute), the "Specified" fields aren't auto-generated. Unfortunately, making the fields non-required would require a code change, but at least it wouldn't do so on the client.
An alternate way to allow callers to be able to not specify parameters (don't know if it's more VS 2010-ish than the "Specified" fields) is to use Nullable<> types.
I haven't tested it, but perhaps you could remove your Service References and instead put a pre-build step into your projects to run the old version of WSDL.exe to generate the proxies.