Dapper 🚀 - Will you support CoreCLR?

Only in the "yeah, that'd be good" sense of "plans". I haven't had
opportunity to investigate, although from what I gather the restricted
metaprogramming means it won't be trivial, and the underlying data API is
significantly different. So: it isn't trivial.

I need to set some time aside to investigate.
On 7 Feb 2015 15:19, "Nicholas Mayne" [email protected] wrote:

Hey - Are there any plans to port Dapper over the the CoreCLR?

—
Reply to this email directly or view it on GitHub
https://github.com/StackExchange/dapper-dot-net/issues/241.

mgravell on 7 Feb 2015

Have you had some time to investigate this?

Rinsen on 13 May 2015

Seems as though there is a branch! https://github.com/StackExchange/dapper-dot-net/tree/CoreCLR

Jetski5822 on 13 May 2015

Oh, there's more than a branch - the branch has merged, and I dropped some
beta packages to NuGet. This was only in the last week or so - I just
forgot to update here. Let me know if you get any problems in beta* - but
more that the latest does _not_ include the CorwCLR bits
On 13 May 2015 1:48 pm, "Nicholas Mayne" [email protected] wrote:

Seems as though there is a branch!
https://github.com/StackExchange/dapper-dot-net/tree/CoreCLR

—
Reply to this email directly or view it on GitHub
https://github.com/StackExchange/dapper-dot-net/issues/241#issuecomment-101652850
.

mgravell on 13 May 2015

There have for sure been some time invested, interesting :)

I will check it out!

Rinsen on 13 May 2015

This is the one you want for now:

https://www.nuget.org/packages/Dapper/1.41.0-beta5
On 13 May 2015 4:32 pm, "Fredrik Rinsén" [email protected] wrote:

There have for sure been some time invested, interesting :)

—
Reply to this email directly or view it on GitHub
https://github.com/StackExchange/dapper-dot-net/issues/241#issuecomment-101716260
.

mgravell on 13 May 2015

The parts of dapper that i use seems to work as they should :)

Thanks!

Rinsen on 14 May 2015

Just watch out for anything involving precision/scale: the current
sql-server provider (nothing to do with me) is broken here. I have loggd
bugs.
On 14 May 2015 9:36 pm, "Fredrik Rinsén" [email protected] wrote:

The parts of dapper that i use seems to work as they should :)

Thanks!

—
Reply to this email directly or view it on GitHub
https://github.com/StackExchange/dapper-dot-net/issues/241#issuecomment-102161770
.

mgravell on 14 May 2015

