What's the difference between these two assemblies and when should I use each? I find that there are class name collisions between them so I imagine that I should only use one.
Example
Microsoft.WindowsAzure.Storage has Microsoft.WindowsAzure.Storage.Table.CloudTableClient
Microsoft.WindowsAzure.StorageClient has Microsoft.WindowsAzure.StorageClient.CloudTableClient
This seems very confusing. I can't imagine that Microsoft intends these to both be used in the same project.
Microsoft.WindowsAzure.Storage is version 2.0 of storage client library while Microsoft.WindowsAzure.StorageClient is the older version. There have been many changes in version 2.0 of the library (some of them are breaking). If you're starting new, I would actually recommend using 2.0 of the library as I found it more intuitive and easy to use than the older version. If you have an application which makes use of 1.7 version of the library, before you decide to upgrade, I would actually recommend reading the following blog posts by Windows Azure Storage Team:
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/10/29/introducing-windows-azure-storage-client-library-2-0-for-net-and-windows-runtime.aspx
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/10/29/windows-azure-storage-client-library-2-0-breaking-changes-amp-migration-guide.aspx
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/06/windows-azure-storage-client-library-2-0-tables-deep-dive.aspx
However please note that there're still some components that your application might be using which has a dependency on storage client library 1.7. Windows Azure Diagnostics is one of them. So for some time you will need to use both versions. Good thing is that you can use both versions simultaneously in your project.
Hope this helps.
EDIT:
I also wrote a few blog posts about migrating code from storage client library 1.7 to 2.0 where I covered some basic scenarios. You can read those posts here:
Migrating blob storage code: http://gauravmantri.com/2012/11/28/storage-client-library-2-0-migrating-blob-storage-code/
Migrating queue code: http://gauravmantri.com/2012/11/24/storage-client-library-2-0-migrating-queue-storage-code/
Migrating table storage code: http://gauravmantri.com/2012/11/17/storage-client-library-2-0-migrating-table-storage-code/
Related
I've always found this very confusing:
There is a WindowsAzure.Storage NuGet package authored by Microsoft which allows you to work with, for example, blob storage (creating blobs, etc.).
There are also Microsoft.Azure.Storage.* packages which accomplish the same thing, also authored by Microsoft.
If your project happens to have dependencies on both, you can have naming conflicts e.g. (The type 'CloudStorageAccount' exists in both 'Microsoft.Azure.Storage.Common, ... and 'Microsoft.WindowsAzure.Storage, ...).
Here are links to the two alternatives:
https://learn.microsoft.com/en-us/dotnet/api/overview/azure/storage?view=azure-dotnet
https://github.com/Azure/azure-storage-net/blob/master/README.md
What is the difference and when would I be motivated to use one over the other?
WindowsAzure.Storage(latest is v9.3.2) is the legacy Storage SDK we always use and Microsoft.Azure.Storage.*(latest v9.4.0) is its new release, nuget available about one year.
Check the changelog of Storage .NET SDK. List part of those important differences/changes.
Microsoft.Azure.Storage splits libraries to three parts, Blob, Queue and File, which means we can install separate package instead of the full edition.
Microsoft.Azure.Storage doesn't support Table API, it is transferred to Microsoft.Azure.Cosmos.Table.
Microsoft.Azure.Storage added NetStandard2.0 target support since 9.4.0-preview, which supports synchronous methods wrapped over the asynchronous APIs. WindowsAzure.Storage on NetStandard only has asynchronous APIs.
Microsoft.Azure.Storage v9.4 package moves back to use Microsoft.WindowsAzure.Storage namespace temporarily to ease the transition for existing libraries.
Just make choices based on our requirement.
There are now three levels:
WindowsAzure.Storage - up to v9.3.3 - don't use this anymore.
Microsoft.Azure.Storage - v9.4.0 to v11.1.7 - older
Azure.Storage - v12.x - use this library.
All the Azure libraries are being consolidated into the Azure namespace, so the newer libraries all start with Azure (not Microsoft.Azure or WindowsAzure) and you should use those when available.
I'm trying to wrap my head around how we're supposed to build Azure functions.
I love the idea of building serverless, compact, single-function apps that respond to events.
Here are the problems I'm running into:
I have nice class libraries built in .NET Standard 2 that handle all my "backend needs" namely handling CRUD ops with Cosmos Db, Azure Table Storage, Azure SQL, Redis, Azure Storage. No matter what I did, I couldn't integrate these class libraries into an Azure Functions project. More details below.
Also, getting dependency injection in Azure Functions project has proven to be quite a task -- especially with my class libraries mentioned above.
At this point, the only option I'm seeing is to "copy and paste" code into a new Azure Functions project and use it without any DI.
This seems to go against "best practices". So what's the solution other than either to create monolithic code or wait till Azure Functions support .NET Core and DI.
I thought I could use my .NET Standard class libraries from a regular Azure Functions project targeting .NET Framework. After all, the idea of .NET Standard is to "standardize" things. I opened a couple of posts here on SO. I'm providing the links so that you can see the issues I've run into:
Using .NET Core 2.0 Libraries in WebJob Targeting .NET Framework 4.7
No parameterless constructor error in WebJobs with .NET Core and Ninject
P.S. My previous posts are referring to WebJobs. That was plan B approach because WebJobs seem half a step ahead of Azure Functions when it comes to supporting things like .NET Core and DI. Ultimately, I'd like to build a few Azure Functions that can use my class libraries built in .NET Standard 2.
Also, my previous posts mention that my class libraries target .NET Core 2.0. Since then I converted them to .NET Standard 2 which didn't really take much at all. I did this so that I truly conform to .NET Standard 2.
One issue is that Visual Studio has an outdated version of the Functions Core tools. Until this is resolved, you can work around in the following way:
Install the latest via npm by running npm install -g azure-functions-core-tools
In your Function App in VS, go to the Properties
Go to Debug, and click New... under Profile
Name the new Profile something like FunctionsNpm
Set the executable to (replace [YourUserName]): C:\Users\[YourUserName]\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.exe
Set the arguments to host start
Set the working directory to $(TargetDir)
In toolbar, look for the green triangle icon to change your current Profile to the one you just created:
Now when you run from VS, you'll be using the npm tools instead of the older one that come with the VS package.
.NET Standard 2 support is on its way, see this github issue.
I'm using the official nuget package of Windows Azure Storage Client Library to retrieve items of my Azure tables.
Recently I updated the package from version 2.0.2.0 to 2.0.5.0 and my app stopped working because the results returned by my storage query are different with the new version.
I'm looking for the library changelog in order to understand how to fix the issue.
Do you know where can I find it ?
The link provided on the nuget page seems to be outdated (it's a changelog between 1.x and 2.x, not between 2.0.2 and 2.0.5 !). Also, the Windows Azure Storage team's blog is not updated.
Please refer to the changelog.txt that is always updated with the respective source code changes.
The changelog is always up to date at https://github.com/Azure/azure-storage-net/blob/master/changelog.txt
I cant find a method since I upgraded the Azure storage dlls.
The static method I cant find is: CloudTableClient.CreateTablesFromModel
The old class:
http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.cloudtableclient_methods.aspx
This is the new class:
http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storage.table.cloudtableclient_methods.aspx
I did some searching but couldn't find a word about this being replaced or deleted.
Does anybody have an idea?
Storage client library 2.0 is quite different from the previous version and a number of methods have been removed in the newer version. This method is one of them. If you look under the remarks section on this page: http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.cloudtableclient.createtablesfrommodel.aspx, it is recommended that you not use this method.
Since these 2 versions are quite different, it is recommended that you read up the following blog posts from the storage team before upgrading your code to use the latest version:
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/10/29/introducing-windows-azure-storage-client-library-2-0-for-net-and-windows-runtime.aspx
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/10/29/windows-azure-storage-client-library-2-0-breaking-changes-amp-migration-guide.aspx
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/06/windows-azure-storage-client-library-2-0-tables-deep-dive.aspx
I also wrote a blog post about migrating code from storage client library 1.7 to 2.0 which you can read here: http://gauravmantri.com/2012/11/17/storage-client-library-2-0-migrating-table-storage-code/
The Azure Storage client was recently updated to version 2.0, and I haven't found any API that returns Task.
How can I use TPL with Table Storage? .. Blob or Queue?
For your reference the new API has an example here for Table Storage.
Looking through some of the source under https://github.com/WindowsAzure/azure-sdk-for-net/ it appears that they haven't had a chance to add the Task versions yet (seems odd since it specifically mentions targeting .NET 4), but the operations appear to have the Begin* and End* versions available, so you could use the FromAsync method to wrap each pair in a task for easier consumption.
Does seem like an odd omission AFAICT, though.