WIP: Import DictionaryAdapter from Castle Core

[stakx]

This is in response to castleproject/Core#394 (comment).

@jonorossi, I hope you don't mind my forging ahead and creating this new repository. If you'd prefer it to live over at castleproject-deprecated, I hope it can be transferred there easily.

This PR brings in those parts of Castle Core that are related to DictionaryAdapter.

Some things remain to be done before a NuGet release (if we want to do one at all):

• I suspect we might be able to remove that Explicit.NuGet.Versions tool. IIRC, this is only needed to pin down package dependency versions for the three logging integration packages.

• The namespaces are a bit of a mess. Should we have a clean break and put everything under a new root namespace Castle.DictionaryAdapter?

  Alternatively, we might consider these few juggles:

  • ReflectionBasedDictionaryAdapter and StringObjectDictionaryAdapter are public. Perhaps they could be moved to Castle.Components[.DictionaryAdapter], then we could create empty subclasses (type aliases, if you will) that we put in Castle.Core, but mark as [Obsolete]?

  • A bunch of internal types. Should we move those over to Castle.Components.DictionaryAdapter.Internals?

• README.md is missing some links, e.g. for where to find debugging symbols, the build status badge, or the NuGet feed. We can only add those once you've set up the project on AppVeyor (if desired).

• Set the NUGET_API_KEY env variable on AppVeyor. Or, even better, put it in appveyor.yml as an encrypted environment variable (prepared using AppVeyor data encryption tool).

[jonorossi]

I hope you don't mind my forging ahead and creating this new repository. If you'd prefer it to live over at castleproject-deprecated, I hope it can be transferred there easily.

I probably should have said it before now, I wish you had said you were going to start on this, because I was planning to keep the last 10 years of Git history when creating this repository, using git-filter-branch to remove non-DA code leaving a compact repo for development to continue if people chose. That with the aim of releasing DA v5.0 which breaks from Castle Core versioning so can make breaking changes with namespaces and the like because it would be a new package.

[stakx]

@jonorossi,

I was planning to keep the last 10 years of Git history when creating this repository

My apologies. I have no problem starting all over again (or let you handle it—I'd need to first familiarise myself with git filter-branch). The second time should be much faster, since we can use this PR to quickly see what needs to be removed.

Let me close this PR so we can do this the right way then.

[jonorossi]

My apologies. I have no problem starting all over again (or let you handle it—I'd need to first familiarise myself with git filter-branch)

No my apologies, you're the active one at the moment, I'm the slack busy one. Did we want to start a Castle Core v5 issue over there to work out what we actually want to include. Is v5 going to be an API reduction release?

[stakx]

Did we want to start a Castle Core v5 issue over there to work out what we actually want to include. Is v5 going to be an API reduction release?

I'd say yes to both!

[jonorossi]

I have no problem starting all over again (or let you handle it—I'd need to first familiarise myself with git filter-branch).

I haven't started this. I should have time to do it in the next few days if you wanted me to do it, although I'm happy for you to do it too.

[stakx]

You probably have a clearer idea how exactly this should be done, and are more experienced with filter-branch, so it would be great if you could do it.