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
Related
I'm trying to use Magick.NET library to do image processing on Azure Functions.
I have tried the same code in a Console App (.NET Core 3.1) which works without any issues. However when running the same code in an Azure Functions Project, I get the following error.
Code:
var image = new MagickImage(File.ReadAllBytes(#"<My Image Path>"));
Exception:
System.TypeInitializationException: 'The type initializer for 'NativeMagickSettings' threw an exception.'
StackTrace:
at ImageMagick.MagickSettings.NativeMagickSettings..ctor()
at ImageMagick.MagickSettings..ctor()
at ImageMagick.MagickImage..ctor()
at ImageMagick.MagickImage..ctor(Byte[] data)
at FunctionApp2.Function1.Run(TimerInfo myTimer, ILogger log) <-- My Code
Inner Exception:
Unable to load DLL 'Magick.Native-Q8-x64.dll' or one of its dependencies: The specified module could not be found. (0x8007007E)
Inner Exception StackTrace
at ImageMagick.Environment.NativeMethods.X64.Environment_Initialize()
at ImageMagick.Environment.NativeEnvironment.Initialize()
at ImageMagick.Environment.Initialize()
at ImageMagick.MagickSettings.NativeMagickSettings..cctor()
I believe this is due to the way Azure Functions package is organized and the path Magick.NET is looking for its native binary to load. I can confirm that the native binary is written at \bin\Debug\netcoreapp3.1\runtimes\<platform>\native when the Function app is built.
I have traced the apps using ProcessMonitor for each app and can see Function app looks in the wrong location.
It looks in
\bin\Debug\netcoreapp3.1\ bin\ runtimes\[platform]\native
instead of
\bin\Debug\netcoreapp3.1\runtimes\[platform]\native
(Below traces are filtered to only show path contains Magick.Native and process name filtered to the Console app exe and func.exe)
Console App Trace
Function App Trace
I have also tried setting MagickAnyCPU.CacheDirectory to Directory.GetCurrentDirectory() but it hasn't helped.
UPDATE:
After building, if I copy \netcoreapp3.1\runtimes folder to \bin this fixes the problem, but I current don't want to rely on that trick if there's a proper workaround.
UPDATE 2:
This issue appears to happen only when using
<TargetFramework>netcoreapp3.1</TargetFramework>
and Microsoft.NET.Sdk.Functions version 3.0.x
It does not appear when using older versions. I have successfully used
<TargetFramework>netcoreapp2.1</TargetFramework>
and Microsoft.NET.Sdk.Functions version 1.0.x
without this issue.
So, is there a workaround to get ImageMagick to load native lib from the right place?
Potential Workaround is to get msbuild to copy the runtimes folder after the build completes.
Add following to csproj
<Target Name="PostBuild" AfterTargets="PostBuildEvent">
<Exec Command="xcopy /Y /E $(OutDir)runtimes\ $(OutDir)bin\runtimes\" />
</Target>
or right click project > properties > Build Events and paste the above command to post build event command line
This will copy all of the runtimes binaries, not just the one we want, increasing the size of final build.
UPDATE:
This may be a bug in Microsoft.NET.Sdk.Functions version 3.0.8.
These issues in the github repo are tracking this.
Version 3.0.8 places the runtimes folder incorrectly
Microsoft.Data.SqlClient is not supported on this platform with Microsoft.NET.Sdk.Functions 3.0.8
This seems to only happen when using Microsoft.NET.Sdk.Functions version 3.0.8 which seems to have only just appeared in nuget on Friday. I will instead downgrade to 3.0.7.
Alternatively if you don't want to downgrade,
You could use MagickNET.SetNativeLibraryDirectory as a work around
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.
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.
I'm trying to upload a blob to azure using a shared access signature. I have the token and added the nuget package WindowsAzure.Storage to my project. I've tried both version 7.0.0 and 7.0.1-preview.
For some reason I'm unable to resolve the reference when creating an instance of CloudBlobContainer. Also I've tried to just type the using statement but no luck. All azure documentation points to a version 4.4.0-preview, is this the one I should be using?
azure doc ref https://azure.microsoft.com/da-dk/documentation/articles/storage-xamarin-blob-storage/
Best regards
I would just guess that the docs are outdated with the 4.4.0-preview link instead of a link to the NuGet package:
https://www.nuget.org/packages/WindowsAzure.Storage/
CloudBlobContainer seems to be within the Microsoft.WindowsAzure.Storage.Blob namespace.
I would check to ensure that you actually installed the NuGet package as it may have failed silently with other projects.
EX: http://screencast.com/t/FLhztkeu
Changing the PCL profile worked for me. Bizarre.
After installing the NuGet package, you actually need to change the profile on your Xamarin project. You can do this by going to the shared project -> Options -> General – > C#
Change the Current Profile to PCL 4.5 – Profile111 (I have no idea
of what this does.)
You need to retarget your NuGet packages for this new profile now.
Right click on Packages within the shared project, and you’ll have 5
options here.
Retarget will be available. Click that. (Not shown here, as I’ve
already retargeted)
Rebuild your project
How I figured this out
I stumbled across this Xamarin forum post, where someone had the exact same issue. One user pointed us towards a bug report, where PCL references were not added automatically via NuGet package installation. They recommended retargeting, and it worked! Now I can include the using Microsoft.WindowsAzure.Storage.Blob; namespace.
I have a blog post with more info on this.
I'm trying to read a message from an Azure ServiceBus queue using an Azure WebJob but it's throwing and exception:
Unhandled Exception: System.InvalidOperationException: Found 2 DNS claims in authorization context.
I've set the correct connection strings named "AzureWebJobsServiceBus", "AzureWebJobsDashboard" and "AzureWebJobsStorage"
The WebJob Program code has been updated to use JobHostConfiguration:
class Program
{
static void Main()
{
var config = new JobHostConfiguration();
config.UseServiceBus();
var host = new JobHost(config);
host.RunAndBlock();
}
}
And the actual Job method
public class Functions
{
public async static Task ServiceBusResizeRequest(
[ServiceBusTrigger("blah")] string message,
TextWriter log
)
{
await log.WriteLineAsync("got message " + message);
}
}
I can successfully create and write to the queue via a separate console application.
But when I run the webjob application, it throws that exception.
Any ideas?
EDIT: Using .net 4.6.1
The answer marked as solution, is not the solution, it is a botched job.
The solution to use it in .Net Framework 4.6.1 is to add in the rutime block in App.config:
<AppContextSwitchOverrides value="Switch.System.IdentityModel.DisableMultipleDNSEntriesInSANCertificate=true" />
Read this article Mitigation: X509CertificiateClaimSet.FindClaims Method
Very IMPORTANT for now Azure WebApps / WebJob etc, doesn't support 4.6.1 I will note here when (said at jan 21, 2016).
It means, that you can develop a web job application with 4.6.1, but when you push it to Azure, you can see exceptions like Job failed due to exit code -2146232576
January 29th Microsoft released version 3.1.3 of the NuGet package WindowsAzure.ServiceBus.
From the release notes:
• General: .Net 4.6.1+ compatibility fix. Fixing custom DNS IdentityVerifier so that we honor multiple DNS claims returned by WIF
Upgrading the package solved the problem for us.
As outlined in this answer above, the snippet below does the trick
<runtime>
...
<AppContextSwitchOverrides value="Switch.System.DisableMultipleDNSEntriesInSANCertificate=true" />
...
<runtime>
BUT be carefull to add it to the correct project in your solution! Add it to the project containing the Azure code and Azure references.
Microsoft released a new package (under a new name) to fix this issue. So ...
remove the Microsoft.AspNet.SignalR.ServiceBus package,
install the Microsoft.AspNet.SignalR.ServiceBus3 package instead, and
upgrade the WindowsAzure.ServiceBus package.
More info here: https://github.com/SignalR/SignalR/issues/3548#issuecomment-296326048
Downgrading from .net 4.6.1 to 4.6 seems to prevent the issue from occurring.
Today, I ran into this issue and had no idea about it. Finally, I decided to upgrade all the Azure nuget packages that I am using (including webjobs, servicebus ...) and BOOM! it WORKS. Hopefully, it will help if anyone runs into this issue in the future
For me it started failing after I updated .NET Framework from 4.5.2 to 4.7
All I did to fix it was update the Nuget Package WindowsAzure.ServiceBus to 5.2.0