Recently we have started upgrading our projects from ASP.NET 4.5 to ASP.NET Core and we are targeting the .NET Standard 1.6 framework. Most of the projects have been migrated but we are particularly facing issues with projects which have reference to Azure Storage SDK. Initially we were using SDK version 7.0.0, but since it was not supported in .NET Standard 1.6, we had to upgrade SDk to 7.2.1. But it seems that a lot of functions have been removed from the new version, for e.g. CloudTable.CreateQuery(). And also it seems that all the functions have been made async.
Is it an expected thing, or am I missing something here? Is there are a change or a upgrade document for all the changes that has been done? I could not find any document for all these changes.
Is it an expected thing, or am I missing something here?
Yes, this is an expected thing. We could check the CloudTable class in this article. And we could find CreateQuery function in that article. However we could not use CreateQuery function and we only could use async method. I think it is caused by the following, and this is a default behavior：
"frameworks": {
"netcoreapp1.0": {
"imports": [
"dotnet5.6",
"portable-net45+win8"
]
}
},
As we know that, we only could use Azure storage async method in portable library and win8. In asp.net core it imports "portable-net45+win8". So I think this is a reason. If you update your application to Asp.net core. I think you need to rewrite the Azure Storage code.
Related
We have an Azure Func app hosted in Linux Premium plan, private network, using only https, but the Swagger UI cannot display APIs like below:
The settings below are set based on the link below, but the error above still occurs.
{
"Values": {
"OpenApi__ForceHttps": "true",
"OpenApi__ForceHttp": "false",
"OpenApi__HostNames": "/api"
}
}
https://github.com/Azure/azure-functions-openapi-extension/blob/main/docs/openapi.md
Settings
.NET Core 3.x
Microsoft.Azure.WebJobs.Extensions.OpenApi 1.0
Refs:
https://github.com/Azure/azure-functions-openapi-extension/blob/main/docs/openapi-core.md
https://github.com/Azure/Azure-Functions/issues/1933
https://github.com/Azure/azure-functions-openapi-extension/issues/352
I faced a similar issue recently caused by a new package reference added to my project: my API operations list suddently became empty, without any error when the swagger (or open API 3.0) file was generated.
The package causing this issue is Microsoft.Azure.WebJobs, with version >= 3.0.32. (issue with 3.0.32 and 3.0.33 which is the current latest version).
Note: I did not use this package directly as it is already a dependency used by other packages of my project, but it was upgraded to a version >= 3.0.32 when I referenced Microsoft.Azure.WebJobs.Extensions.Storage.Blobs in version '5.0.1', see dependencies below:
The workaround I used in my case was to use version 5.0.0 (instead of 5.0.1) of Microsoft.Azure.WebJobs.Extensions.Storage.Blobs, which needs Microsoft.Azure.WebJobs in version >= 3.0.30 only
We have a function deployed to azure running the v2 runtime. If I go to the function in the portal to try to upgrade it to v3, I see this message "Cannot upgrade with existing functions: 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."
However, I was able to change the function in Visual Studio and deploy, using a simple test deploy of right-click publish, and the publishing process upgraded the deployed function to runtime v3.
Are there any gotchas we may run into using this approach? Is it better practice to create new azure function resources to deploy to a clean v3 azure function?
Thanks
Apparently no one else has this question or the answer is obvious. In any case, here's Microsoft's recommendation from their support personnel (grammar/language translation is Microsoft's):
Based on the official documentation changing the version can be made by changing the App Setting "FUNCTIONS_EXTENSION_VERSION" value form ~2 to ~3 however this can cause some problems if there are any dependencies unique to version 2 of the runtime, you can read more about this in the following link
https://learn.microsoft.com/en-us/azure/azure-functions/functions-versions#migrating-from-2x-to-3x
Now based on my experience the safest an easiest way to archive [achieve] this is to deploy the code into a Function app that was created targeting the version 3 of the runtime this is to assure [ensure] that it will only have the dependencies form [from] version 3 and not having anything extra from 2 left after changing the version directly from the portal
The idea with this is to avoid having conflicts from between assets form version 2 or missing assets from version 3
Suppose you are using c# function, if yes, the major update about v2 to v3 is the .net core version. So mostly if your code could work with the update that means your dependencies are compatible with .net core3, so mostly it won't crash.
And there is an official doc about migrating from 2.x to 3.x.
And about deploying, if the runtime is different when you deploy it will prompt to update the portal runtime, so it won't affect the function running.
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 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/
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/