各种 NuGet 包中的 Azure CloudStorageAccount 命名空间冲突，以及迁移到更新的 Azure SDK

Question

我知道我参加这个聚会可能有点晚了，但仍然感到困惑。

多年来，我们一直在使用 NuGet 包WindowsAzure.Storage来处理 Blob、表和队列，在 .Net 的上下文中并使用 .Net Azure SDK。

在我们开发的许多 Azure Web 应用程序的最底层共享代码中，我们有一种缓存模式，CloudStorageAccount用于获取这些存储实体所需的各种客户端。我们使用以下 C# 代码获取该存储帐户：

    CloudStorageAccount storageAccount = CloudStorageAccount.Parse(connectionString);

这“storageAccount”缓存，我们用它在整个应用可以访问各种存储客户端，即CloudBlobClient，CloudTableClient和CloudQueueClient，就像这样：

    CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
    CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();
    CloudTableClient tableClient = storageAccount.CreateCloudTableClient();

这些客户端也被缓存，但这可能与这个问题无关。

Microsoft 似乎鼓励（尽管可能没有任何弃用警告？）迁移到较新的 SDK，这些 SDK 位于Microsoft.Azure.Storage.Xxxxxx和/或中的 NuGet 包中Azure.Storage.Xxxxxxx，但这些 NuGet 包层次结构不支持表，仅支持 Blob 和队列（和文件，我目前没有使用）。

相反，表似乎处于不同的层次结构中，即Microsoft.Azure.Cosmos.Table.

但是CloudStorageAccount在 in 中Microsoft.Azure.Cosmos.Table声明的一个类型和在Microsoft.Azure.Storage.Common.

然后甚至更新的Azure.Storage.Xxxxxxxx库似乎对表没有任何支持。

当然，我可以为类型设置别名或始终完全指定它们，但这意味着我将不得不重写我的缓存代码（不是世界末日）但是整个练习的一部分让我怀疑我是否遗漏了一些这些各种不同存储实体的性质中的关键重要概念。我也很犹豫，因为我似乎可以打破一些第三方依赖。所以整个问题看起来真的很棘手。

我非常感谢任何概念上的理解、指向综合学习文档的指针、代码示例、建议或解释。表对我们来说很关键，但我怀疑我们是否会很快迁移到新的 Cosmos DB 表。

Answer 1

这可能不是您正在寻找的答案，但我们最近一直在查看此软件包更新 - 我们可能是这里的幸运儿，但表面上新软件包Microsoft.Azure.Cosmos.Table具有与旧软件包相同的方法/WindowsAzure.Storage.Table签名有（而且我坚信他们实际上只是按原样分叉了所有代码）。我们所要做的就是卸载旧的 nuget 软件包，安装新的软件包，然后将所有解决方案中的行替换为using Microsoft.WindowsAzure.Storage.Table，using Microsoft.Azure.Cosmos.Table它就像一个魅力一样。

您根本不必使用 Cosmos DB，它只是在包的名称中，但它仍然可以完美地工作/连接到常规存储帐户。

可以在这里找到微软决定迁移的一些（尽管非常模糊）信息：https ://azure.microsoft.com/en-us/blog/previewing-azure-sdks-following-new-azure-sdk-api-standards /。