Add Configuration API

[Mike-E-angelo]

ExtendedXmlSerializer should have a configuration API that allows users to setup the configuration of the serializer and then instantiate it accordingly. From #20 (comment):

//Without configuratino
var serializer = new ExtendedXmlSerializer();
// with configuration
var serializer = new ExtendedXmlSerializer(config);
// or from configuration
var serializer= config.CreateSerializer();
In configuration you will be able to configure all settings:

for example:

ExtendedXmlSerializer.Initialize(cfg =>{
cfg.ConfigType<OtherClass>()
.Property(p=>p.Id).ObjectReference().AsAttribute()
.Property(p=>p.Password).Encrypt()
.Property(p=>p.UserName).ChangeName("User").Order(1)
.AddExtension(AttachedPropertyToOtherClass);

cfg.UseAutoProperties();
cfg.UseNamespaces();
cfg.AddExtension(AttachedPropertyToAllTypeExtension);
});

[WojciechNagorski]

I don't have too much time to the end of the year. I'm going to do this job after you part because you can change or simplify something.
Do you know when you can make new deserializer?

[Mike-E-angelo]

Yeah no worries. I ended up with another week of free time, so I will see what I can get done. :) FWIW, I have the v2 performance down to 276us. So that's 200us of bloat currently that I hope to ween down today.

[WojciechNagorski]

276us sounds better :)

[Mike-E-angelo]

Alright, I managed to get this down to 165us. (Initially I said 215us, but that was due to turning off one of the caches). It's a much more simplified model, but I have a lot of broken things now that I need to get fixed.

The reason why it was so slow was:

1. The serializer had "all the things" added to it, so it was going through a whole bunch of unnecessary steps.
2. Extensions were enabled by default, so every context change would query whether or not to continue. This is expensive and should be a configuration.
3. WAY too complex of a model. I got rid of IPlan and will be getting rid of ISerializationProfile tomorrow.

Here are the reasons why it is 165us vs. 76us in v1:

1. Encapsulated logic into IInstruction objects.
2. Keeping track now of state with an IWriteContext that keeps track of current node along with parent and other state-related information.

So now we're sitting at about twice as slow as v1. Hey, twice the features, half the speed. 😆 I am not sure how much more I can squeeze out of it. I think this is a good point to stop at and if we really want to squeeze more performance out of it we can do it some other time.

In any case, it might take me another day or so to get all the functionality back. Maybe a little bit more. I am hoping to incorporate the new configuration as discussed here and hopefully get it right. Then I can finally start working on that deserializer and call this thing done. :P

[WojciechNagorski]

Yes it is good result for this moment!

[WojciechNagorski]

It is inspired configuration from automaper. https://github.com/AutoMapper/AutoMapper.
We should create profile too.

[Mike-E-angelo]

OK great... I have used AutoMapper and have found it a little too complicated for my tastes. :( Of course, I am also the same person that checked in an overly-complicated v2 serializer on my first try. 😆 But, I do like it's API. I like your API/pseudo-code above and will use that as a reference/inspiration. 👍

[WojciechNagorski]

In this task I have to do profile.

[Mike-E-angelo]

This should all now be done and available in v2. If you encounter a problem around expected functionality, please open a new issue (or issues :)) and we will take it from there.

[Mike-E-angelo]

Pre-release deployment for this feature can be found at these feeds:
https://www.myget.org/feed/wojtpl2/package/nuget/ExtendedXmlSerializer
https://www.nuget.org/packages/ExtendedXmlSerializer/2.0.0-alpha