Add support for DNX Core

[jtbennett]

Please add a DNX Core version of Microsoft.Azure.DocumentDB. (If you add the code here, I'll help do the work!)

[ghost]

This is something on our radar

[youngpe69]

+1 For that...

[jwuliger]

Yes please! +100 👍

[NickBrooks]

+1

[ealsur]

+1 Willing to help if needed

[cwiederspan]

+1 and also willing to help.

[cwiederspan]

My interest is in building an ASP.NET 5 app that can be coded and run on a Mac with VS Code, which would require being able to run and build the app on the .net core 5 platform. Would likely publish the app to Linux running on Azure.

I suppose I could just use the REST interface instead of the package, but that doesn't sound as fun!

[jwuliger]

I agree with @cwiederspan. Cross-platform compatibility would be nice. I am using the current .NET SDK in a MVC 6 API App, but as we know it can only run on a windows server.

This is also off topic a little... but a connected service (like table storage, sql etc.) for DocDB would be amazing. I know there must be some work there though!.

In my own opinion, using the rest interface directly gives me an uneasy feeling for some odd reason. You can't use all the nice magic of the API and what about layered security? I could be missing some thing though.

Anyway have a great weekend everyone.

[cwiederspan]

Interesting. I had always assumed that the client library was just a nice wrapper on top of the REST calls to the back-end service using HttpClient, similar to the way that Azure Storage library works (I think). I believe that that library is now able to use .net core 5, although I haven't tried it for myself yet.

If only we could see the DocumentDB library in github ;-).

[cwiederspan]

Ryan, out of curiosity, is it your crew that built the SDK for Javascript, too? Does it have feature parity with the .NET SDK? I'm wondering if we could take that JS code and rewrite it in .NET with .net core 5 "compliance"? Or am I over simplifying it?

I guess that's my way for fishing for your thoughts on what kind of gotchas might be hiding out there...?

[ghost]

The .NET library has a custom written Tcp based protocol in addition to HTTP. It also has two modes of connecting, Gateway and Direct. And a few other things like a query parser etc.

The other SDKs, like Node, Java, Python etc. don't have this yet. They are just Gateway over HTTP.

[cwiederspan]

Thanks - good information. That explains the native code interop dependencies. I'll take a look and see if I think I could do a good enough job to make something similar to the JS version that would work with .net core 5. Maybe get some help for your team and or other interested folks...?

[jtbennett]

I'd love to help with that. Count me in.
-JB
On Nov 20, 2015 6:57 PM, "Chris Wiederspan" notifications@github.com
wrote:

Thanks - good information. That explains the native code interop
dependencies. I'll take a look and see if I think I could do a good enough
job to make something similar to the JS version that would work with .net
core 5. Maybe get some help for your team and or other interested folks...?

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

[kpfaulkner]

Hi Ryan,

Our of curiosity, of the other SDK's (Node, Python etc) is one considered
"more complete" than the others? ie, which should the community potentially
look at to see the various underlying REST calls?

Cheers

Ken

On Sat, Nov 21, 2015 at 10:52 AM, Ryan CrawCour notifications@github.com
wrote:

The .NET library has a custom written Tcp based protocol in addition to
HTTP. It also has two modes of connecting, Gateway and Direct. And a few
other things like a query parser etc.

The other SDKs, like Node, Java, Python etc. don't have this yet. They are
just Gateway over HTTP.

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

[ghost]

I wouldn't say any are more complete. The node.js SDK is by far the more popular outside of the the .NET SDK.

[ghost]

We're discuss this dnxcore50 support next week and make a call when we'll add support. Stay tuned.

[youngpe69]

So just to add another data point - yes, the ability to build cross platform in .net would be really useful. My own workflow would be dev on Mac and deploy on Azure. I've started using ASP.NET 5 and have begun playing around with beta 8 of the storage API. Would be really cool to be able to do the same with DocumentDB as I'd have a neat stack to build on then.

See what happens when you let the cross platform genie out of the bottle? :-)

[cwiederspan]

@jtbennett and anybody else interested... I've created a nearly-empty repository here - https://github.com/azure-community/azure-documentdb-dotnetcore - with a quick skeletal of an unimplemented object hierarchy based on browsing the existing SDK. That said, it's probably pretty useless in its current form, but maybe a starting point...?

Anyway, I can certainly tell you that I'm fairly new to the OSS scene, at least in terms of setting up a project from scratch, so I'm happy to handoff the repository to anybody that's got more experience in that department.

I'm also not entirely sure whether we'd be better off trying to work backwards from the existing .NET SDK, or trying to "port" the JavaScript or NodeJS SDK over to dotnetcore, so would love to get anybody's thoughts there.

[ghost]

I wouldn't use the JavaScript SDK. The node.js is a better start.

[kpfaulkner]

