We have an application which includes a SmartDate property (VehicleEarliestNextVisitDate) and, as suggested, uses a string property for setting:
Public Property VehicleEarliestNextVisitDateString() As String Get Return GetPropertyConvert(Of SmartDate, String)(VehicleEarliestNextVisitDateProperty) End Get Set(ByVal value As String)SetPropertyConvert(VehicleEarliestNextVisitDateProperty, value)
End Set End PropertyWhen we test this in our development environment, it works just fine. We can see that our code is providing values in the form "mm/dd/yyyy" eg> "06/20/2009"
When we deploy the application to another machine, the date value is being provided in the same format (mm/dd/yyyy) but we get a System.ArgumentException: String value can not be converted to a date.
We suspect there is some kind of default date format issue at the heart of this, but we are quite baffled. Is there some interaction between SmartDate and system configuration which might result in this behaviour? Can anyone suggest another possible cause?
I am assuming since our business object assemblies are being use in a web app, that the culture settings for the web app would apply.
The culture is set to Invariant Language (Invariant Country) in both instances.
This may well be the case.
In any event, I have worked around the issue by using Date.TryParse to parse the date string into a date and then setting the value directly,using SetProperty instead of SetPropertyConvert. Since TryParse will return Date.MinValue when the value is not a valid date, this works for our requirements.
I still would like to understand why SetPropertyConvert has an issue with this (be it a culture mismatch or otherwise).
Frazer
You could step through the code in the debugger to see which coercion technique is failing.
SetPropertyConvert() calls CoerceValue(), which tries every technique I'm aware of in .NET for coercing a value from one type to another, one after another. Once of the techniques must be trying to do the conversion and flat out failing (actually two of them, because all the easy technqiues are wrapped in a try..catch block, so the really expensive final resort technique only occurs as a final resort.
In fact, I have been trying to do this. Our problem is that I cannot seem to replicate the root cause in our development environment and I am not able to step-debug on the production machine.
Our exception logging shows that the StringToDate method, called from the Text property setter in SmartDate, is throwing.
In the development environment, I can emulate the exception, by modifying the date string value (i.e. switching the order of month and day), just before the coercion.
I deployed a patched version of our code to our production machine to get some info into the log. In the logged message, I captured the value of "value" and it is a date string in the format mm/dd/yyyy (eg: 02/27/2009).
This is exactly the same format we see in our development environment - but some setting that is different between the two systems causes StringToDate to fail on on, and not the other.
It is also curious that the workaround with Date.TryParse works - although this is a less than desirable solution.
If I recall correctly, SmartDate uses TryParse() to convert the
date – or maybe it uses Parse().
But CoerceValue() will use System.Convert in some cases, so
maybe that’s what happens?
Without unit test illustrating the problem there’s little I
can do to help change the framework to address it.
Rocky
Copyright (c) Marimer LLC