Azure-cosmos-dotnet-v3: Namespace clash with Microsoft.Azure.Cosmos.Table

[Miggleness]

Describe the bug
I've a project that references both Microsoft.Azure.Cosmos 3.0.0.9-preview and StreamStone 2.3.0 which in turn has a reference to Microsoft.Azure.Cosmos.Table 1.0.0.0.

One error I encountered is as follows The type 'IndexingMode' exists in both 'Microsoft.Azure.Cosmos.Direct, Version=3.0.0.9, Culture=neutral, PublicKeyToken=31bf3856ad364e35' and 'Microsoft.Azure.Cosmos.Table, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' (CS0433) [deleteme]

This also begs the question, what's the direction for CosmosDb .NET SDK going forward? Will it be consolidated into Microsoft.Azure.Cosmos or will it be broken down into multiple parts? (core/direct?, document/sql, mongo api, cassandra api, table api, gremlin api)?

To Reproduce

1. dotnet new xunit
2. dotnet add package Microsoft.Azure.Cosmos -v 3.0.0.9-preview
3. dotnet add package StreamStone -v 2.3.0
4. use code below

using System;
using Xunit;
using Microsoft.Azure.Cosmos;

namespace deleteme
{
    public class UnitTest1
    {
        [Fact]
        public void Test1()
        {
            var x = new IndexingPolicy
            {
                IncludedPaths = { new IncludedPath{Path=""}},
                IndexingMode = Microsoft.Azure.Cosmos.IndexingMode.Lazy // uh, oh
            };
        }
    }
}

Environment summary
SDK Version: 2.2.505
MacOS Mojave

[donghexu]

Hi @Miggleness, thanks for reporting this issue. The namespace conflict on IndexingMode is a known issue while depending on Microsoft.Azure.Cosmos and Microsoft.Azure.Cosmos.Table. We will fix it in future Table sdk. At the same time, you can use assembly alias to unblock you. Here is the link of it: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/extern-alias

Thanks,

[Miggleness]

Thanks. That's indeed my workaround to get around the conflict right away.

So, it seems that there will continue to be separate projects/packages for each database model. Maybe the naming can be improved a bit. Microsoft.Azure.Cosmos sounds like the core library that all else depends on when it's not.

[donghexu]

Hi @Miggleness, Great to hear you are unblocked and thanks for the feedback. We will close this issue for now.

[dlmelendez]

Adding this link to help anyone else with this same problem, since Nuget doesn't support extern aliases https://github.com/NuGet/Home/issues/4989

[FrankGagnon]

@donghexu Hi, I'm not sure why this issue is closed considering that the SDK is now GA and this problem is still there. It makes it practically impossible to use the Cosmos SDK alongside the Table Storage SDK in the same project.

Could this be reopened and fixed please?

Thanks

[dlmelendez]

@shanselman, @donghexu This bug is causing some real friction for switching to this version of the SDKs. Sharing identical namespaces/objects across multiple packages seems to be a major oversight. In this current state, I am regretting implementing the latest versions of the Cosmos libraries (this one and the Cosmos.Table) since I use both the CosmosSQL and Azure Table Storage in the same data access libraries. I would not recommend this library in its current state to clients or other partners.

One could argue there is a workaround to using the extern alias. Sure, but then Nuget doesn't support the extern alias either and there is a yet another workaround to implement that NuGet/Home#4989 .

It is incredible to me that your workaround you are suggesting for libraries that just went GA introduce technical debt immediately into any new work using these SDKs. Can we please get this reopened and fixed?

[donghexu]

Hi @dlmelendez, @FrankGagnon. I truly understand your confusion with this issue. The Table SDK GA version takes the dependency on DocumentDB sdk which doesn't have the same namespace for IndexingMode. We are developing a new version that takes dependency on CosmosClient, which will eliminate the problem here. It is coming.

The assembly alias is also the workaround.

Thanks,

[donghexu]

Hi All,

We just released Table SDK 2.0.0-preview: https://www.nuget.org/packages/Microsoft.Azure.Cosmos.Table/2.0.0-preview. It takes the dependency on CosmosClient and resolves the naming problem. Please check it out.

Thanks!

[kieronlanning]

@donghexu Are there any updates planned for that library to bring it out of Preview?

[donghexu]

@PaulCheng

[PaulCheng]

@kieronlanning We do have plan for the next major release of Table SDK which is to deprecate the dependency on the underlying cosmosdb sdk by supporting REST mode only. We don't have date committed yet since that requires server side change to use hybrid binary row.

[kieronlanning]

@PaulCheng Does that mean a new emulator, and all storage accounts will need manual updating to support apps using this new SDK...?

[PaulCheng]

There is no need to update existing storage account or cosmosdb table account. Emulator will continue working as well.

[blueelvis]

@PaulCheng @donghexu - When will this be out of preview? It has been an year since this is in preview and yet the other versions have been updated.

[kieronlanning]

@blueelvis Apparently there is a build of a _new_ package (Azure.Data.Tables?) due for release in September that will supersede this package for both Cosmos and Storage Table APIs.

[blueelvis]

@kieronlanning - So another package? First we had one package, then it got separated, then again it is being combined. :(

Anyways, thanks for the update, I will keep an eye on the new release. Any slated release date?

[kieronlanning]

@blueelvis Sorry, no idea other than next month apparently.