The 1.41.0-beta5 build already appears to be stale with the latest dnx release. I had to make a few changes (discussed here: https://github.com/StackExchange/dapper-dot-net/pull/310), rebuild and locally deploy the package to get it working. An updated prerelease package on Nuget would help, but ultimately there seems to be a challenge with naming and versioning to support the various frameworks.

As it stands now, there doesn't appear to be a way to have net35 alongside dnx451 and dnxcore50 in a single package. There is an question posed about it here: https://github.com/aspnet/dnx/issues/1894. The solution taken in the above package 1.41.0-beta5 was to remove net35, but that approach would be a breaking change. Presumably this limits the ability to have CoreClr support in a package not marked as prerelease.

I realize that CoreCLR is still in Beta, but are there any thoughts on how Dapper CoreClr support will work going forward?

cbeall on 11 Jul 2015

Do you have any plans to create a build targeting asp.net beta6 @mgravell ?

The beta5 package gave me some real headache yesterday and today when i tried to do some updates to beta6, but I don´t really understand why dnx/asp.net did not give me a better clue of what was wrong...

https://github.com/aspnet/Mvc/issues/2959

Ignore this, it is only in one of my environments....

Rinsen on 13 Aug 2015

@mgravell seems like the System.Runtime reference (https://github.com/StackExchange/dapper-dot-net/blob/master/Dapper/project.json#L16) under net45 is the cause of the issue @Rinsen is running into. Could you move the reference to the frameworkAssemblies node?

"net45": {
    "compilationOptions": { "define": [ "ASYNC" ], "warningsAsErrors": true },
    "frameworkAssemblies": {
        "System.Data": "4.0.0.0",
        "System.Runtime": "4.0.0.0"
    }
}

pranavkm on 24 Aug 2015

I haven't had time to update with the latest betas etc; I will blow the
dust off and investigate. Thanks for the suggestion re the main change - it
helps!

On 24 Aug 2015 8:45 pm, "Pranav K" [email protected] wrote:

@mgravell seems like the System.Runtime reference (
https://github.com/StackExchange/dapper-dot-net/blob/master/Dapper/project.json#L16)
under net45 is the cause of the issue @Rinsen is running into. Could you
move the reference to the frameworkAssemblies node?

"net45": {
"compilationOptions": { "define": [ "ASYNC" ], "warningsAsErrors":
true },
"frameworkAssemblies": {
"System.Data": "4.0.0.0",
"System.Runtime": "4.0.0.0"
}
}

—
Reply to this email directly or view it on GitHub.

mgravell on 24 Aug 2015

Update on this: I've updated the CoreCLR packages, but we're looking through other open issues and PRs before doing another NuGet push on a 1.43 beta. We're tight on time over here, so thanks for the patience!

NickCraver on 3 Sep 2015

Any update on this? I'd love to be able to use Dapper for my dnxcore project.

ShaneCourtrille on 8 Oct 2015

@ShaneCourtrille Sorry, we've been a bit busy and haven't gotten to pull requests - there is .Net core support on NuGet that will use the latest packages on most restores anyway (due to newest-wins resolution) - check out 1.41-beta5 here: https://www.nuget.org/packages/Dapper/1.41.0-beta5 (I'm using it without problems in a DNX solution now).

NickCraver on 8 Oct 2015

Just tried using the 1.41.0-beta5 on an ASPNET5 1.0.0-beta8 site, and I'm seeing the following error in the build output:

MSBUILD : DNX 4.5.1 error CS1703: Multiple assemblies with equivalent identity have been imported: 'C:\Users\KeithWilliams\.dnx\packages\System.Runtime\4.0.20-beta-22816\lib\net45\System.Runtime.dll' and 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\System.Runtime.dll'. Remove one of the duplicate references.

Quick Google suggests: https://github.com/aspnet/dnx/issues/2031

Keep up the good work, looking forward to running my project CoreCLR only!

keith-vikode on 20 Oct 2015

That is related to the issue I had earlier and that @pranavkm suggest a solution on.

Rinsen on 20 Oct 2015

Oops, you're right, should've read the thread more closely!

keith-vikode on 20 Oct 2015

CoreCLR support is in beta by the way - 1.50-beta* should be very CoreCLR friendly. I'll leave this open a while longer for feedback...but we should be good to go here.

Outside Dapper, CoreCLR work is not done. The discussion about what the differences between CLR and CoreCLR _should be_ regarding the bits very important to Dapper and other ORMs is far from resolved.

NickCraver on 27 Nov 2015

Just FYI, 1.50-beta is working like a dream for me when combined with the beta System.Data.SqlClient package!

On 27 Nov 2015, at 13:03, Nick Craver [email protected] wrote:

CoreCLR support is in beta by the way - 1.50-beta* should be very CoreCLR friendly. I'll leave this open a while longer for feedback...but we should be good to go here.

Outside Dapper, CoreCLR work is not done. The discussion about what the differences between CLR and CoreCLR should be regarding the bits very important to Dapper and other ORMs is far from resolved https://github.com/dotnet/corefx/issues/3480.

—
Reply to this email directly or view it on GitHub https://github.com/StackExchange/dapper-dot-net/issues/241#issuecomment-160135341.

keith-vikode on 27 Nov 2015

I have a rough version of the net connector mysql driver converted for corefx. I haven't been able to figure out a way to reach the net connect team to offer them the code. You can ping me if you are interested. It runs with 1.50 dapper beta. All the mysql tests are passing in dapper and contrib. There might be some features disabled in the mysql driver but all the code is there.

mihevc on 18 Jan 2016

That's awesome news. By the "net connect" team, do you mean at mysql? I
actually looked at trying to do this myself, but after several hours of
searching I couldn't even find the code, let alone find a well-managed
contribution process. I do remember the process looking more bureaucratic
and complex than github! If you don't mind, I'll try to use my reach to
help track down some contacts. Let's do this!

;p

On 18 January 2016 at 21:50, mihevc [email protected] wrote:

I have a rough version of the net connector mysql driver converted for
corefx. I haven't been able to figure out a way to reach the net connect
team to offer them the code. You can ping me if you are interested. It runs
with 1.50 dapper beta. All the mysql tests are passing in dapper and
contrib. There might be some features disabled in the mysql driver but all
the code is there.

—
Reply to this email directly or view it on GitHub
https://github.com/StackExchange/dapper-dot-net/issues/241#issuecomment-172663509
.

Regards,

Marc

mgravell on 18 Jan 2016

Yes, MySql. It's the code from this site. https://dev.mysql.com/downloads/connector/net/6.9.html. It took me a good week to convert and get the unit tests passing. There is a lot of security and streaming that is different between corefx and dot net.

mihevc on 18 Jan 2016

As far as I can tell, the "process" (quotes quite intentional... I'm not
sure it qualifies) would be to file a bug on http://bugs.mysql.com/ under
the category Connector / NET; I suspect your changes are too large to
conveniently attach, so probably best to just indicate that you have a
working implementation. I suspect Chiranjeevi Battula is the person who
needs to see it.

On 18 January 2016 at 22:11, mihevc [email protected] wrote:

Yes, MySql. It's the code from this site.
https://dev.mysql.com/downloads/connector/net/6.9.html. It took me a good
week to convert and get the unit tests passing. There is a lot of security
and streaming that is different between corefx and dot net.

—
Reply to this email directly or view it on GitHub
https://github.com/StackExchange/dapper-dot-net/issues/241#issuecomment-172667791
.

Regards,

Marc

mgravell on 18 Jan 2016

A litlle off topic here,

@mihevc @mgravell beware of License issue with Mysql official connector (GPL) all code using it must be GPL as well. (I still have to manage this issue in SimpleStack as well)

My two cents

vdaron on 19 Jan 2016

That's very relevant; interesting. Options, then, as I see it:

license the test project as GPL
remove the mysql tests
create a demonstrably separate project (different repo) for the mysql tests with a GPL license
see if we qualify for the FOSS exemption somehow
(other options)

Since nobody will be consuming the test project, I don't see the first one as problematic, but IANAL as to whether that is sufficient. I will ponder.

mgravell on 19 Jan 2016

I think we're ok here;

we're not distributing their libraries
apache 2.0 is listed in http://www.mysql.com/about/legal/licensing/foss-exception/

mgravell on 19 Jan 2016

Yep, agree with @mgravell's interpretation above after independently researching here. Are you aware of the FOSS exceptions @vdaron? They do list MIT (for SimpleStack) but no version.

NickCraver on 19 Jan 2016

I was not aware of these foss exceptions.

If it is not a problem for Dapper/SimpleStack, it remain important for people using Dapper/SimpleStack for non free software.

vdaron on 19 Jan 2016

As I interpret it, though, that is more a case of people knowing what their
dependency chain is. Since you have specific sub-packages that explicitly
target MySql, I can totally see that you'd want to make it clear to people
"hey, if you do this, you're taking a dependency on something that has
licensing you really need to know about". It doesn't really apply so much
to dapper at the moment, as we don't have any package code that would take
that dependency; instead, the situation is reversed: the user takes a
dependency on dapper and whatever ADO.NET provider they choose (nothing to
do with us). And obviously, they are responsible for their choice of
dependencies.

Very much worth taking a few minutes for us to look into, but I just don't
think it impacts dapper. If you disagree, can you be more specific as to:
how?

On 19 January 2016 at 11:20, Vincent DARON [email protected] wrote:

It is especially important for people using Dapper/SimpleStack for non
free software

—
Reply to this email directly or view it on GitHub
https://github.com/StackExchange/dapper-dot-net/issues/241#issuecomment-172821408
.

Regards,

Marc

mgravell on 19 Jan 2016

_bump_ now that Core and company are RC2

RichiCoder1 on 17 May 2016

👍1

@RichiCoder1 I have updated for RC2 here: https://github.com/StackExchange/dapper-dot-net/tree/netstandard We'll give it a sanity check before merging in and get an RC2 package up as soon as Marc and I can find some time to review.

NickCraver on 17 May 2016

👍4

@NickCraver awesome! Thanks and great job :)

RichiCoder1 on 18 May 2016

Just to add that I had beta 8 working well on RC1 but can't get beta 8 or 9 working on RC2. I get the following error after porting and running a web app that builds fine.

FileNotFoundException: Could not load file or assembly 'System.Data.SqlClient ...

So looking forward to beta 10. Interesting comment in https://github.com/StackExchange/dapper-dot-net/issues/504 BTW.

I've had to mark Dapper as not supported now on https://anclafs.com but I'll change this when the fixed package is out. Or feel free to send a PR to https://github.com/jpsingleton/ANCLAFS.

Keep up the good work @NickCraver @mgravell!

jpsingleton on 19 May 2016

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 on 19 May 2016

Oh and StrongName is available too, if you're sick and twisted like that:
https://www.nuget.org/packages/Dapper.StrongName/1.50.0-beta10

NickCraver on 19 May 2016

Scratch that. beta10 is lower than beta9 in semantic versioning. Luckily, rc2 isn't so I figure that was much clearer.
New link: https://www.nuget.org/packages/Dapper/1.50.0-rc2

NickCraver on 19 May 2016

❤1

Awesome, works a treat. Thanks guys. I've reverted my previous update.

jpsingleton on 19 May 2016

what about Jil rc2 support?

agoretsky on 20 May 2016

Oh right, I'll get to it soon. I have a backlog of stuff here - will get a
PR to Kevin soon as I can get eyes on it.
On Fri, May 20, 2016 at 1:24 PM Anton Goretsky [email protected]
wrote:

what about Jil rc2 support?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/StackExchange/dapper-dot-net/issues/241#issuecomment-220667189

NickCraver on 20 May 2016

@NickCraver, thanks!)

agoretsky on 20 May 2016

@NickCraver Hey. Thanks for al your work. If I use the dapper rc2 package, I get an error when compiling saying that my SqlConnection does not support "Execute". I have the appropiate using Dapper statement. Anything I'm missing?

using (IDbConnection db = new SqlConnection(connectionString)) { var sql = "random sql statement" db.Execute(query, product);}

Edit: Nevermind. Updating to the rc2a version of dapper worked

KroanNL on 4 Jun 2016

Thanks for the great work around Dapper. I have it running well in a .net 4.5 environment, but am getting some issues when porting to .net Core with Sql Server. Is there a known issue around the exception below? I can see my sql executing on sql profiler, but then receive this error. Does anyone have a solution for this?

                using (SqlConnection cn = DbConnection)
                {
                    cn.Open();
                    var result = cn.Query<T>("SELECT * FROM Users");
                    cn.Close();
                    return result.ToList();
                }

The server is attempting to use a feature that is not supported on this platform. Received an unsupported token 'Udt' while reading data from the server. at System.Data.SqlClient.TdsParser.TryCommonProcessMetaData(TdsParserStateObject stateObj, _SqlMetaData col) at System.Data.SqlClient.TdsParser.TryProcessMetaData(Int32 cColumns, TdsParserStateObject stateObj, _SqlMetaDataSet& metaData) at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady) at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData() at System.Data.SqlClient.SqlDataReader.get_MetaData() at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, SqlDataReader ds) at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method) at System.Data.SqlClient.SqlCommand.ExecuteReader() at SqlServerTests.Program.Main(String[] args) in...

