Will you support CoreCLR? #241

Jetski5822 · 2015-02-07T15:18:59Z

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

mgravell · 2015-02-07T22:05:38Z

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
#241.

Rinsen · 2015-05-13T12:46:24Z

Have you had some time to investigate this?

Jetski5822 · 2015-05-13T12:48:25Z

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

mgravell · 2015-05-13T14:18:20Z

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
#241 (comment)
.

Rinsen · 2015-05-13T15:32:19Z

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

I will check it out!

mgravell · 2015-05-13T18:49:54Z

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
#241 (comment)
.

Rinsen · 2015-05-14T20:36:49Z

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

Thanks!

mgravell · 2015-05-14T20:39:14Z

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
#241 (comment)
.

cbeall · 2015-07-11T16:59:44Z

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: #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: aspnet/dnx#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?

Rinsen · 2015-08-12T23:04:27Z

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...

aspnet/Mvc#2959

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

pranavkm · 2015-08-24T19:45:12Z

@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"
    }
}

mgravell · 2015-08-24T20:53:25Z

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.

NickCraver · 2015-09-02T23:32:54Z

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!

ShaneCourtrille · 2015-10-07T23:00:19Z

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

NickCraver · 2015-10-08T01:52:13Z

@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).

keith-vikode · 2015-10-20T16:19:24Z

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: aspnet/dnx#2031

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

Rinsen · 2015-10-20T17:34:56Z

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

keith-vikode · 2015-10-20T21:01:55Z

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

NickCraver · 2015-11-27T13:03:02Z

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.

keith-vikode · 2015-11-27T13:05:04Z

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 #241 (comment).

mihevc · 2016-01-18T21:50:53Z

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.

mgravell · 2016-01-18T22:07:44Z

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
#241 (comment)
.

Regards,

Marc

mihevc · 2016-01-18T22:11:01Z

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.

mgravell · 2016-01-18T22:14:45Z

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
#241 (comment)
.

Regards,

Marc

vdaron · 2016-01-19T09:51:36Z

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

mgravell · 2016-01-19T10:20:33Z

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 · 2016-01-19T10:33:21Z

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/

NickCraver · 2016-01-19T10:35:13Z

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.

vdaron · 2016-01-19T11:20:01Z

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.

mgravell · 2016-01-19T16:22:45Z

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
#241 (comment)
.

Regards,

Marc

RichiCoder1 · 2016-05-17T16:06:41Z

bump now that Core and company are RC2

NickCraver · 2016-05-17T18:25:48Z

@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.

RichiCoder1 · 2016-05-18T15:35:50Z

@NickCraver awesome! Thanks and great job :)

jpsingleton · 2016-05-19T09:24:49Z

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 #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!

NickCraver · 2016-05-19T15:21:05Z

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 · 2016-05-19T15:21:37Z

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 · 2016-05-19T15:45:32Z

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

jpsingleton · 2016-05-19T18:22:09Z

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

agoretsky · 2016-05-20T17:24:21Z

what about Jil rc2 support?

NickCraver · 2016-05-20T17:25:40Z

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
#241 (comment)

agoretsky · 2016-05-20T17:28:26Z

@NickCraver, thanks!)

KroanNL · 2016-06-04T16:53:27Z

@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

JMan77 · 2016-11-29T04:44:50Z

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...

mgravell · 2016-11-29T17:30:54Z

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

mgravell · 2016-11-29T17:32:52Z

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.

JMan77 · 2016-11-30T03:27:35Z

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.

mgravell · 2016-11-30T09:27:05Z

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 ***@***.***> 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 <#241 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsP4cCcH6mlL3jyIrQ7umYApsQ1aMks5rDO0ngaJpZM4DdN08> .

-- Regards, Marc

JMan77 · 2016-12-01T03:11:44Z

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

mgravell · 2016-12-01T08:25:58Z

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 ***@***.***> 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 <#241 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsPlmI1z8HTXocTO6OqR8l0xsu1Epks5rDjrxgaJpZM4DdN08> .

-- Regards, Marc

NickCraver · 2017-01-28T15:57:36Z

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

zam6ak mentioned this issue Feb 27, 2015

Update benchmarks to include EF7 #246

Closed

JamesNK mentioned this issue Jul 31, 2015

project.json targeting net20 and net35 aspnet/dnx#1894

Closed

pranavkm mentioned this issue Aug 24, 2015

MVC/Razor issue after updating to beta6 with multiple in-memory assembly on local iis server and azure but not in debug aspnet/Mvc#2959

Closed

NickCraver added the core-clr label Oct 10, 2015

NickCraver closed this as completed Jan 28, 2017

Will you support CoreCLR? #241

Will you support CoreCLR? #241

Comments

Jetski5822 commented Feb 7, 2015

mgravell commented Feb 7, 2015

Rinsen commented May 13, 2015

Jetski5822 commented May 13, 2015

mgravell commented May 13, 2015

Rinsen commented May 13, 2015

mgravell commented May 13, 2015

Rinsen commented May 14, 2015

mgravell commented May 14, 2015

cbeall commented Jul 11, 2015

Rinsen commented Aug 12, 2015

pranavkm commented Aug 24, 2015

mgravell commented Aug 24, 2015

NickCraver commented Sep 2, 2015

ShaneCourtrille commented Oct 7, 2015

NickCraver commented Oct 8, 2015

keith-vikode commented Oct 20, 2015

Rinsen commented Oct 20, 2015

keith-vikode commented Oct 20, 2015

NickCraver commented Nov 27, 2015

keith-vikode commented Nov 27, 2015

mihevc commented Jan 18, 2016

mgravell commented Jan 18, 2016

mihevc commented Jan 18, 2016

mgravell commented Jan 18, 2016

vdaron commented Jan 19, 2016

mgravell commented Jan 19, 2016

mgravell commented Jan 19, 2016

NickCraver commented Jan 19, 2016

vdaron commented Jan 19, 2016

mgravell commented Jan 19, 2016

RichiCoder1 commented May 17, 2016

NickCraver commented May 17, 2016

RichiCoder1 commented May 18, 2016

jpsingleton commented May 19, 2016

NickCraver commented May 19, 2016

NickCraver commented May 19, 2016

NickCraver commented May 19, 2016

jpsingleton commented May 19, 2016

agoretsky commented May 20, 2016

NickCraver commented May 20, 2016

agoretsky commented May 20, 2016

KroanNL commented Jun 4, 2016 • edited Loading

JMan77 commented Nov 29, 2016 • edited by mgravell Loading

mgravell commented Nov 29, 2016

mgravell commented Nov 29, 2016

JMan77 commented Nov 30, 2016

mgravell commented Nov 30, 2016 via email

JMan77 commented Dec 1, 2016

mgravell commented Dec 1, 2016 via email

NickCraver commented Jan 28, 2017

KroanNL commented Jun 4, 2016 •

edited

Loading

JMan77 commented Nov 29, 2016 •

edited by mgravell

Loading