Azure-cosmos-dotnet-v2: 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 :+1:

[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" [email protected]
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
https://github.com/Azure/azure-documentdb-dotnet/issues/60#issuecomment-158562404
.

[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 [email protected]
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
https://github.com/Azure/azure-documentdb-dotnet/issues/60#issuecomment-158561762
.

[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 [email protected]
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
https://github.com/Azure/azure-documentdb-dotnet/issues/60#issuecomment-159069600
.

[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 [email protected] 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]

:+1:

[knom]

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

[tedvanderveen]

+1

[lenardg]

@ryancrawcour any updates if we are still on track for a Q1 2016 update that would support .NET Core? Thanks!

[ghost]

I will update this thread once we have more info.

[ealsur]

@ryancrawcour another option is if you can expose the Swagger files for the APIs, use Autorest to generate the clients :)

[ghost]

thanks @ealsur . this is already in progress, however this will give you a very basic client. might be enough for some.

[jpearnshaw]

+1

[sandorfr]

@ryancrawcour it is apparently planned to open source the client. If it were to be done anytime soon, the community might work/help on this :).

[poteb]

+1 Any update on the eta?

[timmydo]

@ryancrawcour to clarify, will the result of this work make it so the nuget package can target netstandard? I'm building a dotnet cli web application using asp.net core for windows and am trying to compile against netstandard1.5, but documentdb requires me to target net46 or similar.

https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

thanks

[Bigsby]

It is, indeed, that one can't implement an ASP.Net 5 Web API that uses this. Let's do this, guys.

[figox]

+1

[peterblazejewicz]

https://blogs.msdn.microsoft.com/webdev/2016/05/11/notes-from-the-asp-net-community-standup-may-10-2016/
https://live.asp.net/

Question: Do we have any commitment or knowledge from Azure team as to how long after RC2 release (or RTM for that matter) will PaaS components will support it?
The Azure team is working with the ASP.NET Core team, and this should be ready very soon after each release. Scott suggested that the two of them record the upgrade process for a web application as a demo.

[OnTheMike]

Any progress on this issue? Having some issues with RC1 which are resolved in RC2, but can't upgrade due to dependency on DocumentDB.

[pherbel]

any update?

[tallichet]

any update? now that Q1 and almost Q2 reached the end...

[tedvanderveen]

+1

[sunneh]

+1

[tverboon]

At some point I need to make a decision: https://jira.mongodb.org/browse/CSHARP-1177

[sandorfr]

@tverboon The total lack of communication since a few monthes now and the fact that it is closed source and cloud only are really worrying me. It feels like the product is going to follow the tragic fate of SQL Azure Federations or AppFabric Caching and being discontinued. A less tragic one would be table storage, a walking dead product seeing no real improvements and having a big monolithic sdk which is a real pain.

[ghost]

maybe @aliuy can comment on this.

[ealsur]

@sandorfr I think that the strategy is across all Azure SDKs, not just DocumentDB. On previous versions there where dependencies on packages like Hyak that made portability impossible. It made sense to migrate to a Swagger-Autorest scenario and decorate the autogenerated client with a more friendly structure, I think that's the approach that most (if not all) the Azure SDKs are taking to be able to support Core.

[tallichet]

@ryancrawcour @ealsur do you mean their is no work in progress as of today? if there is one, could you indicate a project? I'll do my best to work on it.

[ealsur]

@tallichet I didn't say there is no work in progress, I said that it is probably a big change for the Azure SDKs and that they are surely working on it hand in hand with the .Net Core team, my guess is that the path might be using Swagger+Autorest (but it's a guess) and it's something being done across all Azure SDKs, not just DocumentDB.

[sunneh]

@ealsur Regardless if there is a big rewrite in process for the dotnet core adjustment it takes two seconds to inform the users of the SDK. The lack of communication is concerning.

[aliuy]

I can confirm .NET Core support is on the DocumentDB roadmap, but there are currently no timelines as this involves quite a bit of non-trivial work.

[tverboon]

@aliuy Thanks for sharing. I guess a lot of us were under the impression that .Net Core support was right around the corner. Hopefully MS will also make this library open source when you're actively porting this to .Net Core and the planned work for this is clear.

[kaleemxii]

+1

[tedvanderveen]

+1

[murilocurti]

+1

I think that as .Net Core 1.0 was released the implementation should be done fast.
Let us know if you need any help on that ;)

[oleksii-udovychenko]

+1

It would be greate to have this asap.

[Radar5000]

+1

asap

[weslleyhenrique]

+1

[JonathanMolina]

+1

[Assassyn]

+1

[FabioReis]

+1

[gabrielgio]

+1

[caserzer]

+1

[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 :tada:

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