Efcore: Use the new Cosmos SDK

[Mortana89]

I've integrated Cosmos DB in my ASP.NET Core API project, using the latest EF Core package that ships with a Cosmos DB provider.

I'm able to successfully use this provider when running locally in my local ASF cluster, connecting to a local Cosmos DB emulator instance. However, when trying to either run in local ASF or Azure-hosted ASF, I'm unable to connect to the Azure Cosmos DB instance. For some reason I keep getting a 400 BadRequest when initializing the seed for the database/collection.

Exception message: BadRequest
Stack trace:
BadRequest
     at Microsoft.EntityFrameworkCore.Cosmos.Storage.Internal.CosmosClient.CreateDocumentCollectionIfNotExistsOnceAsync(DbContext _, String collectionId, CancellationToken cancellationToken)
       at Microsoft.EntityFrameworkCore.Storage.ExecutionStrategy.ExecuteImplementationAsync[TState,TResult](Func`4 operation, Func`4 verifySucceeded, TState state, CancellationToken cancellationToken)
       at Microsoft.EntityFrameworkCore.Storage.ExecutionStrategy.ExecuteImplementationAsync[TState,TResult](Func`4 operation, Func`4 verifySucceeded, TState state, CancellationToken cancellationToken)
       at Microsoft.EntityFrameworkCore.Cosmos.Storage.Internal.CosmosDatabaseCreator.EnsureCreatedAsync(CancellationToken cancellationToken)
       at Infrastructure.SystemDataContextSeed.SeedAsync(SystemDataContext context) in Infrastructure\SystemDataContextSeed.cs:line 21
       at xtensions.IWebHostExtensions.Seed(IWebHost webhost) in Extensions\IWebHostExtensions.cs:line 23
       at Api.<>c__DisplayClass1_0.<CreateServiceInstanceListeners>b__1(String url, AspNetCoreCommunicationListener listener) in AccountApi.cs:line 47
       at Microsoft.ServiceFabric.Services.Communication.AspNetCore.AspNetCoreCommunicationListener.OpenAsync(CancellationToken cancellationToken)
       at Microsoft.ServiceFabric.Services.Runtime.StatelessServiceInstanceAdapter.OpenCommunicationListenersAsync(CancellationToken cancellationToken)

Configuration:
"Cosmos": {
"EndPoint": "https://xxxx-sqlapi.documents.azure.com:443",
"AuthKey": "xxx==",
"DatabaseName": "AccountService"
},
Extension method to hook up the Cosmos DB provider:
```c#

public static IServiceCollection AddCosmosSettings(this IServiceCollection services, IConfiguration configuration)
        {
            services.AddEntityFrameworkCosmos()
                   .AddDbContext<SystemDataContext>(options =>
                   {
                       options.UseCosmos(configuration["Cosmos:EndPoint"], configuration["Cosmos:AuthKey"], configuration["Cosmos:DatabaseName"]); ;
                   },
                       ServiceLifetime.Scoped  //Showing explicitly that the DbContext is shared across the HTTP request scope (graph of objects started in the HTTP request)
                   );

            return services;
        }

```
What I've tried:

• Analysing log analytics, shows no logging for these requests
• Removing the EnsureCreated and just directly insert data
• Create the collection manually (SystemDataContext)
• Create the database manually (AccountService)
• Removing networking firewall (Allow all networks) in azure

Further technical details

EF Core version: 2.2.0
Database Provider: Microsoft.EntityFrameworkCore.Cosmos 2.2.0-preview3-35497
Operating system: Azure Service Fabric - Windows Server Datacenter Core
IDE: VS 2017 15.9.3

[Mortana89]

So, apparently a POST request is happening to create the collection in Azure. This POST request is throwing a 400 BadRequest.
When checking the REST API specifications at https://docs.microsoft.com/en-us/rest/api/cosmos-db/create-a-collection, I notice the required header x-ms-offer-throughput or x-ms-offer-type is missing.

This looks as the reason why the request cannot be fullfilled...

