Where is CloudDrive in Azure SDK 1.8 (October 2012)?
In Azure SDK 1.8 the StorageClient namespace no longer exists. This is the namespace that contained CloudDrive.
I know that the StorageClient namespace was renamed to Storage in Azure SDK 1.8, but I can not find the CloudDrive class in this namespace.
Where did it go?
Cloud Drive access wasn't updated in the 1.8 SDK. See the discussion here: http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/01/known-issues-for-windows-azure-storage-client-library-2-0-for-net-and-windows-runtime.aspx
A quote from that link:
clouddrive has not been updated to use the latest version yet and hence it does not support the 2.0 client library (which uses 2012-02-12 REST version). However, you can use both libraries together and continue using the older client lib for use with clouddrive (and diagnostics) but use the newer 2.0 lib for everything else in your app.
From personal experience, if you do use Azure libraries from different SDKs side by side in the same project, watch out for version conflicts, especially with the Microsoft.WindowsAzure.Configuration dll - and watch out for NuGet helpfully upgrading your packages, whether you want it to or not.
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!
started getting this error after I updated Microsoft.Azure.KeyVault.KeyVaultClient from version 2.05 to 3.05.
Method 'get_SerializationSettings' in type 'Microsoft.Azure.KeyVault.KeyVaultClient' from assembly 'Microsoft.Azure.KeyVault, Version=3.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' does not have an implementation
Any idea how I can fix it ?
Try to confirm your Microsoft.Azure.KeyVault dependencies version.
At the time 3.0.5 was built, we depended on Newtonsoft.Json 10.0.3. Do you have that or newer installed into your project? If you do, another possibility is something another team hit: a version of Json .NET was in the GAC but specific for net35, which is lacking some types that were necessary. If you can, check that you're not picking up a GAC's copy of Json .NET.
For more details, you could refer to this issue.
I was facing this problem too, it seems that Azure Functions v1 (this old version is required as it's some legacy .NET Framework code) is locked to Newtonsoft 9.0, whereas Microsoft.Azure.KeyVault requires Newtonsoft 10+
This is not reconcilable, so it seems to be impossible to use the Key Vault SDK inside an Azure Function V1.
However, the Azure SDK v4 is now out, and doesn't have a Newtonsoft dependency. So a workaround is to use the v4 SDK instead, which doesn't give this error does appear to work inside an Azure Function.
As a developer on the Key Vault SDK, I recommend upgrading to Azure.Security.KeyVault.*. Not only do they not take a dependency on Newtonsoft.Json, they have better logging, faster performance, less memory overhead, and the pipeline is more extensible. Microsoft.Azure.KeyVault* will only get critical fixes, and some new features for Key Vault are already in preview so moving to v4 (same as Azure.Security.KeyVault.*) would be ideal.
Try to downgrade Microsoft.Azure.KeyVault down to version 3.0.3
Dependency for that version: Newtonsoft.Json (>= 6.0.8) for .NetFramework 4.5.2
Azure Functions V1 use Microsoft.NET.Sdk.Functions-1.0.24
Dependency for that version: Newtonsoft.Json (= 9.0.1) for .NetFramework 4.6
So it is possible to use Azure KeyVault stuff for Azure Functions V1.
It is needed to make a little bit tunning used versions of additional packages.
Maybe it is not the best way, but it is the simplest way. And it works!
Is the Azure storage v10 SDK and its dependencies compatible with Java 11?
Didn’t see a reference to Java 11 in the following:
https://github.com/Azure/azure-storage-java
Did not find reference or statement in this document as same as you. I downloaded jar package for Blob Storage SDK v10 from the maven repo and decompress it. I check the Build-Jdk property is 1.8.0_181 in the MANIFEST.MF file.
Based on the Oracle official document : Security Baselines JDK 11. The baseline version for V8 is 1.8.0_191-b12 which is upper than above version.
However, I tested Blob Storage SDK v10 code locally with V11 JDK and it works fine.I suggest you taking a shot on your side. Also,you could commit feedback to azure storage team.
You will need javafx, which is not provided by java 11.The dependency is used for instance in TransferManager - not that it really uses functionality of javafx, it is just introduced by an apparently lazy programmer..
I'm migrating from VS2015 to VS2017, and updating a repo's solutions to be able to be compatible with VS2017. In the process, I'm also updating the Azure SDK version from 2.7 to 3.0.
I'm setting up a fresh dev environment, and installed Azure SDK 3.0 via VS2017's Azure development workload.
When I opened the solution file in the repo, I got one notice per cloud service project that its Microsoft Azure Tools version was getting upgraded from 2.7 to 2.9...
...and the ProductVersion tag in the corresponding .csproj files was updated from 2.7 to 2.9.
Questions:
Why wasn't this updated to 3.0?
Is there anyway for me to update it
to 3.0 without manually editing the csproj file? I don't see an
option to do so in Properties when I right click the cloud service
projects in Solution Explorer.
Is there some reason I shouldn't be
doing this?
"Microsoft Azure Tools - v2.9" mentioned in your screenshot is just a little misleading.
Underlying reason is that Microsoft hasn't really changed the version number of most components as part of 3.0 SDK release. Even the binaries get installed in the same folder as 2.9.
Good news is that you don't need to do anything special apart from converting the project to target latest version, which you're already getting prompted for.
So once you do convert your project as per the prompt, you're essentially working with SDK 3.0, even though version string says v2.9, because as the links explain, most of the components haven't changed major version number as part of SDK 3.0 version (when comparing with 2.9)
Here are some of the links which talk about this -
Azure SDK for .NET 3.0 Release Summary
No breaking changes to the Azure SDK 3.0 have been introduced in this
release. There is also no upgrade process needed to leverage this SDK
with existing Cloud Service projects. To allow use of the Azure SDK
3.0 without requiring an upgrade process, Azure SDK 3.0 installs to the same directories as Azure SDK 2.9. Most the components did not
change the major version from 2.9 but instead just updated the build
number.
Visual Studio 2017 latest installer does not install Azure SDK 3.0
In this link look at the response from Devin Breshears - MSFT
Azure 3.0 SDK Install Weirdness
An independent blog talking about the same issue.
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