I can create a MobileServiceClient and GetTable<Model>() to InsertAsync, and see how my model gets inserted in the Easy Table table in Azure. But when I ReadAsync() from the table I get the following error:
Microsoft.WindowsAzure.MobileSerices.MobileServiceInvalidOperation: The server did not provide a response with the expected content.
This is when I mobileServiceClient.GetTable<Model>.ReadAsync()
What could be the problem?
This was when running from an MsTest project with no Microsoft.WindowsAzure.MobileServices.CurrentPlatform.Init(); call. The read worked when running the app
I had the same problem.
According to GitHub Issue:
As #elamalani pointed out above, we don't support .Net Core 2.1 in the SDK today. Unfortunately, we don't have a workaround today and like Ela said, the we don't have an ETA for a new release or other SDK to use for .Net Core 2.1 compatibility yet, so your only workaround is to stick with .Net Core 2.0 for now.
And I was also had SDK version 2.1
After changing SDK to version 2.0 all going to work fine. Please try to making the same, hope it will help you
Related
we have recently migrated to .NetCore 2.0 and so far I can say it went quite smoothly. However it seems that today we have stumbled upon the first hurdle. NotificationHubClient seems to require .NetFramework 4.5. We've tried installing NotificationHubClient nuget package but have been getting a series of exceptions, the latest was the missing library Systems.Diagnostics.Eventlog.
Is there a plan to release a fully .NetCore 2.0 compatible version of Azure NotificationHubClient? #azure-notificationhubs
We've been working on supporting .netcore for Notification Hubs, and this should be available in the next few weeks.
Thank you,
Karl
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.
My existing project, uses Azure .NET SDK 2.1. I wanted to upgrade the SDK to 2.4, so i dowloaded the latest from here for VS 2012. After successfull installation, when i opened up my solution, the cloud projects did not load. Thats ok, as they have been created using a lower version. So i removed them and created newer cloud projects.
But the thing which astonishes me is, there are many places in the worker role project where its throwing build error as it is not able to find out the assemblies and methods. Is there any easier way to upgrade to sdk 2.4 without making code changes. Which i think is a bad idea to make changes to the stable code, just for SDK upgrade.
When you open a project created using 2.1 SDK and try to open it using 2.4 SDK, you should see the project upgrade dialog which gives you the option to either download 2.1 SDK or convert existing project to target 2.4. Selecting the convert option should upgrade the project to 2.4. Any errors in this process will be reported in the project migration summary report.
If you are not seeing this dialog, then you might still have 2.1 sdk on your machine in addition to 2.4 sdk. In that case, you can go the Azure project properties. That will give you the option to upgrade your project to 2.4.
In regard to the build errors that you are getting for new projects, the error details will help in identifying the root cause.
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