Dapper target netcoreapp1.0?

[teilin]

Are there any plans of targeting netcoreapp1.0 for Dapper? I am using dnxcore50 and it works pretty well with Dapper, but I would love to be able to use the dotnetcli.

[mgravell]

Definitely plans. And if you look at the commit history, I think the last
commit+revert was updating (and reverting) the refs to handle that. The
problem is: rc2 is a mess right now, and there is no single configuration
that builds cleanly from any package feed. When that exists: we'll
absolutely want to re-package and re-publish.

Marc
On 14 Apr 2016 7:47 a.m., "Teis Lindemark" [email protected] wrote:

Are there any plans of targeting netcoreapp1.0 for Dapper? I am using
dnxcore50 and it works pretty well with Dapper, but I would love to be able
to use the dotnetcli.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#504

[teilin]

Great.

[NickCraver]

Just an FYI: there's now a netstandard branch with a clean build if you want to try it out.

[la-yumba]

With RC2 now officially released, it would be good to merge the netstandard branch.

It just needs netstandard1.3 to be changed to netstandard1.5

[NickCraver]

I'll get with Marc soon as kids are out the door here and get NuGet updated - I don't follow your netstandard1.5 comment though, why would we need to change this?

[la-yumba]

this is what class libraries shoudl be written in according to the
documentation (as of today)
http://dotnet.github.io/docs/core-concepts/dnx-migration.html

Enrico Buonanno

email: [email protected]
skype ID: enrico.buonanno
Tel: +34 632 333 865

On Thu, May 19, 2016 at 12:04 PM, Nick Craver [email protected]
wrote:

I'll get with Marc soon as kids are out the door here and get NuGet
updated - I don't follow your netstandard1.5 comment though, why would we
need to change this?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#504 (comment)

[mgravell]

The 1.5 is the minimum for targeting just .NET core. If you can use a
lower netstandard level, that's fine - and your library can be used on a
wider set on consumers. Using a lower number is fine. No change is required
here. At very worst case, we could choose to add both as explicit, but I
don't think that is required.

On 19 May 2016 at 12:28, Enrico [email protected] wrote:

this is what class libraries shoudl be written in according to the
documentation (as of today)
http://dotnet.github.io/docs/core-concepts/dnx-migration.html

Enrico Buonanno

email: [email protected]
skype ID: enrico.buonanno
Tel: +34 632 333 865

On Thu, May 19, 2016 at 12:04 PM, Nick Craver [email protected]
wrote:

I'll get with Marc soon as kids are out the door here and get NuGet
updated - I don't follow your netstandard1.5 comment though, why would we
need to change this?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
<
#504 (comment)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#504 (comment)

Regards,

Marc

[henkmollema]

You only need to target a higher .NETStandard if you need more API. Libraries should target the lowest as possible.

[la-yumba]

ok, I just migrated my own library to 1.5 as per docs, then in order to be
able to reference dapper I had to change it to 1.5 as well. (But I may well
be wrong, after all this is my 1st day grappling with this)

Enrico Buonanno

email: [email protected]
skype ID: enrico.buonanno
Tel: +34 632 333 865

On Thu, May 19, 2016 at 2:24 PM, Henk Mollema [email protected]
wrote:

You only need to target a higher .NETStandard if you need more API.
Libraries should target the lowest as possible.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#504 (comment)

[NickCraver]

1.50-beta10 (supporting RC2) has been pushed to NuGet. Let us know if you have any issues!
https://www.nuget.org/packages/Dapper/1.50.0-beta10

[NickCraver]

1.50-rc3 supporting RTM is now on NuGet, and it will become the stable version tomorrow night if we find no issues. Closing this issue out.