Improved exception messages and logging (fixed #273)

[Athari]

• Changed logging with Trace to TraceSource. Log messages will now contain more information and it will be much easier to process and filter them. See #273 for more details.
• Changed all messages to include detailed information about unresolved objects, incorrect arguments etc. Receiving a message "Column not found" is not very helpful, especially in a library heavily relying on dynamic objects.
• Made sure exceptions are correctly rethrown. In some cases inner exceptions were not supplied to exception constructors which lead to cut off stack traces.
• Minor changes: added ReSharper settings file with your code conventions, fixed pluralization test (it failed if CurrentCulture is different from en-us).

On the whole, all changes are backwards compatible, with one exception: instead of attaching listeners to Trace, developers should now use SimpleDataTraceSource.TraceSource.

You should also review usages of InvalidOperationException. In some cases, UnresolvableObjectException and other specific classes should probably be used, but I didn't risk changing type to avoid exception handling compatibility.

[markrendle]

I'm reluctant at this stage to pull these good but breaking changes into the 1.0 branch. I'm starting a 2.0 branch very soon and will pull onto that. Thanks for the contribution, and apologies for the late response, but I've been really, really busy.

[Athari]

(from http://blog.markrendle.net/) What’s actually happening is that Dan Maharry is working on the docs and finding bugs as he goes along, and when things calm down a bit I’ll fix those bugs and he’ll finish the docs and that will be 1.0 final. I’m really hoping that happens in early summer, because I want to start on 2.0

In theory, 1.0 and 2.0 can be developed simultaneously... ;)

[markrendle]

In theory, yes, but in practice I'm going to be rewriting so much of the internal code that merging fixes from the 1.0 branch would be hideous.

[Athari]

How soon do you expect 2.0 release to be ready? If it's a year away, I doubt maintaining ideal compatibility and unhelpful error messages are preferable over very minor compatibility issues and detailed errors. Unless someone compares exception messages for equality (which is almost always wrong), it's a matter of changing one line of code -- and only in the case the developer uses tracing. With NuGet, it shouldn't be an issue anyway, as versions are kept separately.

[markrendle]

Very good point; you've changed my mind. I'll merge this soon (it needs command-line conflict-resolving merging) and do a new release to NuGet by the end of the week.

[markrendle]

Merged; will release as 0.19 shortly.