Allow Properties instead of fields

[MarcosMeli]

If we go ahead with the rewrite of the RecordInfo class we can take this into account

Now only supports AutoProperties

[killergege]

I'm curious, why you didn't support properties right out of the box ? Why fields only ? Are they easier to manage ?
Even for the auto properties, I see that behind the scene you get the backing field created by the compiler.

I'm interested by this feature by the way, I've been sad to see that my custom properties weren't in the ouput file.

[MarcosMeli]

Hi There

Yes the library started with fields in 2004 mostly because if you support properties you must to ensure that are writable, can throw errors, can slow down assignment with custom code, also the reflection of .net 1.1 were incredible slow and dynamic code generation for fields was easy to implement

Later for backward compatibility and lazyness I didn't support properties, now autoproperties work better thanks to work in this PR #170

But we must to do the effort and support full properties and try to make a little impact in the previous code to avoid weird errors, maybe with new record classes

DelimitedRecordUsingProperties
FixedLengthRecordUsingProperties

So we can make it clear from the class definition what the RecordInfo must look for

what do you think ?
Marcos

[davidbmckenzie]

I vote for the new UsingProperties attributes. If you tried to share the attribute with both Fields and Properties then you'd have to check for the existence of the attribute on both (properties and fields) and throw an exception if they differ in ultimate effect, which is well annoying.

[robertcoltheart]

Is there still any interest in making this change? I'd like to submit a PR if so.

[robertcoltheart]

Ignore, I found the issue here #331