Showing posts with label WCF. Show all posts
Showing posts with label WCF. Show all posts

Friday, December 4, 2009

JSON Serialization

The Problem:
Here is the error that took me a few days of back-and-forth with an India programming team to figure out:

DateTime values that are greater than DateTime.MaxValue or smaller than DateTime.MinValue when converted to UTC cannot be serialized to JSON.
at System.Runtime.Serialization.Json.JsonWriterDelegator.WriteDateTime(DateTime value)
at System.Runtime.Serialization.XmlWriterDelegator.WriteDateTime(DateTime value, XmlDictionaryString name, XmlDictionaryString ns)


The Solution:
I found that I had an uninitialized date time property (meaning it was equal to DateTime.MinValue) in my data transfer object (DTO). If your WEST of GMT, this doesn't cause a problem; however, if your EAST of GMT, the DataContractJsonSerializer will puke.

Wednesday, July 30, 2008

WCF DateTime field adjusted automatically for time zone

Well, I got bit by DateTime serialization yesterday. Our server is in the U.S. Central Standard Time (CST) zone and our client is in the U.S. Eastern Standard Time (EST) zone. All data saved in the database is relative to the client and NOT the server. So when the client wants to see all data for today, only the date is specified using DateTime.Today. So when the EST client sent a date of 7/29/08 00:00:00 AM to our WCF webservice on the CST server, the date was converted to 7/28/08 11:00:00 PM. The symptom from the client's point of view was that they could never retrieve data for today.

According to Coding Best Practices Using DateTime in the .NET Framework there are several ways to work around this; however, they missed one. If you change your dates so that DateTimeKind is unspecified, the XML serializer will NOT try to convert them. For example, this code will convert a date to DateTimeKind.Unspecified:


DateTime newDate = DateTime.SpecifyKind(oldDate, DateTimeKind.Unspecified);


References:

Friday, November 9, 2007

WCF Security Exception: Timestamp is invalid because its creation time is in the future

Well, I ran into a real fun bug today that surfaced itself on the user's computer as a "Security Exception see Inner Exception". Upon examining the inner exception, it told me that the message was incorrectly secured. After placing some tracing on the server, I found this error message:

The security timestamp is invalid because its creation time ('11/9/2007 10:37:07 PM') is in the future. Current time is '11/9/2007 10:28:52 PM' and allowed clock skew is '00:05:00'.

After fixing the user's clock, which was roughly 8 minutes fast, everything worked great. The next question is "How do I increase the maximum skew time"? It took a bit of searching to figure out that I need to create a custom binding to change the values. Here is an example of how to do it:

<bindings>
<customBinding>
<binding name="MaxClockSkewBinding">
<textMessageEncoding />
<security authenticationMode="Kerberos">
<localClientSettings maxClockSkew="00:07:00" />
<localServiceSettings maxClockSkew="00:07:00" />

<secureConversationBootstrap />
</security>
<httpTransport />
</binding>
</customBinding>
</bindings>

For more information, see How To: Set a Max Clock Skew on MSDN.


More References:

Friday, July 13, 2007

How do I upload & download files using WCF?

I'm looking for the best way to accomplish these tasks. What follows is the best information that I've found. I will periodically update this post as I discover more information.

Examples:

WCF gotchas:
  • Don't forget to set the maxReceivedMessageSize attribute of your binding to something fairly high if you are sending large files.

IIS gotchas:
  • Increase the maxRequestLength, which represents maximum length in kilobytes, in the System.Web section of my web.config file in order to upload large files to your server (i.e., < maxrequestlength="65536"> ). Remember that the reason maxRequestLength in the System.Web section was set so low was to decrease your vulnerability to denial-of-service attacks.


Articles worth reading: