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.
Related
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 been using Azure Function runtime version as "beta" and Microsoft.Azure.WebJobs.Extensions.EventHubs - version 3.0.0-beta5 package to bind with Eventhubs.
Things broke down completely after azure portal started prompting for Upgrading to version 2 for Azure Functions. With or without changing the runtime to ~2 (or any specific 2.x.x.x version) it is failing.
Can someone make it clear on what needs to change if we want to target version 2? I tried to upgrade Microsoft.NET.Sdk.Functions to latest 1.0.19 and Microsoft.Azure.WebJobs.Extensions.EventHubs to latest 3.0.0-beta8. All I get is assembly loader errors!
Please help!
You can find the description of this breaking change and recommended steps in this issue.
When I try to set Azure Functions to stable versions 1.0.14 or 1.0.13 locally & in the Portal - I tend to receive a 500 error when trying to GET an endpoint. Through some debugging, I managed to correct this by changing the version to beta. No errors.
Has anyone else seen this issue? Is there any way around this without actually having to recreate the function using the desired version?
Thank you!
You probably mistake Azuer Function SDK version for Azure Function Runtime version.
try to set Azure Functions to stable versions 1.0.14 or 1.0.13 locally & in the Portal
1.0.14 or 1.0.13 you mentioned is SDK version(latest is 1.0.19 right now), which is used to build our function project. Of course we can't set SDK version on portal as build is done before we publish pre-compiled code to Azure. If we develop in browser, the build process and SDK version(the latest) is under the control of Azure.
I managed to correct this by changing the version to beta. No errors.
You may have created a v2 function locally, hence function depends on beta runtime. And you specify a wrong version of 1.x like 1.0.14, so 1.0.11959 is used. We can see 500 error is caused by mismatched runtime and you have corrected it. If you have planned to work with v2 function(.net standard), nothing malfunctions so far.
And some more info about function runtime version.
Function Runtime version
There are two major versions: 1.x for .Net Framework and 2.x for .Net Standard.
Syntax
Major version :~1 for 1.x , ~2 for 2.x. With this format, function app on Azure is automatically updated to new minor versions of the runtime when they become available.
Minor version 1.x:1.0.11959; 2.x: 2.0.11961-alpha, 2.0.12050-alpha. (All versions available right now). Function app on Azure is kept on that version until we explicitly change it.
Where to find
Runtime version in Function app settings.
FUNCTIONS_EXTENSION_VERSION in Application settings.
Configuration
Two scenarios we need to change runtime.
Major version change. ~1 to ~2 or reverse.
We may see prompt below if there are functions in the app.
Major version upgrades can introduce breaking changes to languages and bindings. When upgrading major versions of the runtime, consider creating a new function app and migrate your functions to this new app.
In an empty function app(delete existing functions or create new app), change runtime in Function app settings.
We can directly set FUNCTIONS_EXTENSION_VERSION in Application settings if published project depends on another runtime.
Minor version pinned to avoid breaking changes(probably the last time to use as 2.x is planned to be GA by this fall).
See breaking changes in 2.0.12050-alpha(beta), we can pin FUNCTIONS_EXTENSION_VERSION to 2.0.11961-alpha and follow steps to work with changes and move to beta.
Find more breaking changes to fix if our 2.x function runtime is pinned to some older version, which have all been removed on Azure.
Wrong version handler
If we specify a wrong version of 1.x like 1.0.14, Azure will leverage latest minor version instead. It is same with 2.x.
For local dev
Commonly speaking, local dev doesn't need runtime configuration because we choose Cli first(using tools like npm or VS does in background), we are clear about the major version at least.
Some local places to find function runtime version.
VS, New Function project v1 or v2.
VS/VSCode c# function, in functionappname.csproj, see <AzureFunctionsVersion>v2</AzureFunctionsVersion>.
VSCode, functionapp/.vscode/setting.json, see "azureFunctions.projectRuntime": "~2"
Function core tools(Cli), run func, we may see Function Runtime Version:2.0.12050.0
Start a function app in VS/VSCode/Cli, besides 4, we can also see Cli output Starting Host (HostId=xx, InstanceId=xx, Version=2.0.12050.0, ..)
Very useful information, thank you Jerry! I managed to solve my issue by recreating the Azure function without using .NET Standard. Azure lets you know that changing certain settings may lead to the function not working properly. After recreating with the proper runtime set in both portal and project, it worked.
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.
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.