I'm suddenly getting the Bad Request (400) error when using the Azure Storage Emulator when trying to CreateIfNotExists. The Response on the Inner Exception says "The value for one of the HTTP headers is not in the correct format." All the tables exist, the data is in the tables, everything was working up until an update to my NuGet packages. Looking around SO it seems like a common cause is an update to Azure Storage Client Library (now at 5.0.0) that creates a mismatch. I updated the Azure SDK to 2.6 (since I have VS2012). This brings the Storage Emulator up to 4.0.0.0, but still no luck...same error. This is kind of a bad thing that suddenly an update to a package of a package of a package causes the whole thing to break and completely kills my rather large project. Any ideas?
In my case, the problem was with the Container Name, which has strict naming requirements.
Namely:
Only lowercase letters, numbers, and dash are allowed
Must be 3 to 63 characters
For more information, view Naming and Referencing Containers, Blobs, and Metadata on MSDN.
I don't know if this is a problem for anyone else, but this is what I have figured out...
Storage Emulator 4.1.0.0 is the one to use with Azure Storage Client Library 5.0.0
Storage Emulator 4.1.0.0 comes with Azure SDK 2.7.
Azure SDK 2.7 will not work with Visual Studio 2012.
Azure SDK 2.6 for VS2012 has Emulator 4.0.0.0. I don't know what Storage Client Library is compatible... I tried 4.3.0.0, 5.0.0.0, and 5.0.2, but had no luck
.
My "philosophical" issues with this whole thing are...
I can find no discernible connection between Storage Emulator
versions and Storage Client Library versions....The numbers don't
"match"; there are no errors, dependencies, or exceptions that tell
you the relationship; I can't find any look-up, cross-reference, or
table that describes the proper combination of libraries.
The "just use the latest version" theory doesn't work because in the
past they have released new versions of the Storage Client library
(3.0.0.0) w/o a working Emulator and now the "latest version" of each
is separately dependent on which SDK is available for your build
environment (VS2012 vs VS2015)
I understand the Storage Client Library isn't technically "dependent" on the emulator...you don't need the emulator to use Azure Storage. However, it would just be nice if some of these relationships were a little easier for a software oaf like me to figure out.
For me, I got this issue upon upgrading to the currently latest WindowsAzure.Storage version 9.3.1 package.
After hours of trying out various combinations of container names, and other stuff, the simplest solution was to roll back to the older and working version 8.6.0!
If I am not mistaken, you would need to downgrade client libraries to 4.x as well.
You see, each version of storage client library corresponds to a storage service REST API version and same goes for storage emulator as well. If you use storage emulator version 4.0, then you can't use storage client library 5 with that. You would need to use version 4.x with that.
If you want to use storage client library version 5, then you have 2 options:
Make use of latest version of storage emulator or
Do your development against cloud storage account.
Related
I m lost between all those packages I m trying to use them with .NET Core 3.1.
I m using Azure.Cosmos and Azure.Storage.Blob, but I m unsure if I need to use the Microsoft ones.
I will be running Asp.net Core on Kubernetes container and azure function also on Kubernetes
Cosmos Db
https://www.nuget.org/packages/Azure.Cosmos/4.0.0-preview3
https://www.nuget.org/packages/Microsoft.Azure.Cosmos/3.9.0-preview
Blob Storage
https://www.nuget.org/packages/Azure.Storage.Blobs/12.4.1
https://www.nuget.org/packages/Microsoft.Azure.Storage.Blob/11.1.4
For Cosmos, the recommended package is Microsoft.Azure.Cosmos (version 3.8) simply because version 4 is in preview and 3.8 is the latest version generally available at the time of providing this answer. Please see this link regarding ETA on the general availability of v4 of SDK: https://github.com/Azure/azure-cosmos-dotnet-v3/issues/1370.
For Storage, the recommended package is Azure.Storage.Blobs (version 12.4.1) as this is the latest one at the time of providing this answer.
The Microsoft ones are the older versions, for v12 blob storage you should use the non-Microsoft ones and for v11 use the Microsoft ones.
It would make sense for you to refer to the above links to determine which you need to use for your case but obviously if possible use the latest version. Be aware that last time I looked v12 was problematic to use with the storage emulator which is being replaced by the Azurite emulator, which was only partially complete!
I'm getting this message after upgrading to Azure Storage Emulator 4.6 and v8.0.0 of WindowsAzure.Storage.
I have spent two days trying to get this to work including reformatting and installing all dev tools on two machines. This has happened with THREE previous Microsoft releases, either the Azure SDK, or the emulator or some combination of the two is broken.
I managed to get things working with the previous version (again) with the following steps:
Uninstalled v4.6 of the Storage Emulator.
Deleted database files (mdf, ldf) under C:\Users\\
Downloaded and installed v4.5 Storage Emulator.
Reverted WindowsAzure.Storage to v7.2.1 (via NuGet)
Did a search for "8.0.0" in the solution to identify any remaining binding redirects that use v8.0.0 of WindowsAzure.Storage. Delete these if any are found.
This got me up and running again until there is a proper solution to use the latest version of the above libraries.
According to this article some support for older versions of Azure are going away:
https://azure.microsoft.com/en-us/blog/microsoft-azure-storage-service-version-removal/
We have a vs2008 application that is uploading files to Azure. {Using Azure 1.2 (for VS2008) - Microsoft.WindowsAzure.StorageClient v1.0.0 - Runtime v2.0.50727}.
We can't have this break since we are using this in production.
I need to know if there is a clear way to know if this is going to stop working.
I would really like to know if there is a way to upgrade the vs2008 project to use a compatible version of the StorageClient without migrating the project to vs2015.
Your version of the library should still be supported after the service removal. You can confirm which version of the service you are hitting by running requests through Fiddler and checking the x-ms-version. As you can see in the most recent post regarding our service deprecation, we are only removing version 2009-07-17 and older as of August 1, 2016.
I am a beginner in Azure and have come across a task to change the storage version.I basically found that the versions are obsolete and need to upgrade them as per http://blogs.msdn.com/b/windowsazurestorage/archive/2014/08/05/microsoft-azure-storage-service-version-removal.aspx
So, in one of the paragraphs its mentioned
"What to change
If you find any log entries which show that version to be removed is being used, you will need to find that component and either validate that it will continue to work (unversioned requests may continue to work as their implicit version will simply increase – see above), or take appropriate steps to change the version being used. Most commonly, one of the following two steps will be used:
1) Change the version specified in the request, typically by migrating to a later version of the libraries/tools. When possible, migrate to the latest version to get the most improvements and fixes.
2) Set the default service version to one of the supported versions now so that the behavior can be verified prior to removal. This only applies to anonymous requests with no explicit version. "
Question is, how to go about implementing point 1 and 2 ?
Thanks
Since your code is written in C# and uses Azure SDK your best bet is to upgrade it to a "new enough" SDK. It's unclear whether version 2.0 or 2.1 is the lowest required. So your route is the following:
First, check if you really have to do anything.
You check which Azure SDK your service uses. If it's 2.1 or higher you don't need to worry yet. If your're unsure - use Fiddler to validate the version headers as explained in the linked to post.
If you use Azure SDK 2.0 you'd better check the version headers as explained in the linked to post.
If you use Azure SDK prior to 2.0 you are surely affected and have to upgrade.
So if you found you do need to upgrade you'll have to download and install the newer SDK and then remove references to old SDK assemblies from your projects and add references to new SDK assemblies. Then you try to build your code and maybe fix a lot of calls because SDK interfaces have changed (that's what I see migrating from 1.8 to 2.4). Once it builds you test it works fine and then you remove the old SDK version to ensure the code builds without it present.
There was a breaking change between 2.1 and 2.2 - the latter only support Visual Studio 2012 and higher. There was another set of changes in Azure Diagnostics functioning between 2.4 and 2.5 which are so long to read that I chose to migrate to 2.4 instead of 2.5.
We have critical project partly deployed in azure that uses queues, blobs and table storage.
Now we using SDK 2.0 and thinking about moving to latest SDK 2.3 but it will cost us some resources especially for load testing with a new Azure SDK.
Is there a strong point to update SDK version like critical bug fix, performance issue or maybe useful new feature?
Sure, I read release notes but haven't found enough information about it.
In general we recommend that you always take the latest storage client from Nuget directly. If you look at Nuget you will see we are actually on 4.0.1 version of the .NET client vs the 2.0 version of the storage client that I believe is what shipped with SDK 2.0. As you can imagine there are a very large list of improvements between client 2.0 and 4.0. A couple of quick examples include: CORS Support, large improvements to Tables including JSON support and a highly optimized table service layer.
Here are some blogs with some more information:
http://blogs.msdn.com/b/windowsazurestorage/archive/2014/05/14/what-s-new-for-microsoft-azure-storage-at-teched-2014.aspx
http://blogs.msdn.com/b/windowsazurestorage/archive/2013/12/05/windows-azure-tables-introducing-json.aspx
There are also a lot of performance related improvements that have been made as well:
http://blogs.msdn.com/b/windowsazurestorage/archive/2013/09/07/announcing-storage-client-library-2-1-rtm.aspx
Hope this helps.
Jason
The latest Storage SDK version is now v12, which you can find in the Azure SDK repos:
Java
.NET
Python
JS/TS
You can also find migration guides in the repos which detail the migration benefits. The SDK has now split into separate ones like Storage Blob, Storage Queue, etc. The following are migration guides for Storage Blob. You can find the guides for the others in the repos as well:
Java
.NET
Finally, there are Changelogs for the new SDKs in the repos as well, which you can reference to see what fixes/changes are done. The following are Changelogs for Storage Blob. You can find the logs for Queue, Datalake, etc. in the repos as well:
Java
.NET
Python
JS/TS
It is recommended that you use the latest SDKs since those are the ones getting the new features as well as bug and critical fixes whereas the older libraries will only be getting bug and critical fixes. Read more about Azure SDK lifecycle and support policy