Deserialization doesn't work for properties with non-public setters that reside in a base class

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a base class with a property that has a private setter.
2. Create a derived class.
3. Deserialize the derived class, with the base class property included.

What is the expected output? What do you see instead?
The base class property is ignored.

Please provide any additional information below.

I have implemented a fix.  Revision 944d3ebb699b of 
http://code.google.com/r/paulbartrum-dapper-dot-net

Original issue reported on code.google.com by paulbart...@gmail.com on 23 Apr 2011 at 2:05

[GoogleCodeExporter]

I pulled in that change, but the date thing worries me. 

If we are munging dates coming in from the DB, do we need to munge dates passed 
in as params? 

Are we encouraging bad practices, with a disconnect between the DB and the apps 
dates?

Original comment by sam.saff...@gmail.com on 26 Apr 2011 at 1:30

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I'm working on a project where all the dates in the database are UTC - however 
they are all stored as SQL Server datetimes, so the DB doesn't actually know 
this.  Thus when the dates are pulled into .NET DateTime objects, the Kind 
property is Unspecified.  This is a problem for me because ToLocal() and 
ToUniversal() don't work reliably on unspecified DateTimes (for example, 
ToUniversal() assumes the date is in local time).

> If we are munging dates coming in from the DB, do we need to munge dates 
passed in as params?

No, this issue occurs because .NET DateTimes have a timezone component and SQL 
Server datetimes don't.  The same problem doesn't occur in reverse.

> Are we encouraging bad practices, with a disconnect between the DB and the 
apps dates?

The dates remain the same, this just affects how the dates are interpreted.

Original comment by paulbart...@gmail.com on 26 Apr 2011 at 8:41

• Added labels: ****
• Removed labels: ****