Dapper v3 planning and discussion

It's time for a major release and we've just been busy with other libraries. In context though, Dapper is far less work to get there. netstandard is already supported and we don't have a long list of desired (breaking) changes to the APIs. Starting a list here to track:

API changes (breaking):

• Optional CancellationToken params on all Async methods (related: #484)
• Dapper.Contrib Insert<T> and Insert<T, TKey> changes for ISqlAdapter (discussion in #640, related: #559, #587)
• Dapper.Contrib - Allow custom ISqlAdapter (#497) (note: this locks us down for any future interface additions)
• SqlBuilder needs a lot of tests and love (#573, #647)
• Overload reduction via CommandFlags (related: #474)

Package Changes (breaking):

• Re-title to "Dapper" & rename Repo (#683)
• Strong-Name for Dapper (deprecating Dapper.StrongName)
• Strong-Name for Dapper.Contrib (#430, #685)

Missing APIs (non-breaking):

• QueryAsync<T> and related have a few missing from the single/first additions
• Dapper.Rainbow netstandard support (#676)

PRs to examine:

• #471 - Allow custom TypeHandlers for standard types (and .SetValue()) (related: #206, #259, #303, #319, #433, #571, #607)
• #458 - Custom type handlers for enums are ignored
• #512 - Fixed #497 by exposing SqlMapperExtensions.AdapterDictionary as public
• #558 - Temporary fix (really want to fix the actual issue: #555)
• #597 - Allow multi-map async queries to be unbuffered (related: #596)
• #636 - Dapper.Contrib - Support for composite keys in Get method

Cleanup

• Documentation cleanup everywhere
• Moving to VS 2017 RC and new .csproj system (off Preview 2 project.json tooling)
• Organize folders (after PRs!): src, tests, docs, etc. (and the same in the solution)
• Release notes/documentation: moving into /docs (GitHub feature post here, note: this allows PRs to update docs easily too)
• Global: Interpolated String usage (#651)
• Firebird Async support (#651 addition)
• #621 - Static property issues on params
• #613 - SimpleMemberMap became internal between 1.42 and 1.50.2
• #551 - Add example for literal replacement to Readme.md
• #480 - Documentation for SqlBuilder
• #451 - Clarify memory documentation
• #417 - Audit where DbCommand.Cancel() is called

Discussion - Should we add a [Column] or [Table] attributes and/or mapping methods?

Discussion in #722, please chime in!

Discussion - Should we add a DynamicParameters.Add() overload in for DB params?

See #659 for details, specifically:

DynamicParameters.Add(string name, DbType type, ...)

...okay that took a while, and it's a lot of info but I'm trying to relate all the issues I see with a common solution path. What did I forget? What's wrong? Thoughts on discussion items above (or pretty much anything of course)?

There will also be some background work I'll take on here. Like being able to more readily test Dapper & Dapper.Contrib against all providers. Luckily Docker has matured enough that having a rich test bed against most providers is finally a reality. I'm working with others in the container and cloud space to make this an option for all, but that's not a blocker by any means.

I haven't even shown this to @mgravell yet. So hopefully he doesn't kinda sorta give me a mild case of death at the next meetup. Due to how # links work...this is the best way to share it for review as well, so here it is.

This is a roadmap rather than a bounded change; start by choosing one unchecked item and reading its referenced issue or PR, such as #484, #640, or #573. The payload names src, tests, docs, /docs, and provider testing as relevant areas, but it does not define a single completion criterion.