[Mortana89]

Now, manually creating the collection, I see lot's of issues arise when trying to get this thing working.
Has the preview been tested against an Azure cosmos DB instance, or only a local emulator?

[AndriySvyryd]

@Mortana89 The preview is not ready to be used with an Azure cosmos instance

[Mortana89]

That's sad. Nowhere in the announcement it said it wouldn't be ready for the azure instance, at least not that I could see. Perhaps it should state so in the announcement?

Will there be one shipped in a <3.0 train?

[AndriySvyryd]

@Mortana89 We are replacing a lot of infrastructure in EF 3.0, so completing the provider before that would be a wasted effort.

[AndriySvyryd]

@divega Could we mention this in the announcement?

[Mortana89]

Small update, since the latest cosmos DB emulator release, the provider won't work on local either.
This is because the local emulator requires you to create a partition column when creating a collection (it used to be only required in case of shared-throughput collections, but now this is also required when creating a one-to-one (db-to-coll) mapping.

This is mainly because the provider has no understanding of the partition concept at all.

[AndriySvyryd]

@Mortana89 Thanks for the update, this too will be fixed in the 3.0 Cosmos provider.

[pavitrag123]

Hi,

Is there any update on this? We are trying to use cosmos Entity framework 2.2.4 and facing same bad request error while pushing data to cosmos DB. Any help would be highly appreciated.

[ajcvickers]

@pavitrag123 The Cosmos provider for 2.2 was never released as an RTM product and I would not expect it to continue to work. We are continuing to update the pre-release provider for 3.0.

[pavitrag123]

Hi,

I've tried using entity framework cosmos 3.0 in azure functions but it is throwing dependency injection error like below in function startup
Method not found: 'Microsoft.Extensions.DependencyInjection.IServiceCollection Microsoft.Azure.Functions.Extensions.DependencyInjection.IFunctionsHostBuilder.get_Services()'.

We want to use entity framework to connect to cosmos db in azure functions. Our project structure is

1. Azure function - startup that has dependency injection to Infrastructure project
2. CQRS project
3. Infrastructure project that contains cosmos db context initialization with EF core cosmos 3.0

Any suggestions would be of great help.

Thank you

[AndriySvyryd]

@pavitrag123 I'm not sure whether Azure Functions support .NET Core previews yet.

• Make sure that all ASP.NET NuGet packages referenced from your projects are targeting the same 3.0 preview version (preview5 is currently the latest that has Cosmos support).
• Try performing a self-contained deployment

[pavitrag123]

Hi @AndriySvyryd ,

Thank you for the update. Yeah I've tried using .NET core 3.0 references in the entire solution, I'm still facing same DI issue.

In a nutshell, can we conclude that using Entity framework core cosmos in azure functions is not possible as of now, can be available in future?

[pavitrag123]

Hi @AndriySvyryd , @ajcvickers : We, at our company InfoMagnus, fixed EFCore 3.0.0 dependency injection issue for Azure functions by injecting them directly in azure function constructor instead of using Microsoft.Azure.Functions.Extensions.DependencyInjection.

But while using EF core Cosmos 3.0.0 preview 6. we were facing 'Method not implemented' error for data retrieval from Cosmos DB. We had to revert it to 3.0.0 preview 5 version to fix this issue.

As we are planning to use EF core Cosmos for our product development, could you please share roadmap on when it will be released officially

[ajcvickers]

@pavitrag123 First, many thanks for trying preview 6. We really appreciate people trying the previews and filing issues on what they find.

If you haven't seen it already, there is some good information in the preview announcement post about the changes that are happening to LINQ queries for EF Core 3.0. Preview 6 is the first release containing these changes, which means we are both expecting things to be broken, but at the same time very grateful for everyone who tries the release and generated feedback.

At this time, we are still tentatively planning to release a non-preview of the Cosmos provider at the same time as .NET Core 3.0. However, this is contingent on a few things, such as the state of the available SDK, so it make be pushed later than that,