JMan77 on 29 Nov 2016

That's very odd; what is T in that?

mgravell on 29 Nov 2016

Note: that error is happening inside the SqlClient ADO.NET library - not in dapper. My first guess would be that one of the columns is ... "unusual" in some way? What are the columns here? Also: is this SQL Azure? We've seen cases in the past where SQL Azure works differently, so it would be good to rule that out.

mgravell on 29 Nov 2016

Thanks for the feedback. The issue seems to be the sql geography type. When using Dapper 1.4.2 and querying the same table, I get results, but using Dapper 1.50.3-beta1 or 1.50.2 with .net Core, I get the issue above. I took the geography column out and it worked fine. I've tried both Sql 2012 and Sql 2014.

JMan77 on 30 Nov 2016

Can I ask a question? Does it work if you use ADO.NET directly? For
example:

using(var cmd = conn.CreateCommand()) {
     cmd.CommandText = "what you had";
     cmd.CommadType = CommandType.CommandText;
     using(var reader = cmd.ExecuteReader()) {
         while(reader.Read()) {
             // do something...
         }
     }
}

(c# is from memory, might need tweaks)

If the above works: we might need to fix dapper; if it fails, the problem
is in SqlClient and we should get it logged there.

On 30 November 2016 at 03:27, JMan77 notifications@github.com wrote:

Thanks for the feedback. The issue seems to be the sql geography type.
When using Dapper 1.4.2 and querying the same table, I get results, but
using Dapper 1.50.3-beta1 or 1.50.2 with .net Core, I get the issue above.
I took the geography column out and it worked fine. I've tried both Sql
2012 and Sql 2014.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/dapper-dot-net/issues/241#issuecomment-263773319,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsP4cCcH6mlL3jyIrQ7umYApsQ1aMks5rDO0ngaJpZM4DdN08
.

--
Regards,

Marc

mgravell on 30 Nov 2016

You're right - using ADO.net results in the same error and it's specifically around the geography type.

JMan77 on 1 Dec 2016

Thanks, that's really helpful for me, for when it next gets reported. As
you can imagine, though: I don't think dapper can possibly do anything
here, except perhaps to catch this specific exception and re-throw it with
something that makes it more obvious who to blame...

On 1 December 2016 at 03:11, JMan77 notifications@github.com wrote:

You're right - using ADO.net results in the same error and it's
specifically around the geography type.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/dapper-dot-net/issues/241#issuecomment-264067300,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsPlmI1z8HTXocTO6OqR8l0xsu1Epks5rDjrxgaJpZM4DdN08
.

--
Regards,

Marc

mgravell on 1 Dec 2016

Closing this issue out, .NET Core is rocking on and comments above aren't related to Dapper overall

NickCraver on 28 Jan 2017

Dapper: Will you support CoreCLR?

Most helpful comment

All 50 comments

Related issues