Well, given Ryan C was mentioning that MS was going to discuss if they'd do
it themselves (didn't he?). Did a decision come through?
Not sure about "porting" the NodeJS implementation, but more investigate
the requests/responses from that particular SDK.

No?

Anyway, I'm interested :)

On Tue, Nov 24, 2015 at 8:26 AM, Chris Wiederspan notifications@github.com
wrote:

@jtbennett https://github.com/jtbennett and anybody else interested...
I've created a nearly-empty repository here -
https://github.com/azure-community/azure-documentdb-dotnetcore - with a
quick skeletal of an unimplemented object hierarchy based on browsing the
existing SDK. That said, it's probably pretty useless in its current form,
but maybe a starting point...?

Anyway, I can certainly tell you that I'm fairly new to the OSS scene, at
least in terms of setting up a project from scratch, so I'm happy to
handoff the repository to anybody that's got more experience in that
department.

I'm also not entirely sure whether we'd be better off trying to work
backwards from the existing .NET SDK, or trying to "port" the JavaScript or
NodeJS SDK over to dotnetcore, so would love to get anybody's thoughts
there.

—
Reply to this email directly or view it on GitHub
#60 (comment)
.

[ghost]

We're doing some tests now to see how much of the current SDK breaks on .NET Core. You might want to wait a few days until we know the extent of the changes needed.

I'd hate this to be throw away effort.

[cwiederspan]

Absolutely agree about waiting a few days or more - plenty busy without venturing down this path.

[pherbel]

When will you support?

[chrizy]

+1

[ghost]

Sorry for delay in getting back to everyone on the thread;
We've looked at this and will hopefully be able to add support for this in Q1 2016.
Sorry for long delay, but there's a ton of stuff already inflight that we're working on before we can get to this.

[kpfaulkner]

Thanks for the update

On 17 Dec 2015, at 09:04, Ryan CrawCour notifications@github.com wrote:

Sorry for delay in getting back to everyone on the thread;
We've looked at this and will hopefully be able to add support for this in Q1 2016.
Sorry for long delay, but there's a ton of stuff already inflight that we're working on before we can get to this.

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

[peterblazejewicz]

👍

[knom]

👍
.NET Core is key for me as well :-)

[tedvanderveen]

+1

[christianlegault]

+1

[jj09]

+1

[deman4ik]

+1

[Bigsby]

This should be implement as Entity Framework Core middleware.

[svickers]

Holy moly surprised to see this doesn't exist already, +1

[MiddleTommy]

Wouldn't it be better to have the client library be a .NET Standard library? That way it could be used from almost any platform?

[francismooreqc]

+1

[sandorfr]

@MiddleTommy I could not imagine they would do it another way :)

[MahmoudElShazly]

+1

[tanwarsatya]

unimaginable no support for the document dB,

[MoaidHathot]

+1. It is really unimaginable that Microsoft Azure DocumentDB doesn't support .Net Core.

[jplindgren]

+1. It is really unimaginable that Microsoft Azure DocumentDB doesn't support .Net Core.

[spontoreau]

+1

[lucafabbri]

+1

[markglibres]

+1

[Gertm]

+1

[adamdriscoll]

+1

[markuslindberg]

+1 Looking forward to this.

[dmccaffery]

Has anyone tried using MondoDB.Driver 2.3.0-rc1 along with mongodb protocol support for DocumentDB: https://azure.microsoft.com/en-us/documentation/articles/documentdb-connect-mongodb-account/

This, theoretically, will allow CoreCLR to work with Azure DocumentDB (and will also allow migration to other platforms where MongoDB is supported) -- not to mention local testing on non-Windows platforms where the Storage Emulator is not available.

Just a thought -- I'll be diving into this as a solution soon.

[dmccaffery]

Also, please stop using "+1" posts... it floods peoples feeds. Use "Reactions" instead!

[sandorfr]

@dmccaffery while this is definitely a workaround, this does not provide a migration path from net451 nor supports for the new binary protocol. This is also quite experimental as well.

[dmccaffery]

Agreed; definitely not meant as a long-term solution -- if you're starting from square one, though, it is an interesting alternative. Mainly because it enables migration to other services and cloud environments where MongoDb can run (hypothetically).

[MoaidHathot]

Btw, I've tweeted about it to the Azure DocumentDB team and they told me they are working on it, and that they will release it before the end of the year.

[sandorfr]

@MoaidHathot it was supposed to be Q1 then Q2 now before the end of the year...

[JohanOhlin]

According to this recent .NET Blog post:

The next version of the DocumentDB client library, which will be available around the Connect event, supports .NET Core.

The next Connect event is taking place November 16-18, so it's basically around the corner :)

[henkmollema]

There it is: https://www.nuget.org/packages/Microsoft.Azure.DocumentDB.Core 🎉

Introducing blog post: https://azure.microsoft.com/en-us/blog/documentdb-emulator-for-local-development-and-dotnet-core-support/.

[arramac]

Now available! https://www.nuget.org/packages/Microsoft.Azure.DocumentDB.Core