According to Allow Properties instead of fields #67
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
There seem to have been some changes made against Autoproperties full support #170 but this hasn't been included in the release yet. It only seems to be available on the master branch.
I will be merging this but later I will change the way it works to
avoid use of both autoproperties and fields and also to allow
properties in the general way, but your implementation make the use of
autoproperties a simple task
If you're not happy with using that, I would suggest just creating a separate class for the import/export to mirror your existing class but using fields, as suggested by the accepted answer to Formatting properties with FileHelper. Probably the safest bet for now until they get released.