I have to use a customer web service which contains some DateTime. They send me a SOAP example and the expected serialization format is "2016-08-06T13:40:00Z". Problem is when I serialize my DateTime then the format is "2016-08-06T13:40:00" and therefore I get an exception from the WebService. I read in some articles that I have to specify the DateTime Kind to UTC. I did it but without success. Format is still "2016-08-06T13:40:00". Any idea how to handle this case?
Related
I'm generating a C# SOAP Web service proxy from a WSDL using svcutil.exe.
Some fields in the WSDL are of type xs:datetime and return datetimes with timezone information.
I would therefore like the proxy to use DateTimeOffset for these fields.
According to the svcutil.exe documentation it should be enough to specify the /tcv:Version35 parameter in order for it to generate DateTimeOffset fields instead of DateTime fields in the C# proxy.
However this is not the case. There is no change when adding the /tcv:Version35 parameter. It still generates fields of type DateTime in the C# proxy for the xs:datetime fields in the WSDL.
Any ideas how to have it generate fields of type DateTimeOffset instead?
Adding "/targetClientVersion:Version35" worked for me. Can you verify that you are not using an old version of svcutil.exe? My version is located in "Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\SvcUtil.exe".
Also, remember to add "[KnownType(typeof(DateTimeOffset))]" to the data contract class, since DateTimeOffset isn't a type known by the DataContractSerializer as default (ref https://msdn.microsoft.com/en-us/library/ms730167(v=vs.110).aspx),
I am using SOAPUI to call a WCF endpoint with a decimal value. Somewhere the value is getting converted to a zero.
I can call the same service, with the same parameters from a .NET application and the value is not getting altered. I can de-serialise and inspect the values being passed from my .NET app and SoapUI, and both de-serialised versions of the object are identical.
I have been able to capture the request in Fiddler after it has left SoapUI and the decimal value is still in tact so I know it is getting converted down stream somewhere.
This post suggests that this can happen when the proxy is generated:
int properties are 0 when consuming WCF in .Net 2 - but evidence is not pointing to this being a problem in the service, not the client.
Apologies I can't share WSDL nor XML due to corporate privacy restrictions.
The resolution in my case was to change the order of my request parameters.
I was able to determine this by enabling WCF tracing, including message payloads, and then comparing the payloads from my .NET application against the payloads from SoapUI.
The payloads are massively different, but ignoring namespaces, correlation ids, keys and dates I was able to determine that my problematic parameter was in a different position. Changing the order within SoapUI XML request resolved the issue.
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
I have a Silverlight App that calls my WCF service to get a list of the Time zones from the server. All Time zones are retrieved in the function on the server but I need to know how to pass these back to Silverlight.
My call on the server is below but I think I need to somehow serialize the TimeZoneInfo as a Know Type before I can pass it back. This is the point where I am stuck.
Please can someone help on this?
Public Function GetTimezones() As ReadOnlyCollection(Of TimeZoneInfo) Implements ITimezoneService.GetTimezones
Dim timeZones As ReadOnlyCollection(Of TimeZoneInfo) = TimeZoneInfo.GetSystemTimeZones()
Return timeZones
End Function
See this http://social.msdn.microsoft.com/Forums/en/wcf/thread/f164f185-ae18-4775-a2ff-a814813d262d for a list of known types to add to allow TimeZoneInfo to be serialized.
This will work for the full framework but I don't really recommended it, I would rather use either the ID, or the built-in string serialization as proposed in c# TimeZoneInfo serialization.
On the contrary, the Silverlight framework has its own lightweight version of TimeZoneInfo and thus won't be able to deserialize the TimeZoneInfo serialized by the full framework (since it's not the same type definition).
You should also note that, by default security parameter Silverlight has only access to UTC and Local (Silverlight client running machine locale) TimeZoneInfo, and that to use other time zones, you need to run Silverlight with elevated privileges because timezone information is registry based. See silverlight Time Zone converting and http://forums.silverlight.net/t/186363.aspx/1.
In the end some did rewrite whole or part of the TimeZoneInfo class in their own Silverlight application (we had to too). See http://forums.silverlight.net/t/165067.aspx/1.
Silverlight doesn't have yet support for more than local to UTC or UTC to local time zone conversion natively.
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?